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操作了。
rebuild index online的锁机制浅析
一般都说，rebuild index online不阻塞DML操作，这是相对于rebuild index来说的，加上了online，只是在rebuild的期间不阻塞DML，但是在开始和结束阶段还是可能阻塞其他进程的DML的，要弄清楚到底是阻塞还是不阻塞，何处阻塞，为什么阻塞，还是要从锁的角度来分析。本文实验环境为Oracle 10.2.0.4。
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 0
1643 DL 10599 0 3 0
1622 TM 10599 0 3 0
1643 TM 10599 0 2 4
1643 TM 10607 0 4 0
1622 TX 655398 1361 6 0
db link与read only
如果Oracle数据库是以read only模式打开的，则无法通过db link访问远程数据库。因为只要通过db link，即使只执行select，oracle也是要开启分布式事务支持的，事务需要分配回滚段，而read only模式下是没有online的回滚段的：
SQL>select 1 from dual@lnk_db1;
select 1 from dual@lnk_db1
*
ERROR at line 1:
ORA-16000: database open for read-only access
在一个read write的库上做个测试，可以看到通过db link的查询确实开启了事务，并且分配了回滚段。
SQL>select sid from v$mystat where rownum=1;
SID
----------
1270
SQL>select 1 from dual@lnk_db1;
1
----------
1
SQL>select s.sid,s.serial#,s.sql_hash_value,
2 r.segment_name,
3 t.xidusn,
4 t.xidslot,
5 t.xidsqn
6 from v$session s,
7 v$transaction t,
8 dba_rollback_segs r
9 where s.taddr = t.addr
10 and t.xidusn = r.segment_id(+);
SID SERIAL# SQL_HASH_VALUE SEGMENT_NA XIDUSN XIDSLOT XIDSQN
---------- ---------- -------------- ---------- ---------- ---------- ----------
1270 37655 0 _SYSSMU10$ 10 45 2042124
可以看到session 1270虽然只执行了一条select语句，但是由于使用了db link，确实开启了一个活动事务，并且分配了一个回滚段_SYSSMU10$。
Update：七公提醒了一下，实际上还是有办法绕过这个问题的。Oracle提供了read only的事务，是无须用到回滚段的。
SQL>select 1 from dual@lnk_db1;
select 1 from dual@lnk_db1
*
ERROR at line 1:
ORA-16000: database open for read-only access
SQL>set transaction read only;
Transaction set.
SQL>select 1 from dual@lnk_db1;
1
----------
1
参考：Note:437254.1 Ora-16000 Generated Selecting DB Link On Read Only Database.
Data Guard与nid
使用nid可以修改一个库的db_name和dbid。当然，如果dbid变更，则需要resetlogs才能打开数据库，因为oracle在内部其实是通过dbid来区分一个数据库的，而只修改db_name的话，则可以noresetlogs。
对于Data Guard环境来说，如果变更了主库的db_name，备库怎么处理？因为db_name不但存在于控制文件中，在每个数据文件的头部也有标识，而备库是不允许执行nid来更名的：
$ nid TARGET=/ DBNAME=test SETNAME=Y DBNEWID: Release 10.2.0.4.0 - Production on Mon Aug 18 13:25:50 2008 Copyright (c) 1982, 2007, Oracle. All rights reserved. Connected to database TEST (DBID=47959353) NID-00131: Control file is not current Change of database name failed during validation - database is intact. DBNEWID - Completed with validation errors.
但如果主库只是要变更db_name的话，备库是不必重做的，只要从主库重新生成备库控制文件即可。此时备库可以继续恢复主库传过来的归档，但是数据文件头部的某个位置还是会保留原来的db_name，只有在备库切换成主库的时候，才会根据控制文件去更新数据文件头。
主库从test更名为test2后，即使重建备库控制文件，备库的数据文件头中的db_name还是保持不变：
$ strings system.dbf | head -n 5
}|{z
TEST
SYSTEM
_SYSSMU1$
_SYSSMU2$
备库在切换成主库以后，文件头中的db_name更新成新的test2：
$ strings system.dbf | head -n 5
}|{z
TEST2
SYSTEM
_SYSSMU1$
_SYSSMU2$
这样虽然看起来不会有什么太大的问题，只是一个标识字段不一样，甚至主库的某个datafile损坏，一样可以复制备库的datafile过来替代。但主备库的数据文件的文件头中存在这么一个不一致，总是一个潜在的风险点，谁知道哪天又触发到oracle的什么bug了。
另外，原备库的临时文件需要重建，因为切换新的主库以后，tempfile的文件头不会根据控制文件修改成新的db_name。
最后附上使用nid修改db_name而不修改dbid的操作步骤(摘自Note:224266.1)：
1. Backup the database
2. SHUTDOWN IMMEDIATE of the database
3. STARTUP MOUNT
4. Open one session and run NID with sysdba privileges
% nid TARGET=SYS/password@test_db DBNAME=test_db2 SETNAME=Y
– the value of DBNAME is the new dbname of the database
– SETNAME must be set to Y. The default is N and causes the DBID to be changed also.
5. shutdown IMMEDIATE of the database
6. Set the DB_NAME initialization parameter in the initialization parameter
file to the new database name
7. Create a new password file
8. Startup of the database(without resetlogs)
