最近，剛跳槽到一新公司，就遇到生產(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)查詢(xún)，還是沒(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        

        

        
        
      
        
it知識(shí)庫(kù)：一次死鎖追蹤經(jīng)歷，轉(zhuǎn)載需保留來(lái)源！
        
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。