FreeFire

看了网上很多关于死锁的的博客,大家通常介绍死锁的原理,本人也写一个详细的分析。当然,是关于SQLSERVER的死锁。

使用SQL Profiler抓取死锁事件

2、选择选项卡:事件选择,勾选右下角的显示所有事件,找到Locks事件,勾选上Deadlock graph。

3、再选择第三个选项卡:事件提取设置,勾上死锁XML,弹出文件保存路径,输入文件名即可。

4、以上设置,出现死锁时会保存到死锁XML文件中,经操作发现只保存了最后一个死锁图,如果死锁比较多,需要使用SQL Profiler逐个保存。

5、死锁XML文件默认后缀为.xdl,双击直接打开就会使用SSMS打开,仅仅只能看到很基础的信息。如下:

这种图示并不能详细的说明问题。我们可以采取另外一种办法,左键选择死锁XML文件,右键选择打开方式:文本编辑器。整个死锁的内容就一目了然了,如下:

 

红色的框框,是我标注出来的,我主要对黑色框框里面的做详细说明,其实有很多了解死锁的朋友看了之后基本已经明白了。

1、  每一个死锁XML文件有一个根节点:deadlock-list。

2、  在根节点下,有一个节点deadlock victim="process59bcbc8",其中victim值为死锁的编号,如果打开的一个SQL Profiler下出现多个死锁,那么它们的编号是一致的,只有不同的SQL Profiler追踪的死锁编号才会有不同。此外该值为牺牲的进程ID号,与别的ID号区分,这个在之后会详细介绍。

3、  在deadlock victim节点下有两个节点,process-list,resource-list。process-list节点主要解释死锁的一些相关信息。resource-list节点解释锁的授予情况。

4、  process-list节点,一般有两个process节点,每个节点代表着一个死锁中的一个进程,如果多个进程造成的死锁,那就会出现多个process节点。我们先看第一个process节点,这个节点根据之前的图片可以看出,是被牺牲的进程。

1)属性id="process7a9a988",这个是被牺牲的进程ID号,在文件中我们可以看到两个process节点的ID号不同。另一个节点的id属性为id="process7abee08"

2) 属性waitresource=”PAGE: 7:1:8459005”,Page代表这是一个页锁,这个页面出现在数据库ID=7,文件ID=1,页面ID=8459005的位置。另一个Procee节点下的waitresource="PAGE: 7:1:7861369"。

3) 属性transactionname ="SELECT",表示事务类型,SELECT表示这是一个查询事务,可以跟另一个Procee节点下的transactionname属性进行比较,transactionname="UPDATE"

4) 属性lockMode="S",锁的模式为共享锁。另一个process节点的锁模式lockMode="IX"为意向排他锁。

5) 属性status="suspended",锁的状态。另一个process节点的status="suspended"。

6) 属性hostname="999VISTA"指操作这个事务的电脑名。另一个process节点的hostname="jack"

7) 属性loginname="sa"指登录数据库的SQL账户。另一个process节点的loginname="aaa"。

8) 属性isolationlevel="read committed (2)"指事务隔离级别。

9) 节点executionStack,在它之下有两个frame节点,第一个节点中间的文本是执行语句。第二个节点,没弄明白什么意思。

10) 节点inputbuf,这个节点中间的文本也是执行语句,与executionStack节点下第一个frame节点的文本相同,推测executionStack节点下第二个节点是不是在一个执行进程中其他的SQL语句??

5、  resource-list节点。这个节点下有两个pagelock节点,分别代表两个进程各自持有的页锁。如果有多个页锁,是不是会有多个pagelock节点?或者是表锁那会是什么节点??

1)  第一个pagelock节点,fileid="1" pageid="8459005" dbid="7",这个跟process-list节点下第一个process节点的属性waitresource=”PAGE: 7:1:8459005”意思相同。objectname=” 表名",这个是表名,具体格式:db_name.schema_name.Table_name。

2)  pagelock节点下有多个owner-list节点,这个是每一个进程就有一个节点,该示例中由于死锁是由两个进程造成,只有两个节点。

3)  owner-list节点有一个owner,这个代表着锁的授予情况,推测:如果持有多个锁,可能有多个节点。

4)  owner节点:id="process7abee08" mode="IX",id表示进程ID,mode表示锁类型。

5)  pagelock节点下有多个waiter-list节点,这个节点是与owner-list节点一一对应。

6)  waiter-list节点有一个waiter节点,这个代表着锁的授予情况,推测:如果持有多个锁,可能有多个节点。

7)  waiter节点:id="process7a9a988" mode="S" requestType="wait",id表示进程ID,mode表示锁类型,requestType表示等待授予中。

8)  通过以上的介绍,我们可以了解到:

进程process7a9a988先拥有了Page:7:1:7861369的共享锁S,这个时候,它请求获取Page:7:1:8459005的共享锁S,与此同时,process7abee08先拥有了Page:7:1:8459005的意向排他锁IX,又请求获取Page:7:1:7861369的意向排他锁,这样,两个进程相互阻塞造成了死锁的原因。我对此结合数据库表结构分析,发现该表的每行字段都有6880个字符,也就是说,一行就占用了一个页面,同时,进程process7a9a988使用的是LINQ查询,由于LINQ导致这个查询居然不走聚集索引,先走AccountID字段的索引然后在嵌套循环主键索引CaseID,是死锁的原因之一。

 

 

以上就是本人对死锁的见解,如有异议,欢迎提出讨论。

分类:

技术点:

相关文章: