码迷,mamicode.com
首页 > 数据库 > 详细

定位数据库死锁,和初步解决死锁办法(后发制人)

时间:2015-01-08 19:27:24      阅读:284      评论:0      收藏:0      [点我收藏+]

标签:

1.目前我只是在sql 2008上实验成功:

在数据库开启跟踪标识:

DBCC TRACEON(1204,-1)
DBCC TRACEON(1222,-1)

这两个跟踪标记都是将死锁写到错误日志中,不过1204是以文本格式进行,而1222是以XML格式保存。

开启后通过查看数据库日志文件就可以找到是那个语句引发死锁。

1.模拟一个死锁:

 1 DBCC TRACEON(1204,-1)
 2 DBCC TRACEON(1222,-1)
 3 
 4 CREATE TABLE Lock1(C1 int default(0));
 5 CREATE TABLE Lock2(C1 int default(0));
 6 INSERT INTO Lock1 VALUES(1);
 7 INSERT INTO Lock2 VALUES(1);
 8 
 9 将以下脚本分别打开到两个查询分析器窗口中:
10 
11 1.
12 Begin Tran
13   Update Lock1 Set C1=C1+1;
14   WaitFor Delay 00:01:00;
15   SELECT * FROM Lock2
16 Rollback Tran;
17 
18 2.
19 Begin Tran
20   Update Lock2 Set C1=C1+1;
21   WaitFor Delay 00:01:00;
22   SELECT * FROM Lock1
23 Rollback Tran;

依次执行完毕后,稍后片刻会出现死锁详情:

技术分享

此时我们查看数据库日志:

技术分享

此时死锁有了,数据库日志也有了。万事俱备咱开始结合死锁说明和日志着手分析:

死锁通俗说明:

  在死锁发生的时候,进程为54执行的sql语句和另外一个进程的sql语句共同光合作用下产生了死锁,但是系统会选择一个轻量级的进程当做牺牲品,干掉了这个进程,但是由于造成死锁的恰恰是另外一个进程的sql语句。所以必须首先找到另外一个进程的sql语句,死锁解决就指日可待了。

结合当前死锁说明,我们就知道,进程为54的这条不是造成死锁的原因,那么就是 日志文件里面进程为53的这条sql语句诱发了死锁。

1 进程53所执行的sql语句:
2 
3 Begin Tran
4   Update Lock1 Set C1=C1+1;
5   WaitFor Delay 00:01:00;
6   SELECT * FROM Lock2
7 Rollback Tran;

针对症结对症下药:

  结合网上的资料,使用with(nolock)来解决。with(nolock)只是针对select引发的死锁有效,并且对有可能产生的脏读不是很在意的时候可以采用此办法,否则还得另寻他路。

具体如下:

  

Begin Tran
  Update Lock1 Set C1=C1+1;
  WaitFor Delay 00:01:00;
  SELECT * FROM Lock2 whth(nolock)
Rollback Tran;

此时在将模拟死锁的sql脚本在如法炮制一次你会发现,就不会出现死锁了如下所示:

技术分享技术分享

以上针对sql的见解纯属本人愚见,同时也希望能够抛砖引玉。有说的不对的地方,还望大家给小弟说一下。

 最后说明一下:

  不足:这种方式只能坐等死锁发生后,开始着手解决。从战略上属于后发。

定位数据库死锁,和初步解决死锁办法(后发制人)

标签:

原文地址:http://www.cnblogs.com/wgx0428/p/4211384.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!