SQL Server 2008中SQL應(yīng)用之一“死鎖(Deadlocking)”
當(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)用程序以不同的次序訪問表。例如會(huì)話1先更新了客戶然后更新了訂單,而會(huì)話2先更新了訂單然后更新了客戶。這就增加了死鎖的可能性。
2、應(yīng)用程序使用了長時(shí)間的事務(wù),在一個(gè)事務(wù)中更新很多行或很多表。這樣增加了行的“表面積”,從而導(dǎo)致死鎖沖突。
3、在一些情況下,SQL Server發(fā)出了一些行鎖,之后它又決定將其升級(jí)為表鎖。如果這些行在相同的數(shù)據(jù)頁面中,并且兩個(gè)會(huì)話希望同時(shí)在相同的頁面升級(jí)鎖粒度,就會(huì)產(chǎn)生死鎖。
一、使用 SQL Server Profiler 分析死鎖
http://msdn.microsoft.com/zh-cn/library/ms188246.aspx
二、使用跟蹤標(biāo)志位找出死鎖
本文主要介紹使用DBCC TRACEON、DBCC TRACEOFF和DBCC TRACESTATUS命令來確保死鎖被正確記錄到SQL Server Management Studio SQL日志中。這些命令用來啟用、關(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
在第二個(gè)查詢窗口執(zhí)行:
- use AdventureWorks
- go
- SET NOCOUNT ON
- SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
- WHILE 1=1
- BEGIN
- BEGIN TRAN
- UPDATE Purchasing.Vendor
- SET CreditRating = 2
- WHERE VendorID = 91
- UPDATE Purchasing.Vendor
- SET CreditRating = 1
- WHERE VendorID = 90
- COMMIT TRAN
- END
等待幾秒后,其中一個(gè)查詢窗口會(huì)提示:
- /*
- Msg 1205, Level 13, State 51, Line 9
- Transaction (Process ID 52) was deadlocked on lock resources with another process
- and has been chosen as the deadlock victim.Rerun the transaction.
- */
此時(shí),查看,SQL Server Management Studio的SQL 日志,發(fā)現(xiàn)死鎖事件沒有被記錄。
打開第三個(gè)查詢窗口,執(zhí)行:
- DBCC TRACEON (1222, -1)
- GO
- DBCC TRACESTATUS
為了模擬另一個(gè)死鎖,將重啟動(dòng)“勝利”的那個(gè)連接查詢(沒有被殺死的那個(gè)),然后重啟死鎖丟失的會(huì)話,幾秒后又出現(xiàn)另一個(gè)死鎖了。
死鎖發(fā)生后,停止另一個(gè)執(zhí)行的查詢?,F(xiàn)在,SQL Server Management Studio的SQL 日志中包含了死鎖事件的詳細(xì)錯(cuò)誤信息。包括相關(guān)的數(shù)據(jù)庫和對(duì)象、鎖定模式以及死鎖中的SQL語句。
在檢查完畢后,關(guān)閉跟蹤標(biāo)志位:
- DBCC TRACEON (1222, -1)
- GO
- DBCC TRACESTATUS
解析:
在本例中,我們使用跟蹤標(biāo)志位1222。跟蹤標(biāo)志位1222能把詳細(xì)的死鎖信息返回到SQL日志中,標(biāo)志位-1表示跟蹤標(biāo)志位1222應(yīng)該對(duì)所有SQL Server連接在全局中啟用。
三、設(shè)置死鎖優(yōu)先級(jí)
我們也可以使用SET DEADLOCK_PRIORITY命令來增加一個(gè)查詢會(huì)話被選為死鎖犧牲品的可能性。此命令的語法如下:
SET DEADLOCK_PRIORITY { LOW | NORMAL | HIGH |
http://msdn.microsoft.com/en-us/library/ms186736.aspx
例如,上例中,***個(gè)查詢窗口如果使用以下的死鎖優(yōu)先級(jí)命令,幾乎可以肯定會(huì)被選為死鎖犧牲品。(正常情況下,SQL Server會(huì)把它認(rèn)為取消或回滾代價(jià)最小的連接作為默認(rèn)的死鎖犧牲品):
- SET NOCOUNT ON
- SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
- SET DEADLOCK_PRIORITY LOW
- BEGIN TRAN
- UPDATE Purchasing.Vendor
- SET CreditRating = 1
- WHERE VendorID = 2
- UPDATE Purchasing.Vendor
- SET CreditRating = 2
- WHERE VendorID = 1
- COMMIT TRAN
解析:可以將優(yōu)先級(jí)設(shè)為High或Normal,High表示除非另一個(gè)會(huì)話有相同的優(yōu)先級(jí),否則它不會(huì)被選為犧牲品。Normal是默認(rèn)行為,如果另一個(gè)會(huì)話是High,它可能會(huì)被選中。如果另一個(gè)是Low,則它可以安全地不被選中。如果兩個(gè)會(huì)話有相同的優(yōu)先級(jí),則回滾代價(jià)最小的事務(wù)會(huì)被選中。
關(guān)于死鎖的其他資源,可能會(huì)有補(bǔ)充:
happyhippy的SQL Server死鎖總結(jié),也總結(jié)的不錯(cuò)。
鏈接為:http://www.cnblogs.com/happyhippy/archive/2008/11/14/1333922.html
原文鏈接:http://www.cnblogs.com/downmoon/archive/2011/02/27/1966337.html
【編輯推薦】