创建好长时间，没有反映；然后取消，结果删除索引的时候，报如下的错误：

错误：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的： 

Flags字段的说明可以在ind$的sql.bsq脚本中找到：

514=0×202，表示该索引状态为index is being online rebuilt : 0×200 + analyzed : 0×02

在SMON完成清理动作后，再次查询索引状态已经恢复正常：

清理完后，可以在alert.log中看到如下记录：

解决一：

在10g中用dbms_repair.online_index_clean来清除创建索引的失败的遗留

注意：dbms_repair.online_index_clean这个函数一定要有返回值，否则会失败的

解决二：(这种方法没测试成功)

唤醒SMON:

记录一下SMON的功能及其触发频率(9i)：

解决方法三：

由于在做索引在线重建的时候，可能相关的表还在变化，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:

找到OBJECT_ID后，就可以知道表的名字了（SYS_JOURNAL_<OBJECT_ID>），直接DROP这张表。不过如果这张表上的DML比较频繁，DROP操作可能不会一次成功，需要不停的重试。

2、手工修改IND$：

手工清理要十分小心，一旦出错会导致数据字典错误。

解决方法四：

还有一种稳妥的办法是把应用停了，然后重启数据库，这样相关表上没有了DML

操作，很快

就会完成自动清理。

--转自