Move系统表DEPENDENCY$导致索引失效的数据库故障的另一种处理方式-CSDN博客

年底不安全，尽出些稀奇古怪的问题。今天一个客户的一个非核心系统，9i的库的dependency$被MOVE导致索引失效，但是又没有去重建索引，导致数据库关闭后无法启动

该案例的现象为：

MOVE dependency$ 后，其上索引I_DEPENDENCY1/ I_DEPENDENCY2失效

数据库正常关闭后，打开报错：

Database mounted.

ORA-01092: ORACLE instance terminated. Disconnection forced

alert日志报错：

Sun Dec 16 21:04:40 2012

Errors in file /u01/app/oracle/admin/o9208/udump/o9208_ora_28069.trc:

ORA-00704: bootstrap process failure

ORA-00604: error occurred at recursive SQL level 1

ORA-01502: index 'SYS.I_DEPENDENCY1' or partition of such index is in unusable state

Sun Dec 16 21:04:40 2012

Error 704 happened during db open, shutting down database

USER: terminating instance due to error 704

Instance terminated by USER, pid = 28069

ORA-1092 signalled during: ALTER DATABASE OPEN...

sqltrace可以得到报错的语句为：

select owner#,name,namespace,remoteowner,linkname,p_timestamp,p_obj#, d_owner#, nvl(property,0),subname from dependency$,obj$ where d_obj#=:1 and p_obj#=obj#(+) order by order#

dbsnake在oracle手记2中分享过处理的办法为BBED修改。但是觉得远程做风险太大，而且我也很久没看过了，都忘记了，再去研究下太麻烦。

先让客户确认备份，如果有备份从备份恢复，如果没备份就备个份下

同时，我想到的几个其他方案并进行了测试：

1. 用10g软件来打开这个库，期望skip_unusable_indexes参数能有效。但是可能由于compatible参数原因，失败

2. 期望通过其他参数影响索引成本计算，失败。可能9I数据字典根本未收集统计数据，可能是RBO模式

3. 期望用gdb可以跟踪到执行这个语句的步骤，失败，没有符号表，无法定位到可能的函数，无法next执行下一步

难道只有BBED？突然想起双全兄以前分享的一个global_names被置空后，其通过修改oracle执行文件，跳过该步骤方法，那这个方法如何了？

用UltraEdit打开我机器上的Oracle的执行文件，发现果然这个语句就在该文件中

(不知道如何调大图，点击看大图)

下一步是测试如何修改。最后测试的结果为：该SQL的语句不能超过当前长度，可以小于。

最后，我对语句进行了如下修改：

(不知道如何调大图，点击看大图)

1. 通过d_obj#+0=:1 屏蔽掉索引的使用

2. 拿一个其他库测试，得到bootstrap过程中该SQL的绑定变量，测试了这些数据，发现存放的数据和order#的顺序一致，语句决定删除order by order#，避免SQL语句超长，来测试一把

3. 另外，虽然在oracle文件中发现了很多涉及到该表的其他语句，包括一些DML，但是在10046TRC中没有发现有涉及到这个表的其他SQL语句

然后用修改过的该文件代替以前的旧文件：

[oracle@zhangqiaoc bin]$ sql

SQL*Plus: Release 9.2.0.8.0 - Production on Sat Dec 15 23:29:38 2012

Connected to an idle instance.

SQL> startup

ORACLE instance started.

Total System Global Area 840401056 bytes

Fixed Size 741536 bytes

Variable Size 520093696 bytes

Database Buffers 318767104 bytes

Redo Buffers 798720 bytes

Database mounted.

Database opened.

成功OPEN开数据库，开后台日志，这次不再报告SYS.I_DEPENDENCY1不可用，而只是SMON报告了下SYS.I_DEPENDENCY2不可用。但是此时，bootstrap已经完成了，应该SMON再做一些动作，还好SMON报错后依然坚挺，否则可能需要考虑设置EVENT或者其他办法了。

Sat Dec 15 23:29:45 2012

Errors in file /u01/app/oracle/admin/o9208/bdump/o9208_smon_26556.trc:

ORA-00604: error occurred at recursive SQL level 1

ORA-01502: index 'SYS.I_DEPENDENCY2' or partition of such index is in unusable state

replication_dependency_tracking turned off (no async multimaster replication found)

Completed: ALTER DATABASE OPEN

查看启动过程的sqltrace文件，看到bootstrap执行的语句已经变成我修改过的语句了，执行计划也已经是全表扫描了

select owner#,name,namespace,remoteowner,linkname,p_timestamp,p_obj#,

d_owner#, nvl(property,0),subname

from

dependency$,obj$ where d_obj#+0=:1 and p_obj#=obj#(+)

call count cpu elapsed disk query current rows

------- ------ -------- ---------- ---------- ---------- ---------- ----------

Parse 12 0.00 0.00 0 0 0 0

Execute 12 0.00 0.00 0 0 0 0

Fetch 71 0.13 0.13 288 3608 0 59

------- ------ -------- ---------- ---------- ---------- ---------- ----------

total 95 0.13 0.13 288 3608 0 59

Misses in library cache during parse: 2

Optimizer mode: CHOOSE

Parsing user id: SYS (recursive depth: 1)

Rows Row Source Operation

------- ---------------------------------------------------

0 NESTED LOOPS OUTER

0 TABLE ACCESS FULL OBJ#(96)

0 TABLE ACCESS BY INDEX ROWID OBJ#(18)

0 INDEX UNIQUE SCAN OBJ#(36) (object id 36)

另外，关于SMON的报错，我跟踪下发现是如下语句：

select o.owner#,o.obj#,decode(o.linkname,null, decode(u.name,null,'SYS',u.name),o.remoteowner), o.name,o.linkname,o.namespace,o.subname from user$ u, obj$ o where u.user#(+)=o.owner# and o.type#=:1 and not exists (select p_obj# from dependency$ where p_obj# = o.obj#)

该语句在ORACLE也有

(不知道如何调大图，点击看大图)