SQL Server会话KILL不掉，一直处于KILLED /ROLLBACK状态情形浅析
今天遇到一個很奇怪的情況，發現一個會話異常，這個會話只是在執行一個簡單的存儲過程，里面使用了鏈接服務器（Linked Server）查詢另外一臺服務器數據（存儲過程里面沒有任何顯性事務、UPDATE、DELETE操作，只有幾個簡單的SELECT查詢，其中有兩個查詢使用了鏈接服務器Linked Server，由于生產環境，不好貼出SQL語句），在DPA監控工具里面，發現該會話引起了非常長的OLEDB等待時間，手工執行測試，發現并不耗費很長時間，KILL該會話后， 回滾狀態已完成一直是0%， 估計剩余時間也一直是0秒。如下截圖所示：
?
KILL 129 WITH STATUSONLY; ?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線程）），但是重啟數據庫是一個很麻煩的事情。 所以這個僵尸會話就一直存在數據庫里面,對于我這個有強迫癥的人,看著它的存在,總想干掉它. 確實是個折磨人的事情.
posted on 2018-08-03 08:57 NET未來之路 閱讀(...) 評論(...) 編輯 收藏轉載于:https://www.cnblogs.com/lonelyxmas/p/9411451.html
總結
以上是生活随笔為你收集整理的SQL Server会话KILL不掉，一直处于KILLED /ROLLBACK状态情形浅析的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 我们距离AI编程还有多远？
- 下一篇： 技术负责人所需的四个核心能力，你具备几个