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就会完成自动清理。
--转自