|
當(dāng)一個(gè)用戶會(huì)話(會(huì)話1)已經(jīng)落定了一個(gè)資源,而另一個(gè)會(huì)話(會(huì)話2)想要修改該資源,并且會(huì)話2也鎖定了會(huì)話1想要修改的資源時(shí),就會(huì)出現(xiàn)死鎖(deadlocking)。在另一方釋放資源前,會(huì)話1和會(huì)話2都不可能繼續(xù)。所以,SQL Server會(huì)選擇死鎖中的一個(gè)會(huì)話作為死鎖犧牲品。
注意:死鎖犧牲品的會(huì)話會(huì)被殺死,事務(wù)會(huì)被回滾。
注意:死鎖與正常的阻塞是兩個(gè)經(jīng)常被混淆的概念。
發(fā)生死鎖的一些原因:
1、應(yīng)用程序以不同的次序訪問(wèn)表。例如會(huì)話1先更新了客戶然后更新了訂單,而會(huì)話2先更新了訂單然后更新了客戶。這就增加了死鎖的可能性。
2、應(yīng)用程序使用了長(zhǎng)時(shí)間的事務(wù),在一個(gè)事務(wù)中更新很多行或很多表。這樣增加了行的表面積,從而導(dǎo)致死鎖沖突。
3、在一些情況下,SQL Server發(fā)出了一些行鎖,之后它又決定將其升級(jí)為表鎖。如果這些行在相同的數(shù)據(jù)頁(yè)面中,并且兩個(gè)會(huì)話希望同時(shí)在相同的頁(yè)面升級(jí)鎖粒度,就會(huì)產(chǎn)生死鎖。
一、使用 SQL Server Profiler 分析死鎖
http://msdn.microsoft.com/zh-cn/library/ms188246.ASPx
二、使用跟蹤標(biāo)志位找出死鎖
本文主要介紹使用DBCC TRACEON、DBCC TRACEOFF和DBCC TRACESTATUS命令來(lái)確保死鎖被正確記錄到SQL Server Management Studio SQL日志中。這些命令用來(lái)啟用、關(guān)閉、和檢查跟蹤標(biāo)志位的狀態(tài)。
■DBCC TRACEON,啟用跟蹤標(biāo)志位。用法:DBCC TRACEON ( trace# [ ,...n ][ , -1 ] ) [ WITH NO_INFOMSGS ]
詳細(xì)參看 MSDN:http://msdn.microsoft.com/zh-cn/library/ms187329.ASPx
■DBCC TRACESTATUS,檢查跟蹤標(biāo)志位狀態(tài)。用法:DBCC TRACESTATUS ( [ [ trace# [ ,...n ] ] [ , ] [ -1 ] ] ) [ WITH NO_INFOMSGS ]
詳細(xì)參看 MSDN:http://msdn.microsoft.com/zh-cn/library/ms187809.ASPx
■DBCC TRACEOFF,關(guān)閉跟蹤標(biāo)志位。用法:DBCC TRACEOFF (trace# [ ,...n ] [ , -1 ] ) [ WITH NO_INFOMSGS ]
詳細(xì)參看 MSDN:http://msdn.microsoft.com/en-us/library/ms174401.ASPx
下面我們模擬一個(gè)死鎖:
在第一個(gè)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知識(shí)庫(kù):SQL Server 2008中SQL應(yīng)用之-“死鎖(Deadlocking)”,轉(zhuǎn)載需保留來(lái)源!
鄭重聲明:本文版權(quán)歸原作者所有,轉(zhuǎn)載文章僅為傳播更多信息之目的,如作者信息標(biāo)記有誤,請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除,多謝。