KB4338890-FIX: "không có lỗi" Scheduler Scheduler "và SQL Server xuất hiện không phản hồi trong SQL Server 2014, 2016 và 2017

Triệu chứng

Giả định rằng bạn đã cài đặt Microsoft SQL Server 2014, 2016 hoặc 2017.  Bạn có thể gặp một hoặc nhiều sự cố sau đây:

• Phiên bản SQL Server không phản hồi và lỗi "trình lập lịch không thể thực hiện" xảy ra. Bạn có thể phải khởi động lại máy chủ để phục hồi.

• Quay ngược lại của một giao dịch có thể mất nhiều thời gian để hoàn thành. Trong hầu hết các trường hợp, khởi động lại mẫu sẽ cho phép cơ sở dữ liệu phục hồi nhanh hơn nhiều so với rollback. Lưu ý rằng có nhiều lý do quay ngược lại có thể mất nhiều thời gian để hoàn thành, hãy xem phần "thông tin thêm" bên dưới để biết chi tiết về trình triển khai giám sát trước khi tìm cách khởi động lại.

• Bạn có thể nhìn thấy các spinlocks cao, chẳng hạn như SOS_OBJECT_STORE.

Giải pháp

Sự cố này đã được khắc phục trong các bản Cập Nhật tích lũy sau đây cho SQL Server:

       Cập Nhật tích lũy 9 cho SQL Server 2017

       Bản Cập Nhật tích lũy 2 cho SQL Server 2016 SP2

Thông tin về gói dịch vụ cho SQL Server

Bản cập nhật này đã được khắc phục trong gói dịch vụ sau cho SQL Server:

Gói dịch vụ 3 cho SQL Server 2014

Thông tin Bổ sung

Có nhiều lý do khiến rollback có thể mất một thời gian dài chẳng hạn như giao dịch kéo dài, một số lượng lớn VLFs trong tệp nhật ký giao dịch, chậm I/O etc.  Để xác minh rằng vấn đề được mô tả trong bài viết này là nguyên nhân gốc của một cuộn chậm, chúng tôi khuyên bạn nên dùng các kỹ thuật sau đây để theo dõi tiến độ của thao tác rollback:

• Từ sys.dm_exec_requests, xác định session_id có lệnh được đặt là "giết/rollback" và đảm bảo rằng phiên sẽ tích lũy được cả hai thời gian Io và CPU chỉ ra tiến độ. Nếu IO không thay đổi, thì có thể là một dấu hiệu mà bạn đang gặp phải sự cố được mô tả trong bài viết này.

• Sys.dm_tran_database_transactions truy vấn để xác định trạng thái của rollback hiện tại bằng cách sử dụng truy vấn như sau:

Lưu ý:

Trong truy vấn ở trên,

database_transaction_next_undo_lsn là LSN của bản ghi tiếp theo để hoàn tác. database_transaction_begin_lsn là LSN của bản ghi bắt đầu cho giao dịch trong Nhật ký giao dịch.

database_transaction_next_undo_lsn nên giảm đi kèm theo truy vấn này. Rollback sẽ hoàn tất thành công khi database_transaction_next_undo_lsn tiếp cận database_transaction_begin_lsn.

Mục tiêu ở đây là để có một vài ảnh chụp nhanh về truy vấn trước đó trong một khoảng thời gian định trước và sau đó sử dụng Delta của LSNs được xử lý trong database_transaction_next_undo_lsn trong khoảng thời gian đó và tính toán thời gian thực hiện để ước tính thời gian sẽ mất cho database_transaction_next_undo_lsn để đến được database_transaction_begin_lsn.

Nếu quay ngược lại đang tiến triển với một tốc độ phong nha giữa mỗi bản chụp, chúng tôi khuyên bạn nên hoàn thành các cuộn trước của riêng mình mà không cần khởi động lại phiên bản SQL Server.

Xem các bài viết sau để biết thêm thông tin về phục hồi thời gian chạy dài:

• Tìm hiểu về hiệu suất phục hồi trong SQL Server

• SQL Server (2000, 2005, 2008): phục hồi/rollback kéo dài hơn dự kiến

• Cấu trúc tệp nhật ký có thể ảnh hưởng đến thời gian khôi phục cơ sở dữ liệu

• Tiến độ khôi phục cơ sở dữ liệu theo dõi bằng cách sử dụng thông tin từ danh

Trạng thái

Microsoft đã xác nhận đây là sự cố trong các sản phẩm của Microsoft được liệt kê trong phần "Áp dụng cho".

Tham khảo

Tìm hiểu về thuật ngữmà Microsoft sử dụng để mô tả các bản cập nhật phần mềm.