當一個用戶會話（會話1）已經(jīng)落定了一個資源，而另一個會話（會話2）想要修改該資源，并且會話2也鎖定了會話1想要修改的資源時，就會出現(xiàn)死鎖(deadlocking)。在另一方釋放資源前，會話1和會話2都不可能繼續(xù)。所以，SQL Server會選擇死鎖中的一個會話作為死鎖犧牲品。

　　注意：死鎖犧牲品的會話會被殺死，事務會被回滾。

　　注意：死鎖與正常的阻塞是兩個經(jīng)常被混淆的概念。

　　發(fā)生死鎖的一些原因：

　　1、應用程序以不同的次序訪問表。例如會話1先更新了客戶然后更新了訂單，而會話2先更新了訂單然后更新了客戶。這就增加了死鎖的可能性。

　　2、應用程序使用了長時間的事務，在一個事務中更新很多行或很多表。這樣增加了行的表面積，從而導致死鎖沖突。

　　3、在一些情況下，SQL Server發(fā)出了一些行鎖，之后它又決定將其升級為表鎖。如果這些行在相同的數(shù)據(jù)頁面中，并且兩個會話希望同時在相同的頁面升級鎖粒度，就會產(chǎn)生死鎖。

　　一、使用 SQL Server Profiler 分析死鎖

　　http://msdn.microsoft.com/zh-cn/library/ms188246.ASPx

　　二、使用跟蹤標志位找出死鎖

　　本文主要介紹使用DBCC TRACEON、DBCC TRACEOFF和DBCC TRACESTATUS命令來確保死鎖被正確記錄到SQL Server Management Studio SQL日志中。這些命令用來啟用、關閉、和檢查跟蹤標志位的狀態(tài)。

　　■DBCC TRACEON，啟用跟蹤標志位。用法：DBCC TRACEON ( trace# [ ,...n ][ , -1 ] ) [ WITH NO_INFOMSGS ]

　　詳細參看 MSDN:http://msdn.microsoft.com/zh-cn/library/ms187329.ASPx

　　■DBCC TRACESTATUS，檢查跟蹤標志位狀態(tài)。用法：DBCC TRACESTATUS ( [ [ trace# [ ,...n ] ] [ , ] [ -1 ] ] ) [ WITH NO_INFOMSGS ]

　　詳細參看 MSDN:http://msdn.microsoft.com/zh-cn/library/ms187809.ASPx

　　■DBCC TRACEOFF，關閉跟蹤標志位。用法：DBCC TRACEOFF (trace# [ ,...n ] [ , -1 ] ) [ WITH NO_INFOMSGS ]

　　詳細參看 MSDN:http://msdn.microsoft.com/en-us/library/ms174401.ASPx

　　下面我們模擬一個死鎖：

　　在第一個SQL查詢窗口執(zhí)行：

use AdventureWorks
go
SET NOCOUNT ON
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
WHILE 1=1
BEGIN
BEGIN TRAN
UPDATE Purchasing.Vendor
SET CreditRating = 1
WHERE VendorID = 90
UPDATE Purchasing.Vendor
SET CreditRating = 2
WHERE VendorID = 91
COMMIT TRAN
END        

        

        
        
      
        
it知識庫：SQL Server 2008中SQL應用之－“死鎖(Deadlocking)”，轉(zhuǎn)載需保留來源！
        
鄭重聲明：本文版權歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。