rebuild index online的锁机制浅析(续)

上一篇文章介绍了Oracle10.2.0.4中rebuild index online的锁机制,在开始和结束的时候需要对表加一个模式为4的TM锁,导致在这两个时刻会短暂的阻塞DML。到了Oracle11g,这种情况有所变化,还是通过同样的实验来观察一下Oracle11g到底做出了怎样的改进,对于DBA来说又有怎样的好处。实验环境为Oracle11.1.0.6

session 1:

SQL> delete from t where object_id=28;

1 row deleted.

session 2:

SQL> alter index ix_t rebuild online;

session 2同样被挂起,查看v$lock:

SQL> select sid,type,id1,id2,lmode,request from v$lock where type in('DL','TM','TX'); 

       SID TY        ID1        ID2      LMODE    REQUEST
---------- -- ---------- ---------- ---------- ----------
       137 DL      13596          0          3          0
       137 DL      13596          0          3          0
       137 TX     458781        377          0          4
       170 TM      13596          0          3          0
       137 TM      13596          0          2          0
       137 TM      13599          0          4          0
       170 TX     458781        377          6          0
       137 TX     524304        402          6          0

其中170为session 1,137为session 2。可以看到session 2正在请求一个模式为4的TX锁,注意和Oracle10.2.0.4请求的TM锁是不一样的,而且在我们以前的概念中,TX锁的模式都是6,这里出现了模式4的TX锁请求,应该是Oracle11g中新引入的。那么模式4的TX锁和TM锁有什么不同呢?我们继续前面的实验步骤:

session 3:

SQL> delete from t where object_id=46;

1 row deleted.

session 3的DML操作顺利完成,没有被阻塞。而在10g当中,session 3是会被session 2请求的TM锁所阻塞的,这一点改进是非常有意思的,这样即使rebuid online操作被session 1的长事务阻塞,其他会话的DML操作,只要不和session 1冲突,都可以继续操作,在Oracle10g及以前版本中的执行rebuild index online而造成锁等待的风险被大大的降低了。

接下来在session 1执行rollback,观察rebuild index online执行期间的锁的情况,136是session 3:

       SID TY        ID1        ID2      LMODE    REQUEST
---------- -- ---------- ---------- ---------- ----------
       137 DL      13596          0          3          0
       137 DL      13596          0          3          0
       137 TM      13596          0          2          0
       137 TM      13599          0          4          0
       136 TM      13596          0          3          0
       136 TX     327684        414          6          0
       137 TX     524304        402          6          0
       137 TX     524321        402          6          0

等待一段时间,rebuild index online临近结束,再次观察锁的情况:

       SID TY        ID1        ID2      LMODE    REQUEST
---------- -- ---------- ---------- ---------- ----------
       137 DL      13596          0          3          0
       137 DL      13596          0          3          0
       137 TX     327684        414          0          4
       137 TM      13596          0          2          0
       137 TM      13599          0          4          0
       136 TM      13596          0          3          0
       136 TX     327684        414          6          0
       137 TX     524304        402          6          0

可以看到session 2又在请求一个模式为4的TX锁,同样的,这个锁也不会阻塞其他的DML。由于session 3的事务没有提交,session 2被阻塞,这时再将session 3执行提交或者rollback,则session 2的rebuild立即完成。

Oracle11g在很多细节方面确实做了不少的优化,而且像这样的优化,对于提高系统的高可用性的好处是不言而喻的,在Oracle11g中,执行rebuild index online的风险将比10g以及更老版本中小得多,因为从头至尾都不再阻塞DML操作了,终于可以算得上名副其实的online操作了。



无觅相关文章插件,快速提升流量

一条评论

  • At 2011.04.15 16:54, wxh said:

    good job


    (Required)
    (Required, will not be published)