Monthly Archives: June 2012

测试控制全局死锁的隐含参数_lm_dd_interval时，突然想到这个问题。 RAC全局死锁检测时间：https://yangtingkun.net/?p=955 Oracle的死锁判断是没有优先级的，也就是说，当两个或多个会话发生死锁的时候，无法指定牺牲哪个会话，而是由Oracle随机决定。 不过对于RAC环境而言，死锁的检查不在是内部的随机实现，Oracle通过隐含参数_lm_dd_interval来控制死锁的检测时间。更重要的是，对于RAC环境而言，Oracle允许不同实例设置不同的值。而不同实例的检测死锁间隔不同，就意味着优先级的出现。 如果实例1上设置该值为默认值60秒，而实例2设置为30秒，那么当发生死锁后，永远是实例2上先检测到死锁，也就是说，实例2上会话会被牺牲掉。 这是两个实例上设置该参数相同的情况，两个会话分别连接到两个实例，产生死锁。实例1上的会话1： SQL> SELECT name FROM v$database; NAME ——— ORCL SQL> SELECT instance_number, instance_name FROM v$instance; INSTANCE_NUMBER INSTANCE_NAME ————— —————- 1 orcl1 SQL> SET sqlp ‘I1S1> ‘ I1S1> SHOW parameter _lm NAME TYPE VALUE ———————————— ———– … Continue reading →

对于单实例数据库而言，死锁的检测在秒级完成，而RAC环境则死锁的检测时间默认达到了1分钟。 对于单实例环境如果出现了死锁，那么马上其中一个进程就被中止，用户可以快速的得到错误返回。而对于RAC而言，死锁的检测并不是实时完成，而是需要60秒左右的时间。 会话1执行： SQL> CREATE TABLE t_deadlock (id NUMBER PRIMARY KEY, name varchar2(30)); TABLE created. Elapsed: 00:00:00.12 SQL> INSERT INTO t_deadlock VALUES (1, ‘a’); 1 ROW created. Elapsed: 00:00:00.00 SQL> INSERT INTO t_deadlock VALUES (2, ‘b’); 1 ROW created. Elapsed: … Continue reading →