SQL Server會話KILL不掉，一直處於KILLED /ROLLBACK狀態情形淺析[轉]

本文將爲您描述SQL Server會話KILL不掉，一直處於KILLED /ROLLBACK狀態情形淺析,教程操做方法:

今天遇到一個很奇怪的狀況，發現一個會話異常，這個會話只是在執行一個簡單的存儲過程，裏面使用了連接服務器（Linked Server）查詢另一臺服務器數據（存儲過程裏面沒有任何顯性事務、UPDATE、DELETE操做，只有幾個簡單的SELECT查詢，其中有兩個查詢使用了連接服務器Linked Server，因爲生產環境，很差貼出SQL語句），在DPA監控工具裏面，發現該會話引發了很是長的OLEDB等待時間，手工執行測試，發現並不耗費很長時間，KILL該會話後， 回滾狀態已完成一直是0%， 估計剩餘時間也一直是0秒。以下截圖所示：

?

code

1	KILL 129 WITH STATUSONLY;

?

code

1

?

code

1	SPID 129: 正在進行事務回滾。估計回滾已完成: 0%。估計剩餘時間: 0 秒。

 

以下所示，這個會話的start_time(Timestamp when the request arrived. Is not nullable.)爲2016-10-18 02:17:58.210，到如今2016-10-19 16:02:30.173已經有幾十個小時了，我kill會話的時間點爲2016-10-19 12：00:01。

 

 

能夠看到它等待的是OLEDB類型（圖一），也就是說等待連接服務器所指的服務器返回結果。另外這個事務的transaction_type爲2，意味這只是一個Read-only transaction（避免別人誤解，這是一個證據），transaction_state爲2，表示事務處於活動狀態（The transaction is active）。事務出現的這個時間點引發了個人注意，由於連接服務器所指向的這臺服務器出現宕機（參考連接VmWare平臺Windows Server 2012 無響應宕機），恰好是那臺服務器虛擬機出現宕機時候，重啓的時間點前面一點（那臺服務器凌晨1點多宕機，2：22AM的時候重啓的）。從DPA監控工具也能看到確實是那個點出現的。以下所示：

 

 

這種分佈式查詢，因爲Linked Server所指的服務器出現異常（例如宕機），這邊的會話進程一直在等待其返回結果，可是Linked Server所指服務器因爲異常永遠都沒法給這個會話進程反饋任何結果，就出現了這種狀況，不過有點奇怪的是，這種狀況沒法經過KILL會話來結束。 只能經過重啓服務器來解決問題， 也不能經過Kill進程解決（由於SQL Server是單進程多線程架構，不像ORACLE那種多進程架構，能夠從操做系統層面殺掉進程或線程（Windows平臺，Oracle提供了一個工具ORAKILL utility 能夠Kill線程）），可是重啓數據庫是一個很麻煩的事情。 因此這個殭屍會話就一直存在數據庫裏面,對於我這個有強迫症的人,看着它的存在,總想幹掉它. 確實是個折磨人的事情.這篇SQL Server教程是否對您有用呢?