一. 官网说明
在MOS 上的一篇文章讲到了rebuild online 和offline的区别：
Index Rebuild Is Hanging Or Taking Too Long [ID 272762.1]
Symptoms:
=========
Performance issues while rebuilding very large indexes. The offline rebuilds of their index is relatively quick -finishes in 15 minutes. Issuing index rebuild ONLINE statement => finishes in about an hour. This behavior of ONLINE index rebuilds makes it a non-option for large tables as it just takes too long to scan the table to rebuild the index. The offline may not be feasible due to due to the 24/7 nature of the database. This may be a loss of functionality for such situations. If we attempt to simultaneously ONLINE rebuild the same indexes we may encounter hanging behavior indefinitely (or more than 6 hours).
DIAGNOSTIC ANALYSIS:
--------------------
We can trace the sessions rebuilding the indexes with 10046 level 12. Comparing the IO reads for the index-rebuild and the index-rebuild-online reveals the following:
ONLINE index rebuilds： It scans the base table and it doesn't scan the blocks of the index.
OFFLINE index rebuilds：It scans the index for the build operation.
This behaviour is across all versions.
Cause/Explanation
=============
When you rebuild index online, it will do a full table scan on the base table. At the same time it will maintain a journal table for DML data, which has changed during this index rebuilding operation. So it should take longer time, specially if you do lots of DML on the same table,while rebuilding index online.
-- rebuild index online的时候，会选择全表扫描，同时会维护一个中间日志表，用来记录在rebuild 期间的增量数据，原理类似于物化视图日志，日志表是一个索引组织表(IOT)，这张中间表只有插入，不会有删除和修改操作，而且只有主键条件查询，正是IOT最合适的场景。
--rebuild offline时，选择的6模式的X 锁，它根据old index 来rebuild。 因此不允许进行DML，也就没有中间表。因此也比较块。
Solution/Conclusion:
===========
- The ONLINE index rebuild reads the base table, and this is by design.
- Rebuilding index ONLINE is pretty slow.
- Rebuilding index offline is very fast, but it prevents any DML on the base table.
二. rebuild index 说明
有关锁的模式信息如下：
DML操作一般要加两个锁，一个是对表加模式为3的TM锁，一个是对数据行的模式为6的TX锁。只要操作的不是同一行数据，是互不阻塞的。
在rebuild index online 的开始和结束阶段时，需要短暂的对表持有模式为4的TM锁的，当获取到4级别的锁之后，才降为2级。如果rebuild online一直没获取到4级别的锁,那么相关的DML全部产生等待。 在执行期间只持有模式2的TM锁，不会阻塞DML操作。 在Oracle 11g之后,oracle做了特殊处理,后续的dml不会被rebuild online的4级别锁阻塞.
所以如果在执行rebuild index online前长事务，并且并发量比较大，则一旦执行alter index rebuild online，可能因为长事务阻塞，可能导致系统瞬间出现大量的锁，对于压力比较大的系统，这是一个不小的风险。这是需要迅速找出导致阻塞的会话kill掉，rebuild index online一旦执行，不可轻易中断，否则可能遇到ORA-08104。
MOS 的文档：
Session Was Killed During The Rebuild Of Index ORA-08104 [ID 375856.1]
While running an online index rebuild your session was killed or otherwise terminated abnormally. You are now attempting to run the index rebuild again and is throwing the error:
ORA-08104: this index object ##### is being online built or rebuilt
根据以上说明，我们可以知道在进行online rebuild 的时候，Oracle 会修改如下信息：
（1）修改ind$中索引的flags，将该flags+512. 关于这个flags的含义，在下面的实验中进行说明。
（2）在该用户下创建一个journal table 来保存在rebuild期间的增量数据。 该表明名称: sys_journal_
如果异常结束online rebuild操作，那么oracle就没及时清理journal table和ind$的flags标志位，系统会认为online rebuild还在操作。
当然SMON 进程会来处理这些临时段。 在maclean 同学(10g,11g OCM)的Blog里提到了功能：
对于永久表空间上的temporary segment，SMON会三分钟清理一次(前提是接到post)，如果SMON过于繁忙那么可能temporary segment长期不被清理。temporary segment长期不被清理可能造成一个典型的问题是:在rebuild index online失败后，后续执行的rebuild index命令要求之前产生的temporary s