位置: 编程技术 - 正文
Sql Server 死锁的监控分析解决思路(sql死锁的简单例子)
编辑：rootadmin推荐整理分享Sql Server 死锁的监控分析解决思路(sql死锁的简单例子)，希望有所帮助，仅作参考，欢迎阅读内容。
文章相关热门搜索词:sql死锁的原因及解决方法,sql数据库死锁查询,sqlserver死锁解决,sqlserver 死锁解决方案,sql server 死锁的发生和解决方法,sql死锁的简单例子,sqlserver死锁解决,sql server 死锁的发生和解决方法,内容如对您有帮助，希望把文章链接给更多的朋友！
1 背景
1.1 报警情况
最近整理笔记，打算全部迁移到EVERNOTE。整理到锁这一部分，里边刚好有个自己记录下来的案例，重新整理分享下给大家。
某日中午，收到报警短信，DB死锁异常，单分钟死锁个。
死锁的xml文件如下：
表格结构跟模拟数据如下：
1.2 如何监控
捕获死锁有多种方式可以捕获，这里介绍2种：SQL SERVER Profiler工具跟Extended Events。Profiler相对比较耗资源，但是由于只监控死锁这一项，所以性能影响不是很大，其可视化界面较易上手；Extended Events耗费资源较少，实时记录到倒数第二个死锁，同时需要SQL语句来分析查询记录文件。
如何使用 Profiler监控？
打开 SSMS，点击<工具>，选择 <SQL Server Profiler>，如下图。
登录到需要监控的DB实例，填写相应的跟踪属性，首先是<常规>页面,如下图。这里注意2个方面，第一，选择 <TSQL-Locks>模板，这个模板即可以用来监控死锁，也可以拿来观察 锁申请与释放情况，非常详细，有事没事可以多拿来看SELECT UPDATE DELETE等语句对锁的申请及释放情况；第二，监控结果存储，建议可以存放到某个表格中去，方便定期分析与统计。
接着填写<事件选择>项，只需要选择 <deadlock graph> Events，其他都不需要打勾，最后点击运行就可以开始监控了。
可以用一个万年常用的例子来检查是否监控正常，开3个查询窗口，按照以下顺序执行则会发生资源占用及申请互斥导致死锁，执行完第5步，等待1-3s则发生死锁。脚本提供如下：
监控到的死锁界面如下：
如何使用Extended Events监控？
建立扩展事件监控的脚本如下：（扩展事件很赞，版支持可视化操作，感兴趣的可以上 MSDN了解: SERVER对xml的支持也是棒棒哒，期待版中的json支持）
是不是很清晰，一目了然，有了这个就可以去分析拉！
2 分析
根据xml文件内容或者扩展事件的监控内容，都可以整理为以下信息（开头的那个死锁分析）：
查看事务1及事务2的执行计划如下：
结合表格及执行计划，可以大致推测死锁过程：
会话1：
根据主键SeqCode查找到键值所在的 索引页 Index_Page，找到该页上面的 keyhashvalue 键值行 Index_key，对Index_Page持有IU锁，对Index_key持有U锁； 由于该表是堆表，bookmark lookup是通过 RID查找 ，即通过行标识符查找，找到RID所对应的行数据所在的 数据页 Data_Page，然后在该页面上找到RID指向槽号上的行数据，对该行数据持有U锁； 这个时候，已经查找到了需要更新的行数据，可以把数据页 Data_Page上的IU锁 升级为IX锁，RID指向的行数据 从U锁升级为X锁，升级结束后，释放索引页跟键值行上面的 IU锁及U锁。 则此时，会话1 持有 Data_Page 上的IX锁、RID行上的 X锁.这个过程中，刚好会话2进行这样的锁申请：
找出事务2中持有锁资源是哪个索引，可以根据sys.partitions 可以查看到是主键pk_FinanceReceiptNoRule，主键列是：SeqCode。 根据主键SeqCode查找到键值所在的 索引页 Index_Page，找到该页上面的 键值行 Index_key，对Index_Page持有IU锁，对Index_key持有U锁； 由于该表是堆表，bookmark lookup是通过 RID查找 ，即通过行标识符查找，找到RID所对应的行数据所在的 数据页 Data_Page，然后在该页面上找到RID指向槽号上的行数据，准备该行数据持有U锁，但是发现RID行上被会话1持有了X锁，导致其申请 U锁 Timeout。 则此时 会话2 持有 Index_Page上的IU锁、Index_key上的U锁、Data_Page上的IU锁，请求 RID行的 U锁。假设这个时候，会话1 中又执行了一次update操作（同一个事务中）：
根据主键SeqCode查找到键值所在的 索引页 Index_Page，找到该页上面的 键值行 Index_key，对Index_Page持有IU锁，准备对Index_key持有U锁，但是发现 Index_key被会话2持有了U锁。
那么这个时候死锁就产生了(详见下图)：
会话1 持有 Data_Page 上的IX锁、RID行上的 X锁，申请 Index_key 的U锁（等待会话2释放） 会话2 持有 Index_Page上的IU锁、Index_key上的U锁、Data_Page上的IU锁，请求 RID行的 U锁（等待会话1释放）
3 解决
想法子除去RID查找，直接index就找到数据，就不会发生这个死锁，也就是，在主键上面重新建立聚集索引，丢弃原先的非聚集索引主键。因为这样排除了RID的U锁申请与持有，直接是保持X锁 直至事务结束，同时可以直接根据主键来修改键值所在的数据页，减少的RID查询行的时间。
修改后的执行计划如下：
其锁申请释放的流程如下(详见截图)：
根据主键SeqCode查找到键值所在的 索引页 Index_Page，找到该页上面的 keyhashvalue 键值行 Index_key，对Index_Page持有IU锁，对Index_key持有U锁； 由于该表已经是聚集索引表，主键所在的页上包含 行数据，则可以直接 对Index_Page持有IU锁升级为IX锁，对Index_key持有U锁升级为X锁，避免了RID逐个找行数据的锁申请
标签: sql死锁的简单例子
本文链接地址:https://www.jiuchutong.com/biancheng/324371.html 转载请保留说明！
