SQLServer中的死鎖的介紹

簡介

     什麼是死鎖？

     我認爲，死鎖是因爲兩個對象在擁有一份資源的狀況下申請另外一份資源，而另外一份資源剛好又是這兩對象正持有的，致使兩對象沒法完成操做，且所持資源沒法釋放。

      什麼又是阻塞？

     阻塞是因爲資源不足引發的排隊等待現象。好比同時兩個進程去更新一個表。

     這裏咱們能夠把阻塞做爲死鎖的必要條件。下面咱們先理解一下死鎖和阻塞再來看一下我最近遇到一個問題以及解決思路。

SQLServer中的死鎖

     對應到SQL Server中，當在兩個或多個任務中，若是每一個任務鎖定了其餘任務試圖鎖定的資源，此時會形成這些任務永久阻塞，從而出現死鎖；

   這些資源多是：單行(RID，堆中的單行)、索引中的鍵(KEY，行鎖)、頁(PAG，8KB)、區結構(EXT，連續的8頁)、堆或B樹(HOBT) 、表(TAB，包括數據和索引)、文件(File，數據庫文件)、應用程序專用資源(APP)、元數據(METADATA)、分配單元(Allocation_Unit)、整個數據庫(DB)。

    下面我簡單舉一個例子來講明一下死鎖的原理：

    

 

 如圖，按步驟執行：

1. begin tran
update test1 set aaa=1

2.

begin tran

update test2 set aaa=1

update test1 set bbb=2

3.再次執行圖1中的Update test2 set bbb=2

執行完成後發現數據並未插入，且一直處於running狀態

 

這個時候咱們經過語句查詢死鎖的進程和語句。獲得以下結果：

 

很容易發現發生死鎖的語句，也可使用 SQL Server Profiler 分析死鎖: 將 Deadlock graph 事件類添加到跟蹤。此事件類使用死鎖涉及到的進程和對象的 XML 數據填充跟蹤中的 TextData 數據列。SQL Server 事件探查器 能夠將 XML 文檔提取到死鎖 XML  文件中，之後可在 SQL Server Management Studio 中查看該文件。如圖：

接下來咱們說一下如何處理死鎖

      1.臨時解決方案，先Kill 掉死鎖的進程，只是暫時解決這個問題。

      2.SQL Server自動選擇一條SQL做死鎖犧牲品：當死鎖發生時，鎖監視器線程執行死鎖檢查，數據庫引擎 選擇運行回滾開銷最小的事務的會話做爲死鎖犧牲品，返回1205 錯誤，回滾死鎖犧牲品的事務並釋放該事務持有的全部鎖，使其餘線程的事務能夠請求資源並繼續運行。

服務器: 消息 1205，級別 13，狀態 50，行 1 事務（進程 ID  xx）與另外一個進程已被死鎖在  lock 資源上，且該事務已被選做死鎖犧牲品。請從新運行該事務。

     3.使用SET LOCK_TIMEOUT timeout_period(單位爲毫秒)來設定請求超時。 

     4.在SQLServer 和程序兩個方面均可以作代碼上修正，這裏不在詳細描述，主要是經過發現死鎖等待一段時間後再次嘗試的方式來解決。

預防和避免死鎖

     1.儘可能減小事務執行的時間。

     2.在合理的範圍內下降隔離級別。

     3.同一個事務內儘可能避免出現循環對同一個表的處理。

     4.同一個事務內較少用戶交互，即鎖的競爭。

     5.儘可能保證邏輯處理的順序好比對錶的處理都按照一個順序進行。

     6.對於須要各類邏輯處理的表，能夠經過增長索引的方式來減小鎖的競爭。

     7.儘可能減小非彙集索引的include 的列，也能減小外鍵死鎖的發生。

     8.同一個對象儘可能採用select 在update 前來使用。

     9.對於實時性要求不高的可使用with(nolock)來實現對錶的查詢，可是可能會差生髒讀。

 

 總結

      本文簡單的介紹了死鎖的緣由，如何解決和預防。固然任何事情都是雙刃劍，還要咱們根據實際狀況來合理減小死鎖和阻塞的發生；對於不一樣隔離界別鎖帶來的問題能夠看一下我以前的一篇關於鎖的介紹。但願對死鎖發生預防和解決有必定的幫助。