rebuild index online的锁机制浅析(续)
2008-11-22 22:39
309 查看
上一篇文章介绍了Oracle10.2.0.4中rebuild index online的锁机制,在开始和结束的时候需要对表加一个模式为4的TM锁,导致在这两个时刻会短暂的阻塞DML。到了Oracle11g,这种情况有所变化,还是通过同样的实验来观察一下Oracle11g到底做出了怎样的改进,对于DBA来说又有怎样的好处。实验环境为Oracle11.1.0.6。
session 1:
session 2:
session 2同样被挂起,查看v$lock:
其中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:
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:
等待一段时间,rebuild index online临近结束,再次观察锁的情况:
可以看到session 2又在请求一个模式为4的TX锁,同样的,这个锁也不会阻塞其他的DML。由于session
3的事务没有提交,session 2被阻塞,这时再将session 3执行提交或者rollback,则session
2的rebuild立即完成。
Oracle11g在很多细节方面确实做了不少的优化,而且像这样的优化,对于提高系统的高可用性的好处是不言而喻的,在Oracle11g中,执
行rebuild index
online的风险将比10g以及更老版本中小得多,因为从头至尾都不再阻塞DML操作了,终于可以算得上名副其实的online操作了。
--EOF--
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操作了。
--EOF--
相关文章推荐
- rebuild index online的锁机制浅析
- rebuild index online的锁机制浅析(续)
- rebuild index online的锁机制浅析
- create/rebuild index online不要轻易cancel或killed
- alter index rebuild与alter index rebuild online的区别
- alter index rebuild online引发的血案
- rebuild index 的机制
- rebuild index VS. rebuild index online
- alter index rebuild online引发的血案
- alter index rebuild与alter index rebuild online的区别
- alter index rebuild与alter index rebuild online的区别
- alter index rebuild和alter index rebuild online的区别
- rebuild index online的锁机制浅析
- 转alter index rebuild online引发的血案
- alter index rebuild & alter index rebuild online
- index rebuild online 工作日志
- alter index rebuild & alter index rebuild online
- oracle alter index rebuild online和alter index rebuild的区别
- Online rebuild index遭遇ORA-08104
- Oracle index rebuild online 与 rebuild 及 drop index 后重建