online rebulid index 异常终止遇到ora-08104_MySQL, Oracle及数据库讨论区_Weblogic技术|Tuxedo技术|中间件技术|Oracle论坛|JAVA论坛|Linux/Unix技术|hadoop论坛_联动北方技术论坛  
网站首页 | 关于我们 | 服务中心 | 经验交流 | 公司荣誉 | 成功案例 | 合作伙伴 | 联系我们 |
联动北方-国内领先的云技术服务提供商
»  游客             当前位置:  论坛首页 »  自由讨论区 »  MySQL, Oracle及数据库讨论区 »
总帖数
1
每页帖数
101/1页1
返回列表
0
发起投票  发起投票 发新帖子
查看: 2708 | 回复: 0   主题: online rebulid index 异常终止遇到ora-08104        下一篇 
Gavin
注册用户
等级:少校
经验:878
发帖:130
精华:1
注册:2011-7-21
状态:离线
发送短消息息给Gavin 加好友    发送短消息息给Gavin 发消息
发表于: IP:您无权察看 2015-5-22 10:53:33 | [全部帖] [楼主帖] 楼主

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_<INDEXOBJECT_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

就会完成自动清理。

--转自 北京联动北方科技有限公司




赞(0)    操作        顶端 
总帖数
1
每页帖数
101/1页1
返回列表
发新帖子
请输入验证码: 点击刷新验证码
您需要登录后才可以回帖 登录 | 注册
技术讨论