ORA-08104: 该索引对象68100 正在被联机建立或重建

测试人员报告某个sql查询操作比较慢，希望协助查找一下原因。

检查发现IDX_LOG_BUSINON 碎片较为严重，决定重建索引。

为了不影响大家使用，决定用rebuild online的方式重建该索引。

 

 

连接到:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
With the Partitioning, OLAP and Data Mining options

SQL> alter index IDX_LOG_BUSINON rebuild online ;

 

一会有人来叫去会议室讨论影像迁移的问题，与是拔掉网线拿起笔记本去了

会议室。到了会议室发现这个会话已经断开了。找根网线插上继续rebuild索引。

 

SQL> alter index IDX_LOG_BUSINON rebuild online ;
alter index IDX_LOG_BUSINON rebuild online
*
第 1 行出现错误:
ORA-08104: 该索引对象 68100 正在被联机建立或重建

 

检查了一下68100对象，发现就是要rebuild的那个索引。

 

SQL> select OWNER, OBJECT_NAME, OBJECT_ID, OBJECT_TYPE
  2    from dba_objects o
  3   where o.object_id = '68100';

OWNER    OBJECT_NAME         OBJECT_ID OBJECT_TYPE
-------- ------------------ ---------- -----------
REPORT   IDX_LOG_BUSINON         68100 INDEX

 

 

由于之前在ORACLE 10g 上遇到过这个问题，所以觉得没啥。直接用

DBMS_REPAIR.ONLINE_INDEX_CLEAN 清理掉，在重建就好了。

 

SQL> desc dbms_repair

。。。省略部分描述
 FUNCTION ONLINE_INDEX_CLEAN RETURNS BOOLEAN

参数名称                            类型                       输入/输出默认值?
------------------------------ ----------------------- ------ --------
 OBJECT_ID                      BINARY_INTEGER          IN     DEFAULT
 WAIT_FOR_LOCK             BINARY_INTEGER          IN     DEFAULT

 

说明：DBMS_REPAIR.ONLINE_INDEX_CLEAN ()要求有返回值。

SQL> DECLARE
  2    RetVal BOOLEAN;
  3    OBJECT_ID BINARY_INTEGER;
  4    WAIT_FOR_LOCK BINARY_INTEGER;
  5 
  6  BEGIN
  7    OBJECT_ID := 68100;
  8    WAIT_FOR_LOCK := NULL;
  9    RetVal := SYS.DBMS_REPAIR.ONLINE_INDEX_CLEAN ();
 10    COMMIT;
 11  END;
 12  /

继续开会。。。大约20分钟会议结束。感觉索引应该rebuild结束。

但还没执行完，这时候突然紧张起来了。赶紧去看alert*.log没发现

有异常。什么原因呢，测试环境中这张表的数据并不多，应该很快就能

搞定的。为什么这么长时间还没完呢。是不是有人锁表了呢。

 

 

SQL> SELECT /*+ rule */
  2         s.username,
  3         decode(l.type, 'TM', 'TABLE LOCK', 'TX', 'ROW LOCK', NULL) LOCK_LEVEL,
  4         o.owner,
  5         o.object_name,
  6         o.object_type,
  7         s.sid,
  8         s.serial#,
  9    FROM gv$session s, gv$lock l, dba_objects o
 10   WHERE l.sid = s.sid
 11     AND l.id1 = o.object_id(+)
 12     AND s.username is NOT NULL ;

USERNAME    LOCK_LEVEL OWNER      OBJECT_NAME        OBJECT_TYPE    SID  SERIAL#
----------- ---------- ---------- ------------------ ------------ ----- --------
REPORT                 REPORT     WFLOG              TABLE          154      159
REPORT                 SYS        TAB$               TABLE          154      159
REPORT                 REPORT     WFLOG              TABLE          154      159
REPORT      TABLE LOCK REPORT     SYS_JOURNAL_68100  TABLE          154      159
REPORT      ROW LOCK                                                154      159
REPORT      TABLE LOCK REPORT     WFLOG              TABLE          154      159
REPORT      ROW LOCK                                                138       10
REPORT      TABLE LOCK REPORT     WFLOG              TABLE          138       10

 

果然有人锁表了，找到那个哥们，发现她刚才也来开会了。她commit后，果然很快清理完了。

再次rebuild 这个索引，也很快搞定。

 

SQL> alter index IDX_LOG_BUSINON rebuild online ;

 

 

总结： 幸亏是赶在快吃饭时间用测试库的人比较少，影响比较小。

          要是在生产库上就是一次严重的事故了。不过在生产库上

          有严格的审批流程，没人敢去轻易操作。

 

结论：做事情要一心一意，不能分心。尤其是操作数据库。