這篇文章主要講解了“SQLSERVER語句交錯引發(fā)的死鎖問題怎么解決”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“SQLSERVER語句交錯引發(fā)的死鎖問題怎么解決”吧！

阿克塞哈薩克族自治網站建設公司創(chuàng)新互聯(lián)建站,阿克塞哈薩克族自治網站設計制作，有大型網站制作公司豐富經驗。已為阿克塞哈薩克族自治上千提供企業(yè)網站建設服務。企業(yè)網站搭建\成都外貿網站建設要多少錢，請找那個售后服務好的阿克塞哈薩克族自治做網站的公司定做！

一：背景

1. 講故事

相信大家在使用 SQLSERVER 的過程中經常會遇到 阻塞 和 死鎖，尤其是 死鎖，比如下面的輸出：

(1 row affected) Msg 1205, Level 13, State 51, Line 5 Transaction (Process ID 62) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

二：死鎖簡析

1. 一個測試案例

開啟兩個會話 65 和 66 ，分別使用如下查詢。

-- 會話 65 --
BEGIN TRAN
UPDATE dbo.Employees SET Title='Dr.' WHERE EmployeeID=1;
WAITFOR DELAY '00:00:10'
SELECT * FROM dbo.Orders WHERE OrderID=10258
ROLLBACK

-- 會話 66 --
BEGIN TRAN
UPDATE  dbo.Orders SET  ShipAddress='上海' WHERE OrderID=10258
WAITFOR DELAY '00:00:10'
SELECT * FROM dbo.Employees WHERE EmployeeID=1;
ROLLBACK

兩個會話非常簡單，交錯的對 Employees 和 Orders 進行 SELECT 和 UPDATE 操作，稍等幾秒后就會出現(xiàn)死鎖。

2. 尋找死鎖源頭

當我們的應用程序拿到了這樣的輸出其實作用是不大的，要想溯源最好就是通過不斷的對 SQLSERVER 進行監(jiān)視來捕獲死鎖時的上下文信息，手段也有很多：

• SQL Server Profile

• DBCC TRACEON(1222)

• DMV VIEW

這里我們就用第一種方式，一定要勾選 TextData 項，因為這里面會有死鎖上下文信息的xml表示，截圖如下：

將 profile 開啟后，重新執(zhí)行剛才的兩個查詢，一旦出現(xiàn)死鎖，profile 就會成功捕獲，然后 copy 出 TextData 項，截圖如下：

 
  
   
    
     
unknown     
     
unknown     
    
    

BEGIN TRAN
UPDATE  dbo.Orders SET  ShipAddress='上海' WHERE OrderID=10258
WAITFOR DELAY '00:00:10'
SELECT * FROM dbo.Employees WHERE EmployeeID=1;
ROLLBACK
    
   
   
    
     
unknown     
     
unknown     
    
    

BEGIN TRAN
UPDATE dbo.Employees SET Title='Dr.' WHERE EmployeeID=1;
WAITFOR DELAY '00:00:10'
SELECT * FROM dbo.Orders WHERE OrderID=10258
ROLLBACK
    
   
  
  
   
    
     
    
    
     
    
   
   
    
     
    
    
     
    
   
  
 

雖然上面有圖形化表示，但在生產環(huán)境下參考價值并不多，因為這張圖蘊含的信息比較少，熟讀和整理 xml 的內容就非常必要了，截圖如下：

仔細觀察上面的這張圖可以清晰的看到，spid=66 持有了 Orders.PK_Orders 索引上哈希碼為 59ce0997f9b8 鍵值的 X 鎖，之后需要再次獲取 Employees.PK_Employees 索引上哈希碼為 8194443284a0 鍵值上的 S 鎖，很不巧的是，此時的 Employees.PK_Employees 索引上哈希碼為 8194443284a0 的鍵值已經被 spid=65 的會話附加了 X 鎖，這是一種典型的相互等待造成的死鎖。

同時也可以觀察到，我們的語句是一個 adhoc 即時查詢，其外層也沒有 存儲過程 之類的包圍語句。

3. 尋找解決方案

知道了是什么語句和什么語句之間的沖突之后，后面的問題就比較簡單了，常見措施如下：

使用 nolock 臟讀

由于沖突中涉及到了 S 鎖，其實絕大多數(shù)系統(tǒng)對臟讀不是特別敏感，所以使用 nolock 無鎖提示是一個好辦法。

BEGIN TRAN
UPDATE  dbo.Orders SET  ShipAddress='上海' WHERE OrderID=10258
WAITFOR DELAY '00:00:10'
SELECT * FROM dbo.Employees WITH(NOLOCK) WHERE EmployeeID=1;
ROLLBACK


BEGIN TRAN
UPDATE dbo.Employees SET Title='Dr.' WHERE EmployeeID=1;
WAITFOR DELAY '00:00:10'
SELECT * FROM dbo.Orders WITH(NOLOCK) WHERE OrderID=10258
ROLLBACK

使用 MVCC 多版本控制

現(xiàn)代化的關系型數(shù)據(jù)庫都支持 快照讀 來解決 并發(fā)讀寫 的沖突，同時又能保證不臟讀，簡而言之就是在事務修改時將修改前的數(shù)據(jù)存到 tempdb 中來形成字段的版本化。

首先需要從 數(shù)據(jù)庫 級別開啟它。

ALTER DATABASE Northwind SET ALLOW_SNAPSHOT_ISOLATION ON

然后在各自事務中顯式使用 SNAPSHOT 隔離級別查詢，參考sql如下：

-- 會話 65 --
SET TRAN ISOLATION LEVEL SNAPSHOT
BEGIN TRAN
UPDATE dbo.Employees SET Title='Dr.' WHERE EmployeeID=1;
WAITFOR DELAY '00:00:10'
SELECT * FROM dbo.Orders WHERE OrderID=10258
ROLLBACK

-- 會話 66 --
SET TRAN ISOLATION LEVEL SNAPSHOT
BEGIN TRAN
UPDATE  dbo.Orders SET  ShipAddress='上海' WHERE OrderID=10258
WAITFOR DELAY '00:00:10'
SELECT * FROM dbo.Employees  WHERE EmployeeID=1;
ROLLBACK

感謝各位的閱讀，以上就是“SQLSERVER語句交錯引發(fā)的死鎖問題怎么解決”的內容了，經過本文的學習后，相信大家對SQLSERVER語句交錯引發(fā)的死鎖問題怎么解決這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關知識點的文章，歡迎關注！