首页 > 数据库技术 > 详细

中国人寿数据库死锁处理

时间:2015-07-30 22:55:03      阅读:249      评论:0      收藏:0      [点我收藏+]
请求锁(request,肯定是后执行的)的SQL是直接能查到的,但加载锁(block,肯定是先执行的)的SQL是通过v$lock表找不到的,因为锁信息只记录了发起锁的session信息,而没有具体SQL信息。但通过一些方法可以定位:
假设有两个session分别执行SQL,第一个session修改了deptno=10和deptno=20的记录,但未提交,这时候会有锁:
技术分享
技术分享
 
接下来第二个session也尝试修改deptno=10的记录:
技术分享
 
可以看到,请求加锁发生等待的SQL是782session的实际请求锁的SQL,但已加载锁的session 19执行的SQL是最后一次执行的修改deptno=20的SQL。所以我们无法直接查到首先加锁的SQL。
但我们可以从v$sql中查找first_load_time对比CTIME的时间进行比较,就能定位具体SQL:
技术分享
 

但既然发生了锁竞争,肯定就是对同一条记录进行处理的冲突,所以实际上等待锁和之前的加锁的SQL应该是类似的

中国人寿数据库死锁处理

原文:http://www.cnblogs.com/iyoume2008/p/4690779.html

(0)
(0)
   
举报
评论 一句话评论(0
关于我们 - 联系我们 - 留言反馈 - 联系我们:wmxa8@hotmail.com
© 2014 bubuko.com 版权所有
打开技术之扣,分享程序人生!