徵狀
假設您已安裝 Microsoft SQL Server 2014、2016或2017。 您可能會遇到下列一或多個問題：
-
SQL Server 實例顯示沒有反應，且發生「未產生排程」錯誤。 您可能需要重新開機伺服器才能復原。
-
回滾事務可能需要花很長的時間才能完成。 在大多數情況下，重新開機實例將能讓資料庫的復原速度比復原快得多。 請注意，回滾可能需要花很長的時間才能完成，請參閱下方的 [其他資訊] 區段，以取得在嘗試重新開機前，如何監視回滾的詳細資料。
-
您可能會看到旋轉鎖的高等待，例如 SOS_OBJECT_STORE。
解決方案
此問題已在下列 SQL Server 累計更新中修正：
每個新的 SQL Server 累計更新都包含所有的修正程式，以及前一個累積更新中所包含的所有安全性修正程式。 查看 SQL Server 的最新累計更新：
SQL Server Service pack 資訊
此更新已在下列 SQL Server service pack 中修正：
Service pack 是累加的。 每個新的 service pack 都包含舊版 service pack 中的所有修正程式，以及任何新的修正程式。 我們建議您將最新的 service pack 和該 service pack 的最新累計更新套用。 在安裝最新的 service pack 之前，您不需要安裝舊版 service pack。 使用下列文章中的表格1，尋找最新 service pack 和最新累計更新的詳細資訊。
其他相關資訊
復原可能需要花很長的時間（例如長時間執行的事務），在事務記錄檔中有大量的 VLFs，但 i/o 等等。 為了確認本文所述的問題是慢復原的根本原因，我們建議使用下列技術來監視復原作業的進度：
-
從 sys.dm_exec_requests中，找出其命令設定為「已終止/復原」的 session_id，並確定會話是在 IO 與 CPU 時間累積，以指示進度。 如果未變更 IO，可能表示您遇到本文所述的問題。
-
查詢 sys.dm_tran_database_transactions 以使用如下所示的查詢來識別復原的目前狀態：
選取 getdate （）作為 CurrentTime、database_transaction_next_undo_lsn、database_transaction_begin_lsn、t.transaction_id、database_transaction_begin_time、database_transaction_log_record_count、db_name （t.database_id）
從 sys.dm_tran_database_transactions t
加入 sys.dm_exec_requests s 在 t.transaction_id = s.transaction_id
其中 t.database_id = db_id （"<Database Name"），s.session_id =<Session_id 執行回滾作業>
注意：
在上述查詢中，
database_transaction_next_undo_lsn 是要復原的下一筆記錄的 lsn。 database_transaction_begin_lsn 是交易記錄日誌中交易的開始記錄的 lsn。
database_transaction_next_undo_lsn 應減少此查詢的每個快照。 當 database_transaction_next_undo_lsn 達到 database_transaction_begin_lsn 時，回滾就會成功完成。
這裡的目標是在預先確定的間隔中拍攝前一個查詢的幾個快照，然後使用該間隔中 database_transaction_next_undo_lsn 處理的 LSNs，並在該間隔內外推所需的時間，以估計 database_transaction_next_undo_lsn 達到 database_transaction_begin_lsn所需的時間。
如果復原在每個快照之間的執行速度相當完善，我們建議您不需重新開機 SQL Server 實例，就能讓復原自行完成。
如需長時間執行的復原的詳細資訊，請參閱下列文章：
狀態
Microsoft 已確認＜適用於＞一節中所列的 Microsoft 產品確實有上述問題。
參考
瞭解 Microsoft 用於描述軟體更新的 詞彙。
