深入剖析:RAC的全局死锁问题
Posted 数据和云
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了深入剖析:RAC的全局死锁问题相关的知识,希望对你有一定的参考价值。
杨廷琨(yangtingkun)
云和恩墨 CTO
高级咨询顾问,Oracle ACE 总监,ITPUB Oracle 数据库管理版版主
编辑手记:数据库的死锁问题可能大家并不陌生,那么单实例和RAC数据库中,死锁有什么区别呢,如何避免RAC的全局死锁呢,我们拣选了老杨的博客,跟大家一起分享。
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
如何加入"云和恩墨大讲堂"微信群
关注本微信(OraNews)回复关键字获取
2016DTCC, 2016数据库大会PPT;
DBALife,"DBA的一天"精品海报大图;
12cArch,“Oracle 12c体系结构”精品海报;
DBA01,《Oracle DBA手记》第一本下载;
YunHe,“云和恩墨大讲堂”案例文档下载;
以上是关于深入剖析:RAC的全局死锁问题的主要内容,如果未能解决你的问题,请参考以下文章