一次死锁追踪经历

   最近，刚跳槽到一新公司，就遇到生产数据库晚上突然出现大面积中断，并持续近一小时，而发生事故时，我没有在现场，
错过了直接获取信息的机会；过后boss要求追查原因，于是艰难的排查过程开始了。
   开始以为是数据库某个JOB运行出现异常引起或者是因为程序里面哪个鸟人写了垃圾语句造成了大面积的死锁，于是将收集
的trace信息拿到本地分析，从收集到的trace信息看，数据库在19：49：28时出现了锁，系统cancel了它，而且是连续三个，
之后数据库大部分连接都是Abort了。
 
   
   初步估计应该是死锁了，首先想到的就是因为数据库更新语句造成，于是查找Agent里面是否有对应时间的JOB运行，
结果没有匹配的，然后分析trace文件里面是否有该时间段内运行的长Update、Insert或者Delete语句，查了半天也没
发现，汗。。。，调查长查询，还是没有，狂汗。。。

   Trace文件分析来分析去也没办法定位到具体语句（Trace 文件中只抓取了运行时间超过2秒或者读大于10000的记录），看来
问题不是那么简单了；光根据Trace文件信息想要找到凶手估计不可能了，于是把Windows日志和数据库错误日志都查了一遍，也
没有发现任何异常，难道是无头案。。。（没查到任何信息，担心饭碗不保了）

   想来想去，也问了一些牛人，都没有啥结果，看来通过手头上现有的资料估计要找出问题是没多少希望了，只能另辟蹊径；既
然可以肯定是因为死锁造成的，那说明数据库里面肯定存在资源的不一致访问或者竞争，那就从死锁下手，于是先清空掉当前的数
据库错误日志文件，再打开1204和1222跟踪标志，等待鱼儿上钩。

			 DBCC errorlog
 DBCC TRACEON (1204, 1222, -1);
 DBCC tracestatus

   收集了几天数据，准备收网了，将ERROR.LOG从服务器拷贝到本地，用UE打开，认真一行行看，找到如下信息：        Deadlock encountered .... Printing deadlock information 果然是死锁，总算找到真凶了，用UE查找一把，不查不知道，一查吓一跳，一堆死锁...     死锁信息如下：  

查看一下页面信息：

			DBCC TRACEON (3604) 
DBCC PAGE('XXXX',1,22664690,3) WITH TABLERESULTS
DBCC TRACEOFF (3604)

这些页面信息都正常。

再根据信息，Input Buf 的信息，反过来查询Trace文件（Input Buffer 只能存放255个字节，信