https://blog.csdn.net/daiqiulong2
create index idx_p_merchant_detail_id on D_ORDER_DETAIL (merchant_detail_id) Online;
创建好长时间，没有反映；然后取消，结果删除索引的时候，报如下的错误：
错误：ORA-08104: this index object 67420 is being online built or rebuilt
通过 ONLINE 参数创建索引(或者重建索引), 如果进程被突然终止，或者是手工 CTRL+C 取消该操作,
在非常个别的时候，麻烦来了。重新创建索引，会告诉你该索引已经存在，drop index ，会告诉你该索
引被锁，或者是 ORA-08104(this index object xxxxx is being online built or rebuilt) 错误。
该过程失败之前创建的一些临时对象由 SMON 负责清除，糟糕的是, SMON 可不是那么听话，马上出来清除，
这个清除时间可能会很长，据说在 9i 上观察是 2 个小时才清除掉。
如何解决呢？
在Oracle10g之前，对于这种情况没有太好的办法，只有等SMON进程来进行清理了。网上有说上重启库可以解决，
有说直接update系统表ind$的，对于不能停机的产品库来说，这些都是不可取的方案。重启不现实，修改系统表
更是DBA的大忌。
最好是等系统自动清除，如果因此给你带来的影响让你不得不手动尽早清除的话，那就看你的运气了
如果是Oracle10g，则可以使用dbms_repair.online_index_clean手工清理（metalink的说法，9i打了Bug 3805539的patch的话也能用该过程了）。
如果是一个比较繁忙的 OLTP 系统, 并且是要维护单列索引，那么风险真的是很大的。在 SMON 清除这些临
时对象之前，没有办法在该列上建立新的索引。服务器能撑住么?
异常终止的情况下，可以发现ind$关于该索引的状态还是online rebuild的：
SQL> select obj#,flags from ind$ where obj#=67420;
OBJ# FLAGS
---------- ----------
67420 514
Flags字段的说明可以在ind$的sql.bsq脚本中找到：
/* mutable flags: anything permanent should go into property */
/* unusable (dls) : 0x01 */
/* analyzed : 0x02 */
/* no logging : 0x04 */
/* index is currently being built : 0x08 */
/* index creation was incomplete : 0x10 */
/* key compression enabled : 0x20 */
/* user-specified stats : 0x40 */
/* secondary index on IOT : 0x80 */
/* index is being online built : 0x100 */
/* index is being online rebuilt : 0x200 */
/* index is disabled : 0x400 */
/* global stats : 0x800 */
/* fake index(internal) : 0x1000 */
/* index on UROWID column(s) : 0x2000 */
/* index with large key : 0x4000 */
/* move partitioned rows in base table : 0x8000 */
/* index usage monitoring enabled : 0x10000 */
514=0×202，表示该索引状态为index is being online rebuilt : 0×200 + analyzed : 0×02
在SMON完成清理动作后，再次查询索引状态已经恢复正常：
SQL> select obj#,flags from ind$ where obj#=67420;
OBJ# FLAGS
---------- ----------
67420 2
清理完后，可以在alert.log中看到如下记录：
User:,time:20071209 03:12:09,program:oracle@db1
(SMON),IP:,object:SYS_JOURNAL_67420,DDL: drop table "TAOBAO"."SYS_JOURNAL_67420"
解决一：
在10g中用dbms_repair.online_index_clean来清除创建索引的失败的遗留
DECLARE
RetVal BOOLEAN;
OBJECT_ID BINARY_INTEGER;
WAIT_FOR_LOCK BINARY_INTEGER;
BEGIN
OBJECT_ID := 67420;
-- 我的数据库中非法索引的id为67420.
WAIT_FOR_LOCK := NULL;
RetVal := SYS.DBMS_REPAIR.ONLINE_INDEX_CLEAN ();
COMMIT;
END;
/
注意：dbms_repair.online_index_clean这个函数一定要有返回值，否则会失败的
解决二：(这种方法没测试成功)
唤醒SMON:
WAKEUP command ：To wake up a process use
ORADEBUG WAKEUP pid
For example to wake up SMON, first obtain the PID using
SELECT pid FROM v$process
WHERE addr =
(
SELECT paddr FROM v$bgprocess
WHERE name = 'SMON'
);
If the PID is 6 then send a wakeup call using
sql > ORADEBUG WAKEUP 6
记录一下SMON的功能及其触发频率(9i)：
Merging free extents or coalescing: every five minutes.
Cleaning up temporary segments: every two hours.
Updating SMON_SCN_TIME for used in time based flashback: every five minutes.
Cleaning up non existent objects in OBJ$: every 12 hours.
Cleaning up IND$ if online builder crashes: every hour.
Shrink undo segments：every 12 hours.
Transaction recovery only on startup.
Transaction rollback of dead transaction when posted by PMON, allowing the use of fast start parallel rollback if necessary.
解决方法三：
由于在做索引在线重建的时候，可能相关的表还在变化，Oracle需要记录这个索引的相关变化，因此Oracle会创建一张临时表来记录这些变化，等索引重建完成后再删除这张临时表，这张临时表的名字为SYS_JOURNAL_<INDEX的OBJECT_ID>。REBUILD ONLINE刚刚开始的时候就会去创建这张日志表，但是如果创建日志表的时候，发现这张表已经存在了，就可能会报ORA-8104，并无法继续做REBUILD ONLIE（普通的REBUILD会检查索引的FLAG标志和这张表，如果冲突，也会失败）。如果REBUILD ONLINE被中途杀掉了，那么这张表和IND$中的FLAGS不会被自动清除，必须由SMON来清除。而SMON每个小时会进行一次类似的清除工作，SMON做清除前首先要锁住日志表，如果这个索引相关的表还在变化，那么SMON可能无法锁住这张表，如果SMON锁表失败，就会放弃这次清理工作，等一个小时后再来清理。这样一来，在业务较为繁忙的生产系统上，可能SMON永远都没有机会清除这张日志表。
如果是9i的数据库就很麻烦了，如果系统smon进程无法清除，或者重启数据库也无法解决，那只有手工清除了日志表，并且修改索引的FLAGS。手工解决这个问题分为两个步骤：
1、手工删除日志表：
首先找到这个索引的OBJECT_ID:
Select object_id from dba_objects where owner=<owner> and object_name=<index name>;
找到OBJECT_ID后，就可以知道表的名字了（SYS_JOURNAL_<OBJECT_ID>），直接DROP这张表。不过如果这张表上的DML比较频繁，DROP操作可能不会一次成功，需要不停的重试。
2、手工修改IND$：
UPDATE IND$ SET FLAGS=FLAGS-512 WHERE OBJ#=<OBJECT_ID>;
手工清理要十分小心，一旦出错会导致数据字典错误。
解决方法四：
还有一种稳妥的办法是把应用停了，然后重启数据库，这样相关表上没有了DML操作，很快SMON就会完成自动清理。
参考文档：http://www.oraclefans.cn/forum/showtopic.jsp?rootid=14720&CPages=1
http://blog.csdn.net/wyzxg/article/details/4318618