关于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 wnerId=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 wnerId=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

共享锁

                 排它锁

排它锁

                 共享锁

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

问题解决：

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

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

image002.jpg

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/6517/viewspace-683949/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/6517/viewspace-683949/