本篇文章給大家分享的是有關(guān)Sql Server中怎么監(jiān)控死鎖，小編覺得挺實用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

成都創(chuàng)新互聯(lián)企業(yè)建站,十多年網(wǎng)站建設(shè)經(jīng)驗，專注于網(wǎng)站建設(shè)技術(shù)，精于網(wǎng)頁設(shè)計，有多年建站和網(wǎng)站代運營經(jīng)驗，設(shè)計師為客戶打造網(wǎng)絡(luò)企業(yè)風(fēng)格，提供周到的建站售前咨詢和貼心的售后服務(wù)。對于成都網(wǎng)站制作、成都做網(wǎng)站中不同領(lǐng)域進(jìn)行深入了解和探索，創(chuàng)新互聯(lián)在網(wǎng)站建設(shè)中充分了解客戶行業(yè)的需求，以靈動的思維在網(wǎng)頁中充分展現(xiàn)，通過對客戶行業(yè)精準(zhǔn)市場調(diào)研，為客戶提供的解決方案。

死鎖的xml文件如下：

UPDATE FinanceReceiptNoRule SET NowSeqValue=@ReturnNum,ISRUNNING='0',LastWriteTime=GETDATE() WHERE IsRunning='1' AND SeqCode=@SeqCode declare @SeqCode varchar(60)declare @ReturnNum bigintset @SeqCode='CGJS20160106'while(1=1)beginUPDATE FinanceReceiptNoRule SET NowSeqValue=@ReturnNum,ISRUNNING='0',LastWriteTime=GETDATE() WHERE IsRunning='1' AND SeqCode=@SeqCodeend Update dbo.FinanceReceiptNoRule Set [IsRunning]='1' where SeqCode=@SeqCode and IsRunning='0' declare @SeqCode varchar(60)declare @ReturnNum bigintset @SeqCode='CGJS20160106'while(1=1)beginUpdate dbo.FinanceReceiptNoRule Set [IsRunning]='1' where SeqCode=@SeqCode and IsRunning='0' end

表格結(jié)構(gòu)跟模擬數(shù)據(jù)如下：

--涉及表格：CREATE TABLE [dbo].[FinanceReceiptNoRule]([SeqCode] [varchar](60) NOT NULL,[NowSeqValue] [bigint] NULL,[SeqDate] [varchar](14) NOT NULL,[IsRunning] [varchar](1) NULL,[LastWriteTime] [datetime] NULL,[Prefix] [varchar](4) NULL) ON [PRIMARY]GO--數(shù)據(jù)模擬INSERT [dbo].[FinanceReceiptNoRule] ([SeqCode], [NowSeqValue], [SeqDate], [IsRunning], [LastWriteTime], [Prefix]) VALUES (N'TEST20150108', 1469, N'20150108', N'0', CAST(N'2015-01-08 05:05:49.163' AS DateTime), N'TEST')GOINSERT [dbo].[FinanceReceiptNoRule] ([SeqCode], [NowSeqValue], [SeqDate], [IsRunning], [LastWriteTime], [Prefix]) VALUES (N'TEST20150109', 1377, N'20150109', N'0', CAST(N'2015-01-09 04:50:26.610' AS DateTime), N'TEST')GO ALTER TABLE [dbo].[FinanceReceiptNoRule] ADD CONSTRAINT [pk_FinanceReceiptNoRule] PRIMARY KEY NONCLUSTERED ([SeqCode] ASC)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]GO

1.2 如何監(jiān)控

捕獲死鎖有多種方式可以捕獲，這里介紹2種：SQL SERVER Profiler工具跟Extended Events。Profiler相對比較耗資源，但是由于只監(jiān)控死鎖這一項，所以性能影響不是很大，其可視化界面較易上手；Extended Events耗費資源較少，實時記錄到倒數(shù)第二個死鎖，同時需要SQL語句來分析查詢記錄文件。

如何使用 Profiler監(jiān)控？

打開 SSMS，點擊<工具>，選擇 ，如下圖。

登錄到需要監(jiān)控的DB實例，填寫相應(yīng)的跟蹤屬性，首先是<常規(guī)>頁面,如下圖。這里注意2個方面，第一，選擇 模板，這個模板即可以用來監(jiān)控死鎖，也可以拿來觀察 鎖申請與釋放情況，非常詳細(xì)，有事沒事可以多拿來看SELECT UPDATE DELETE等語句對鎖的申請及釋放情況；第二，監(jiān)控結(jié)果存儲，建議可以存放到某個表格中去，方便定期分析與統(tǒng)計。

接著填寫<事件選擇>項，只需要選擇 Events，其他都不需要打勾，最后點擊運行就可以開始監(jiān)控了。

可以用一個萬年常用的例子來檢查是否監(jiān)控正常，開3個查詢窗口，按照以下順序執(zhí)行則會發(fā)生資源占用及申請互斥導(dǎo)致死鎖，執(zhí)行完第5步，等待1-3s則發(fā)生死鎖。腳本提供如下：

--session 1CREATE TABLE Test_DL(id int not null primary key ,name varchar(100));INSERT INTO Test_DL(id,name) select 1,'a';INSERT INTO Test_DL(id,name) select 2,'b';--session2 2 2 2 2 2 2 2 2 2 BEGIN TRANSACTIONUPDATE Test_DL SET Name='a-test' WHERE ID=1--session3 3 3 3 3 3 3 3 3 3 BEGIN TRANSACTIONUPDATE Test_DL SET Name='b-test' WHERE ID=2--session2 2 2 2 2 2 2 2 2 2  SELECT * FROM Test_DL WHERE ID=2--session3 3 3 3 3 3 3 3 3 3 SELECT * FROM Test_DL WHERE ID=1模擬死鎖SQL

監(jiān)控到的死鎖界面如下：

如何使用Extended Events監(jiān)控？

建立擴(kuò)展事件監(jiān)控的腳本如下：（擴(kuò)展事件很贊，2012版支持可視化操作，感興趣的可以上 MSDN了解:https://msdn.microsoft.com/zh-cn/library/bb630282.aspx，本文就不分析語法等知識點了）

CREATE EVENT SESSION [DeadLock] ON SERVER ADD EVENT sqlserver.xml_deadlock_report ADD TARGET package0.event_file(SET filename=N'F:\events\deadlock\deadlock.xel',max_file_size=(20)),ADD TARGET package0.ring_buffer(SET max_events_limit=(100),max_memory=(10240),occurrence_number=(50))WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=ON)GO

查詢SQL如下，這里需要注意：查詢是基于buffer還是基于filer分析，一般buffer存儲的個數(shù)都是有限的，比如上文我們只分配了4M存儲，file分析則是完整的，但是要看保留的文件個數(shù)。這里我們給出buffer的查詢SQL如下，file的查詢大家感興趣的可以動手寫下。

DECLARE @deadlock_xml XMLSELECT @deadlock_xml=(      SELECT         (         SELECT          CONVERT(XML, target_data)        FROM sys.dm_xe_session_targets st        JOIN sys.dm_xe_sessions s ON s.address = st.event_session_address        WHERE s.name = 'deadlock' AND st.target_name = 'ring_buffer'        ) AS [x]      FOR XML PATH('') , TYPE      )SELECT dateadd(hour,+6,tb.col.value('@timestamp[1]','varchar(max)')) TimePoint,tb.col.value('(data/value/deadlock/process-list/process/executionStack/frame)[1]','VARCHAR(MAX)') statement_parameter_k,tb.col.value('(data/value/deadlock/process-list/process/executionStack/frame)[2]','VARCHAR(MAX)') statement_k,tb.col.value('(data/value/deadlock/process-list/process/executionStack/frame)[3]','VARCHAR(MAX)') statement_parameter,tb.col.value('(data/value/deadlock/process-list/process/executionStack/frame)[4]','VARCHAR(MAX)') [statement],tb.col.value('(data/value/deadlock/process-list/process/@waitresource)[1]','VARCHAR(MAX)') waitresource_k,tb.col.value('(data/value/deadlock/process-list/process/@waitresource)[2]','VARCHAR(MAX)') waitresource,tb.col.value('(data/value/deadlock/process-list/process/@isolationlevel)[1]','VARCHAR(MAX)') isolationlevel_k,tb.col.value('(data/value/deadlock/process-list/process/@isolationlevel)[2]','VARCHAR(MAX)') isolationlevel,tb.col.value('(data/value/deadlock/process-list/process/@waittime)[1]','VARCHAR(MAX)') waittime_k,tb.col.value('(data/value/deadlock/process-list/process/@waittime)[2]','VARCHAR(MAX)') waittime,tb.col.value('(data/value/deadlock/process-list/process/@clientapp)[1]','VARCHAR(MAX)') clientapp_k,tb.col.value('(data/value/deadlock/process-list/process/@clientapp)[2]','VARCHAR(MAX)') clientapp,tb.col.value('(data/value/deadlock/process-list/process/@hostname)[1]','VARCHAR(MAX)') hostname_k,tb.col.value('(data/value/deadlock/process-list/process/@hostname)[2]','VARCHAR(MAX)') hostnameFROM @deadlock_xml.nodes('//event') as tb(col)

這個SQL可以查詢的出非常詳細(xì)的資源爭奪情況，如果想要有效的使用擴(kuò)展事件，建議大家詳細(xì)查看下官網(wǎng)的xml語法（SQL SERVER對xml的支持也是棒棒噠，期待2016版中的json支持）

是不是很清晰，一目了然，有了這個就可以去分析拉！

2 分析

根據(jù)xml文件內(nèi)容或者擴(kuò)展事件的監(jiān)控內(nèi)容，都可以整理為以下信息（開頭的那個死鎖分析）：

查看事務(wù)1及事務(wù)2的執(zhí)行計劃如下：

結(jié)合表格及執(zhí)行計劃，可以大致推測死鎖過程：

會話1：

根據(jù)主鍵SeqCode查找到鍵值所在的 索引頁 Index_Page，找到該頁上面的 keyhashvalue 鍵值行 Index_key，對Index_Page持有IU鎖，對Index_key持有U鎖；  由于該表是堆表，bookmark lookup是通過 RID查找 ，即通過行標(biāo)識符查找，找到RID所對應(yīng)的行數(shù)據(jù)所在的 數(shù)據(jù)頁 Data_Page，然后在該頁面上找到RID指向槽號上的行數(shù)據(jù)，對該行數(shù)據(jù)持有U鎖；  這個時候，已經(jīng)查找到了需要更新的行數(shù)據(jù)，可以把數(shù)據(jù)頁 Data_Page上的IU鎖 升級為IX鎖，RID指向的行數(shù)據(jù) 從U鎖升級為X鎖，升級結(jié)束后，釋放索引頁跟鍵值行上面的 IU鎖及U鎖。  則此時，會話1 持有 Data_Page 上的IX鎖、RID行上的 X鎖.

這個過程中，剛好會話2進(jìn)行這樣的鎖申請：

找出事務(wù)2中持有鎖資源是哪個索引，可以根據(jù)sys.partitions 可以查看到72057594038910976是主鍵pk_FinanceReceiptNoRule，主鍵列是：SeqCode。  根據(jù)主鍵SeqCode查找到鍵值所在的 索引頁 Index_Page，找到該頁上面的 鍵值行 Index_key，對Index_Page持有IU鎖，對Index_key持有U鎖；  由于該表是堆表，bookmark lookup是通過 RID查找 ，即通過行標(biāo)識符查找，找到RID所對應(yīng)的行數(shù)據(jù)所在的 數(shù)據(jù)頁 Data_Page，然后在該頁面上找到RID指向槽號上的行數(shù)據(jù)，準(zhǔn)備該行數(shù)據(jù)持有U鎖，但是發(fā)現(xiàn)RID行上被會話1持有了X鎖，導(dǎo)致其申請 U鎖 Timeout。    則此時 會話2 持有 Index_Page上的IU鎖、Index_key上的U鎖、Data_Page上的IU鎖，請求 RID行的 U鎖。

假設(shè)這個時候，會話1 中又執(zhí)行了一次update操作（同一個事務(wù)中）：

根據(jù)主鍵SeqCode查找到鍵值所在的 索引頁Index_Page，找到該頁上面的 鍵值行Index_key，對Index_Page持有IU鎖，準(zhǔn)備對Index_key持有U鎖，但是發(fā)現(xiàn) Index_key被會話2持有了U鎖。

那么這個時候死鎖就產(chǎn)生了(詳見下圖)：

會話1 持有 Data_Page 上的IX鎖、RID行上的 X鎖，申請 Index_key 的U鎖（等待會話2釋放）  會話2 持有 Index_Page上的IU鎖、Index_key上的U鎖、Data_Page上的IU鎖，請求 RID行的 U鎖（等待會話1釋放）

3 解決

想法子除去RID查找，直接index就找到數(shù)據(jù)，就不會發(fā)生這個死鎖，也就是，在主鍵上面重新建立聚集索引，丟棄原先的非聚集索引主鍵。因為這樣排除了RID的U鎖申請與持有，直接是保持X鎖 直至事務(wù)結(jié)束，同時可以直接根據(jù)主鍵來修改鍵值所在的數(shù)據(jù)頁，減少的RID查詢行的時間。

根據(jù)主鍵SeqCode查找到鍵值所在的 索引頁 Index_Page，找到該頁上面的 keyhashvalue 鍵值行 Index_key，對Index_Page持有IU鎖，對Index_key持有U鎖；  由于該表已經(jīng)是聚集索引表，主鍵所在的頁上包含 行數(shù)據(jù)，則可以直接 對Index_Page持有IU鎖升級為IX鎖，對Index_key持有U鎖升級為X鎖，避免了RID逐個找行數(shù)據(jù)的鎖申請

以上就是Sql Server中怎么監(jiān)控死鎖，小編相信有部分知識點可能是我們?nèi)粘９ぷ鲿姷交蛴玫降?。希望你能通過這篇文章學(xué)到更多知識。更多詳情敬請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。