阻塞與死鎖（三） 死鎖的定位及解決方法

原文:

阻塞與死鎖（三）——死鎖的定位及解決方法

在sql server的兩個或多個任務中，如果某個任務鎖定了其他任務試圖鎖定的資源。會造成這些任務的永久阻塞，從而出現死鎖。

下圖為例：

l  事務t1獲得了行r1的共享鎖。

l  事務t2獲得了行r2的共享鎖。

l  然後事務t1請求行r2的排它鎖，但是t2完成並釋放其對r2的共享鎖之前被阻塞。

l  t2請求行r1的排它鎖，但是事務t1完成並釋放其對r1持有的共享鎖之前被阻塞。

現在t2與t1相互等待，導致了死鎖。一般情況下監視器會自動檢測並解決這個問題。

死鎖不僅僅發生在鎖資源上面，還會發生在一下資源上：

l鎖。例如頁、行、元資料和應用程式上的鎖。

l工作執行緒。如果排隊等待執行緒的任務擁有阻塞所有其他工作執行緒的資源，也會導致死鎖。

l記憶體。當併發請求等待獲得記憶體，而當前的可用記憶體無法滿足其需要時，可能發生死鎖。

l並行查詢執行的相關資源。當乙個語句用到多個執行緒執行時，執行緒之間有可能發生死鎖。

預設5秒鐘搜尋sql server中的所有任務，檢測是否有死鎖。如果有，將選擇乙個作為犧牲品，並返回1205錯誤。一般是開銷最小的事務作為犧牲品。

阻塞：當乙個事務請求乙個被其他事務鎖定的資源上的鎖時，發出請求的事務會一直等待下去，知道該鎖被別人釋放，自己能申請到位置。

預設情況下除非設定了lock_timeout，否則事務會一直等待下去。

死鎖：兩個或多個程序之間的相互等待。但是由於sql server有資料庫引擎死鎖檢測方案，至少5秒鐘會消除乙個現有的死鎖。對效能的影響往往沒有阻塞嚴重。

1、 跟蹤標誌1204和跟蹤標誌1222：

開啟跟蹤的語句：

對於1222產生的結果解釋：

1、 死鎖犧牲的程序：第一句deadlockvictim=process***x，中的***x就是死鎖犧牲品。

2、 死鎖發生的程序資訊：第二部分的process-list

3、 發生死鎖的資源資訊：在結果的resource-list中

2、 死鎖圖形事件：

從sqlserver profiler中得到，一般結合1222跟蹤標誌和sql trace。

首先從errorlog中尋找1222的輸出結果，根據輸出的時間在跟蹤裡找到相應的連線。然後分析原因。

儘管死鎖不能完全避免，但是可以把機會降到最低：

l  按同一順序訪問物件。

l  避免事務中的使用者互動。

l  保持事務簡短並處於乙個批處理中。

l  使用腳底的隔離級別。

l  調整語句的執行計畫，減少鎖的申請數目。

按同一順序訪問物件：

如果所有併發事務按同一順序訪問物件，則發生死鎖的可能性會降低。

避免事務中的使用者互動：

避免編寫包含使用者互動的事務，因為沒有使用者干預的批處理的執行速度遠快於必須等待使用者響應時的查詢速度。

保持事務簡短並處於乙個批處理中：

執行時間越長，等待時間就越長，造成死鎖的機會就越高。

使用腳底的隔離級別：

確定事務能否在低隔離級別上執行。盡可能使用較低的隔離級別。

調整語句的執行計畫，減少鎖的申請數目：

可以從執行計畫中找出哪些資源耗得比較多。此時鎖的數目也會相應增多。

阻塞與死鎖（三） 死鎖的定位及解決方法

在sql server的兩個或多個任務中，如果某個任務鎖定了其他任務試圖鎖定的資源。會造成這些任務的永久阻塞，從而出現死鎖。下圖為例 l 事務t1獲得了行r1的共享鎖。l 事務t2獲得了行r2的共享鎖。l 然後事務t1請求行r2的排它鎖，但是t2完成並釋放其對r2的共享鎖之前被阻塞。l t2請求行r...

阻塞與死鎖（三） 死鎖的定位及解決方法

原文 阻塞與死鎖 三 死鎖的定位及解決方法 在sql server的兩個或多個任務中，如果某個任務鎖定了其他任務試圖鎖定的資源。會造成這些任務的永久阻塞，從而出現死鎖。下圖為例 l 事務t1獲得了行r1的共享鎖。l 事務t2獲得了行r2的共享鎖。l 然後事務t1請求行r2的排它鎖，但是t2完成並釋放...

死鎖及死鎖的解決

如果一組程序中的每乙個程序都在等待僅由該組程序中的其它程序才能引發的事件，那麼該組程序是死鎖的，1 競爭不可搶占性資源。當系統把某資源分配給該程序後，就不能將它強行收回，只能在程序用完後自行釋放。2 競爭可消耗資源。當系統中供多個程序共享的資源如印表機，公用佇列等，其數目不足以滿足諸程序的需要時，會...