关于SQL server2005+SP3的死锁的一次诊断过程

关于SQL server2005+SP3 的死锁的一次诊断过程

 

有puber 在SQLServer 版发了一个帖子SQL server2005+Sp3的死锁问题 ，因最近正在研究SQLServer 的一些问题，出于兴趣决定试试看能不能帮助这位pubber 。

问题描述 ：

我的程序为多线程，同时最多20 个线程。

20 个线程同时向一个表中做insert 操作，但是各线程之间的记录不可能重复（主键肯定不一样），但是还是报死锁，同样的程序连oracle 运行时却很正常。

各高人给指出个明路啊。

问题分析：

因为只有这些简单的介绍，很难去定位和诊断问题所在，所以我一开始 建议启用他 1204 和 1222 跟踪标志，通过日志把死锁描述信息详细列出来；或者用 SQL Server Profiler 的定制事件跟踪。

他回复 SQL Server Profiler 的定制事件跟踪 Deadlock graph 得到一个关于健锁的描述

以下为死锁图：

以下为 SQLServer 日志信息：

下面是日志查看器中的信息，应该对应 已用日志 1160 和已用日志 1084 吧。 ----------------------------------------------------------------------------    日期                 2011-1-14 11:15:11 日志                 SQL Server ( 当前 - 2011-1-14 11:15:00) 源                 spid21s 消息 process id=processb793d8 taskpriority=0 logused=1084 waitresource=KEY: 9:72057594058113024 (c601cdd76f20) waittime=4984 ownerId=944254 transactionname=INSERT lasttranstarted=2011-01-14T11:15:06.500 XDES=0x8ee8a88 lockMode=S schedulerid=2 kpid=7384 status=suspended spid=69 sbid=0 ecid=0 priority=0 transcount=1 lastbatchstarted=2011-01-14T11:15:06.500 lastbatchcompleted=2011-01-14T11:15:06.497 clientapp=jTDS hostname=WIN7-PC hostpid=123 loginname=ipcc isolationlevel=read committed (2) xactid=944254 currentdb=9 lockTimeout=4294967295 clientoption1=671219744 clientoption2=128056 ----------------------------------------------------------------------------------- 日期                 2011-1-14 11:15:11 日志                 SQL Server ( 当前 - 2011-1-14 11:15:00) 源                 spid21s 消息 process id=processaea988 taskpriority=0 logused=1160 waitresource=KEY: 9:72057594058113024 (3002597d4e10) waittime=4984 ownerId=944255 transactionname=INSERT lasttranstarted=2011-01-14T11:15:06.500 XDES=0x7e3ea88 lockMode=S schedulerid=1 kpid=4208 status=suspended spid=79 sbid=0 ecid=0 priority=0 transcount=1 lastbatchstarted=2011-01-14T11:15:06.500 lastbatchcompleted=2011-01-14T11:15:06.497 clientapp=jTDS hostname=WIN7-PC hostpid=123 loginname=ipcc isolationlevel=read committed (2) xactid=944255 currentdb=9 lockTimeout=4294967295 clientoption1=671219744 clientoption2=128056

初步分析了一下以上日志和图形：

表面提示是一个共享锁和排他锁相互冲突了，即读写和写读冲突

session1     session2

共享锁

                  排它锁

排它锁

                  共享锁

       经过询问和分析，的确是发生在主键上，我怀疑是触发器问题，触发器中执行时间过长， 或者在程序中进行主键生成的过程中，又重复从该表中进行读取。所以想进一步了解表结构、触发器脚本和主键生成的脚本。

问题解决：

       经过几轮折腾，终于他 找到了问题所在，“原来是其他人在这个表中建立了触发器，我不知道，并且这个触发器还访问了这个表。”，去掉触发器，问题消失。

       死锁常见的场景是读写写读冲突，循环引用会造成相互资源的排斥，同时资源得不到释放，建议解决方式，是缩短事务处理时间，减少循环引用等等方法。