KB4338890 - 修正:「排程器不妥協」錯誤,SQL Server在 2014、2016 和 2017 SQL Server 中似乎無反應

套用到
SQL Server 2016 Developer - duplicate (do not use) SQL Server 2016 Enterprise - duplicate (do not use) SQL Server 2016 Enterprise Core - duplicate (do not use) SQL Server 2016 Standard - duplicate (do not use) SQL Server 2017 Developer on Windows SQL Server 2017 Enterprise Core on Windows SQL Server 2017 Enterprise on Windows SQL Server 2017 Standard on Windows SQL Server 2014 Developer - duplicate (do not use) SQL Server 2014 Enterprise - duplicate (do not use) SQL Server 2014 Enterprise Core - duplicate (do not use) SQL Server 2014 Standard - duplicate (do not use)

症狀

假設你安裝的是 Microsoft SQL Server 2014、2016 或 2017。  你可能會遇到以下一項或多項問題:

  • SQL Server 實例看起來無反應,並出現「無法讓出排程器」錯誤。 你可能需要重新啟動伺服器才能恢復。
  • 交易回滾可能需要很長時間才能完成。 大多數情況下,重新啟動實例會讓資料庫比回滾更快恢復。 請注意,回滾可能需要長時間,請參考下方「更多資訊」區塊,了解在嘗試重新啟動前監控回滾的細節。
  • 你可能會看到像 SOS_OBJECT_STORE 這類旋轉鎖的等待時間很高。

解決方式

此問題已在以下 SQL Server 的累積更新中得到修正:

累積更新9 for SQL Server 2017

Cumulative Update 2 for SQL Server 2016 SP2

關於 SQL Server 的累積更新:

每次新的 SQL Server 累積更新都包含了之前累積更新中包含的所有熱修補與安全修補。 請查看 SQL Server 的最新累積更新:

SQL Server 2017 最新累積更新

SQL Server 2016 最新累積更新

SQL Server 2014 最新累積更新

SQL Server 服務包資訊

此更新已在以下 SQL Server 服務包中修正:

Service Pack 3 for SQL Server 2014

關於 SQL Server 服務包:

Service Pack 是累積性的。 每個新版 Service Pack 都包含前一版 Service Pack 中所有的修正程式,以及任何新增的修正程式。 我們的建議是套用該服務包的最新服務包及累積更新。 所以在安裝最新版的 Service Pack 之前,您不需要安裝前一版的 Service Pack。 請使用以下文章中的表1,查詢最新服務包及最新累積更新的更多資訊。

如何判斷 SQL Server 及其元件的版本、版次及更新層級

更多資訊

回滾可能耗時過長的原因有很多,例如交易執行時間長、交易日誌檔中有大量 VLF、I/O 緩慢等。為了驗證本文所述問題是否為回滾緩慢的根本原因,我們建議使用以下技術來監控回滾操作的進展:

  • sys.dm_exec_requests中,找出指令設定為「KILLED/ROLLBACK」的session_id,並確保該會話同時累積 IO 與 CPU 時間,顯示進度。 如果 IO 沒有改變,那可能是你遇到本文描述的問題。
  • 查詢 sys.dm_tran_database_transactions 用以下查詢來識別回滾的當前狀態:

注意

  • 選擇取得日期 () 為 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
       在 t.transaction_id=s.transaction_id
  • 其中 t.database_id=db_id (『<資料庫名稱』) 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 處理的 LSN 的 delta,推算所耗時間,以估算 database_transaction_next_undo_lsn 抵達 database_transaction_begin_lsn所需的時間。

如果每次快照間回滾進度良好,我們建議允許回滾自行完成,無需重啟 SQL Server 實例。

請參閱以下文章以獲得更多關於長期復原的資訊:

狀態

Microsoft 已確認這是「適用對象」一節中列出的 Microsoft 產品中的問題。

參考資料

了解 Microsoft 用來說明軟體更新的術語