深入剖析：RAC的全局死锁问题

杨廷琨（yangtingkun）

云和恩墨 CTO

高级咨询顾问，Oracle ACE 总监，ITPUB Oracle 数据库管理版版主

RAC的全局死锁时间检测

对于单实例数据库而言，死锁的检测在秒级完成，而RAC环境则死锁的检测时间默认达到了1分钟。单实例环境如果出现了死锁，那么马上其中一个进程就被中止，用户可以快速的得到错误返回。而对于RAC而言，死锁的检测并不是实时完成，而是需要60秒左右的时间。

会话1执行：

会话2执行：

此时，会话2等待会话1的最终操作，下面会话1更新被会话2锁定的行，引发死锁：

可以看到，死锁的超时检测为1分钟。 而这个死锁的检测时间是可以调整的，Oracle通过隐含参数_lm_dd_interval控制：

再次测试死锁的检测时间，会话1：

会话2执行更新：

会话1执行更新引发死锁：

SQL> UPDATE t_deadlock SET name = 'b1' WHERE id = 2;

大约30秒后，会话2报错ORA-60：

在10.2.0.2版本上，Oracle存在一个bug，允许这个参数设置为0，在10.2.0.3以后，这个bug被修正，如果设置为0后，则数据库无法正常启动：

最后修改隐含参数是Oracle不推荐的，而且修改这个参数势必会影响RAC的正常工作方式导致LDM进程的繁忙度增加，而且可能影响RAC环境的稳定性和可用性。 如果确实对于前台的死锁检查时间要求较高，建议在测试环境中详细测试后再部署到产品环境中。

设置全局死锁优先级

测试控制全局死锁的隐含参数_lm_dd_interval时，突然想到这个问题。Oracle的死锁判断是没有优先级的，也就是说，当两个或多个会话发生死锁的时候，无法指定牺牲哪个会话，而是由Oracle随机决定。

不过对于RAC环境而言，死锁的检查不在是内部的随机实现，Oracle通过隐含参数_lm_dd_interval来控制死锁的检测时间。更重要的是，对于RAC环境而言，Oracle允许不同实例设置不同的值。而不同实例的检测死锁间隔不同，就意味着优先级的出现。

如果实例1上设置该值为默认值60秒，而实例2设置为30秒，那么当发生死锁后，永远是实例2上先检测到死锁，也就是说，实例2上会话会被牺牲掉。这是两个实例上设置该参数相同的情况，两个会话分别连接到两个实例，产生死锁。

实例1上的会话1：

在实例2上连接会话2：

会话1上锁定记录2，产生死锁：

I1S1> UPDATE t_deadlock SET name = 'b1' WHERE id = 2;

第一次是实例2上的会话2被牺牲报错：

可以看到，会话2等待30秒后报错，此时会话2执行同样的语句再次引发死锁：

这次变成实例1上的会话1被牺牲报错，可以看到，会话1经历了两次死锁检测，因此执行时间为1分钟。会话1再次引入死锁：

被牺牲的又变成了会话2。 上面这个测试是在两个实例的_lm_dd_interval参数设置相同的情况下，下面修改实例2上的参数设置为5秒：

实例2参数生效后连接会话更新该表，实例1上的会话1取消之前的修改，重新进行更新：

下面在实例2上的会话2，引入死锁：

显然由于不同实例的_lm_dd_interval参数的值设置不同，现在每次死锁都会在设置值更小的实例2上被检测，实例2上的会话每次都会被死锁牺牲掉。尝试设置不同的参数值在不同实例上设置死锁检测优先级获得成功。

----the end