建站
咨詢
售后
建站咨詢
新聞中心
最近，剛跳槽到一新公司，就遇到生產(chǎn)數(shù)據(jù)庫(kù)晚上突然出現(xiàn)大面積中斷，并持續(xù)近一小時(shí)，而發(fā)生事故時(shí)，我沒(méi)有在現(xiàn)場(chǎng)，錯(cuò)過(guò)了直接獲取信息的機(jī)會(huì)；過(guò)后boss要求追查原因，于是艱難的排查過(guò)程開(kāi)始了。
開(kāi)始以為是數(shù)據(jù)庫(kù)某個(gè)JOB運(yùn)行出現(xiàn)異常引起或者是因?yàn)槌绦蚶锩婺膫€(gè)鳥(niǎo)人寫(xiě)了垃圾語(yǔ)句造成了大面積的死鎖，于是將收集的trace信息拿到本地分析，從收集到的trace信息看，數(shù)據(jù)庫(kù)在19：49：28時(shí)出現(xiàn)了鎖，系統(tǒng)cancel了它，而且是連續(xù)三個(gè)，之后數(shù)據(jù)庫(kù)大部分連接都是Abort了。
初步估計(jì)應(yīng)該是死鎖了，首先想到的就是因?yàn)閿?shù)據(jù)庫(kù)更新語(yǔ)句造成，于是查找Agent里面是否有對(duì)應(yīng)時(shí)間的JOB運(yùn)行，結(jié)果沒(méi)有匹配的，然后分析trace文件里面是否有該時(shí)間段內(nèi)運(yùn)行的長(zhǎng)Update、Insert或者Delete語(yǔ)句，查了半天也沒(méi)發(fā)現(xiàn)，汗。。。，調(diào)查長(zhǎng)查詢，還是沒(méi)有，狂汗。。。
Trace文件分析來(lái)分析去也沒(méi)辦法定位到具體語(yǔ)句（Trace 文件中只抓取了運(yùn)行時(shí)間超過(guò)2秒或者讀大于10000的記錄），看來(lái)問(wèn)題不是那么簡(jiǎn)單了；光根據(jù)Trace文件信息想要找到兇手估計(jì)不可能了，于是把Windows日志和數(shù)據(jù)庫(kù)錯(cuò)誤日志都查了一遍，也沒(méi)有發(fā)現(xiàn)任何異常，難道是無(wú)頭案。。。（沒(méi)查到任何信息，擔(dān)心飯碗不保了）
想來(lái)想去，也問(wèn)了一些牛人，都沒(méi)有啥結(jié)果，看來(lái)通過(guò)手頭上現(xiàn)有的資料估計(jì)要找出問(wèn)題是沒(méi)多少希望了，只能另辟蹊徑；既然可以肯定是因?yàn)樗梨i造成的，那說(shuō)明數(shù)據(jù)庫(kù)里面肯定存在資源的不一致訪問(wèn)或者競(jìng)爭(zhēng)，那就從死鎖下手，于是先清空掉當(dāng)前的數(shù)據(jù)庫(kù)錯(cuò)誤日志文件，再打開(kāi)1204和1222跟蹤標(biāo)志，等待魚(yú)兒上鉤。
- DBCC errorlog
- DBCC TRACEON (1204, 1222, -1);
- DBCC tracestatus
收集了幾天數(shù)據(jù)，準(zhǔn)備收網(wǎng)了，將ERROR.LOG從服務(wù)器拷貝到本地，用UE打開(kāi)，認(rèn)真一行行看，找到如下信息：
- Deadlock encountered .... Printing deadlock information
果然是死鎖，總算找到真兇了，用UE查找一把，不查不知道，一查嚇一跳，一堆死鎖...
死鎖信息如下：
查看一下頁(yè)面信息：
- DBCC TRACEON (3604)
- DBCC PAGE('XXXX',1,22664690,3) WITH TABLERESULTS
- DBCC TRACEOFF (3604)
這些頁(yè)面信息都正常。
再根據(jù)信息，Input Buf 的信息，反過(guò)來(lái)查詢Trace文件（Input Buffer 只能存放255個(gè)字節(jié)，信息顯示不全，只能反過(guò)來(lái)找）：
- select top 10 * from fn_trace_gettable('F:\perfmon\Trace_xxxx_20110406A.trc',default)
- where TextData like '%@SMESSAGE varchar(8000),@SINMATERECID varchar(8000),@SREFRECID varchar(8000)%'
- select top 10 * from fn_trace_gettable('F:\perfmon\Trace_xxxx_20110406A.trc',default)
- where TextData like '%@P0_ varchar(7),@P1_ datetime,@P2_ datetime,@P3_ varchar(7),@P4_ datetime%'
發(fā)現(xiàn)，死鎖在表Rec_Main表上，一個(gè)是修改，一個(gè)是查詢，而這個(gè)表數(shù)據(jù)量達(dá)700多W，又一個(gè)汗.....
不過(guò)很奇怪的是，死鎖顯示的信息都是些簡(jiǎn)單的修改（單條記錄修改）和查詢操作，不至于引起這么多死鎖呀，繼續(xù)頭大中...
繼續(xù)追查后發(fā)現(xiàn)，這兩個(gè)操作在數(shù)據(jù)庫(kù)中比較頻繁（一天的trace記錄）：
- select COUNT(0) from fn_trace_gettable('F:\perfmon\Trace_xxxx_20110406A.trc',default)
- where TextData like '%@P0_ varchar(7),@P1_ datetime,@P2_ datetime,@P3_ varchar(7),@P4_ datetime%'
- select COUNT(0) from fn_trace_gettable('F:\perfmon\Trace_xxxx_20110406A.trc',default)
- where TextData like '%@SMESSAGE varchar(8000),@SINMATERECID varchar(18),@SREFRECID varchar(8000)%'
一天的死鎖次數(shù)大概有20次左右，Update一次只有一條記錄，但是為啥會(huì)出現(xiàn)如此頻繁的死鎖呢？ 除了這個(gè)表本身的數(shù)據(jù)量大
以及查詢超級(jí)變態(tài)之外（后面發(fā)現(xiàn)是主因），還有沒(méi)有其他的原因呢？
最后，實(shí)在找不出問(wèn)題所在，將問(wèn)題反映到微軟，和微軟的人經(jīng)過(guò)幾天的溝通，最終給出的結(jié)果是數(shù)據(jù)庫(kù)的Bug（吐血，運(yùn)氣真好呀），微軟回答如下：
問(wèn)題分析：
========
您的數(shù)據(jù)庫(kù)版本是：Microsoft SQL Server 2005 - 9.00.4207.00 (Intel IA-64) Enterprise Edition，SP3 CU1
我檢查了您提供的死鎖相關(guān)信息后發(fā)現(xiàn)，如您所說(shuō)，您的這個(gè)死鎖問(wèn)題正是SQL2005的Bug所引起，詳細(xì)可以參考文檔：
處理方法：
============
您可以單獨(dú)安裝SP3 CU6，也可以直接安裝SP4來(lái)解決您的這個(gè)問(wèn)題
SP3 CU6下載地址：
SP4下載地址：
您的SQL Server是IA64的版本，所以請(qǐng)選擇正確對(duì)應(yīng)的安裝文件
-------補(bǔ)充---
微軟雖然給出了一個(gè)可能的原因（還不知道靠不靠譜），但是基于目前系統(tǒng)的情況，boss不建議打補(bǔ)?。ㄒ舻蕉ㄆ诰S護(hù)的時(shí)候再做），于是要我提改進(jìn)方案，有了以上的追蹤信息，再來(lái)提改進(jìn)方案就不是什么難事了，于是mail給了boss：
根據(jù)這些信息，我們可以知道：
死鎖主要發(fā)生在表Rec_main上，這個(gè)表的數(shù)據(jù)量有700多萬(wàn)；
主要是由一個(gè)Update和一個(gè)Select語(yǔ)句引起了死鎖，這兩條語(yǔ)句運(yùn)行頻率比較高，并且查詢語(yǔ)句非常長(zhǎng)（見(jiàn)附件，這樣的查詢不可能使用到索引）；
主要問(wèn)題出在這個(gè)復(fù)雜的查詢和表的數(shù)據(jù)量上（還包括微軟說(shuō)的bug）；
目前這種死鎖在我們數(shù)據(jù)庫(kù)里面還是頻繁的發(fā)生。
為處理這種情況，有以下建議：
業(yè)務(wù)上，是否能夠?qū)⒃摫淼男畔⒎珠_(kāi)，減少數(shù)據(jù)量；
開(kāi)發(fā)人員能否改進(jìn)這個(gè)查詢語(yǔ)句；
查詢是否可以考慮加上with（nolock），Update 語(yǔ)句可以加上 with（rowlock）；
其他（考慮分區(qū)表等）。
最終，將表中數(shù)據(jù)搬移掉一部分，修改了查詢的語(yǔ)句，同時(shí)加上了with（nolock），問(wèn)題得到解決（至于微軟的方案，要見(jiàn)下回分解了）
分享題目：淺談一次惱火的死鎖追蹤經(jīng)歷
分享網(wǎng)址：http://m.5511xx.com/article/djoegij.html
