关闭

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

1205人阅读 评论(6) 收藏 举报

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

 

puberSQLServer 版发了一个帖子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

共享锁

                  排它锁

排它锁

                  共享锁

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

问题解决:

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

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

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:768264次
    • 积分:9994
    • 等级:
    • 排名:第1785名
    • 原创:221篇
    • 转载:16篇
    • 译文:3篇
    • 评论:767条
    最新评论
    友情链接