中国人寿数据库死锁处理

请求锁(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应该是类似的