rebuild index online的锁机制浅析.doc.docVIP

一般都说，rebuild index online不阻塞DML操作，这是相对于rebuild index来说的，加上了online，只是在rebuild的期间不阻塞DML，但是在开始和结束阶段还是可能阻塞其他进程的DML的，要弄清楚到底是 阻塞还是不阻塞，何处阻塞，为什么阻塞，还是要从锁的角度来分析。本文实验环境为Oracle 。 Oracle中的锁，一共有6两种模式： 0：none 1：null 空 2：Row-S 行共享(RS)：共享表锁，sub share 3：Row-X 行独占(RX)：用于行的修改，sub exclusive 4：Share 共享锁(S)：阻止其他DML操作，share 5：S/Row-X 共享行独占(SRX)：阻止其他事务操作，share/sub exclusive 6：exclusive 独占(X)：独立访问使用，exclusive 我 们知道，DML操作一般要加两个锁，一个是对表加模式为3的TM锁，一个是对数据行的模式为6的TX锁。只要操作的不是同一行数据，是互不阻塞的。但是 rebuild index online在开始和结束的时候是需要对表加一个模式为4的TM锁的，这个可以很容易通过实验观察到，实验中的测试表t是通过create table t as select * from all_objects生成，并且多次执行insert into t select * from t产生较多的数据，以便延迟rebuild的时间来观察系统中锁的情况： 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---------- -- ---------- ---------- ---------- ----------1643 DL 10599 0 3 01643 DL 10599 0 3 01622 TM 10599 0 3 01643 TM 10599 0 2 41643 TM 10607 0 4 01622 TX 655398 1361 6 0 从 上面的结果可以知道，1622是session 1，1643是session 2，session 2一共出现了4个锁，两个DL锁，一个针对表t的TM锁，一个是online rebuild index时需要的一个中间表的TM锁，中间表用于记录rebuild期间的增量数据，原理类似于物化视图日志，其object_id为10607，这是 一个索引组织表(IOT)，从这里我们也可以发现IOT的优点和适合的场合，这张中间表只有插入，不会有删除和修改操作，而且只有主键条件查询，正是 IOT最合适的场景： SQL select object_name,object_type from all_objects where object_id=10607;OBJECT_NAME OBJECT_TYPE------------------------------ -------------------SYS_JOURNAL_10602 TABLESQL select table_name,iot_type from all_tables where table_name=SYS_JOURNAL_10602;TABLE_NAME IOT_TYPE------------------------------ ------------SYS_JOURNAL_10602 IOT Session 2在请求一个模式为4的TM锁，模式4会阻塞这个表上的所有DML操作，所以这是再往这个表上执行DML也会挂起 session 3： SQL delete from t where object_id=46;SQL select sid,type,id1,id2,lmode,request from v$lock where type in(DL,TM,TX);SID TY ID1 ID2 LMODE REQUEST---------- -- ---------- ---------- ---------- ----------1643 DL 10599 0 3 01643 D