我在"9i下Move系统表DEPENDENCY$导致索引失效的恢复"和"9i下Move系统表DEPENDENCY$导致索引失效的恢复（续）"这两篇文章里用BBED成功将上述库起起来了，但是这里有一个问题----我处理的思路是把一切都恢复到以前未move的状态，但是如果DEPENDENCY$在move很长时间后才shutdown，那么原先DEPENDENCY$所属的旧block可能已经被覆盖了，此时上述两篇文章里的方法就不起作用了。
此时有没有办法处理上述情况呢？
当然有。
此时我们的处理思路就是骗过oracle，让oracle不知道索引I_DEPENDENCY1和I_DEPENDENCY2的存在。
注意，index cluster不能随便改的，所谓的牵一发而动全身在这里体现的太明显了。
此时最核心的处理思路就是我们在用BBED把I_DEPENDENCY1和I_DEPENDENCY2删掉后要用到一个隐含参数*._db_always_check_system_ts=FALSE，接着把库起起来后要删掉一系列数据字典表里跟上述两个索引相关联的数据，让I_DEPENDENCY1和I_DEPENDENCY2彻底的成为尸体。
我们来看一下，当我把I_DEPENDENCY1和I_DEPENDENCY2删掉后：
[P550_04_LA:oracle@:/cadrasu01/app/oracle/product/
DBVERIFY: Release
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
DBVERIFY - Verification starting : FILE = /dras20/testdb/system01.dbf
Block Checking: DBA = 4194336, Block Type = KTB-managed data block
data header at 0x
kdbchk: key comref count wrong
keyslot=7
Page 32 failed with check code 6121
DBVERIFY - Verification complete
Total Pages Examined : 52480
Total Pages Processed (Data) : 36943
Total Pages Failing (Data) : 1
Total Pages Processed (Index): 4085
Total Pages Failing (Index): 0
Total Pages Processed (Other): 1750
Total Pages Processed (Seg) : 0
Total Pages Failing (Seg) : 0
Total Pages Empty : 9702
Total Pages Marked Corrupt : 0
Total Pages Influx : 0
Highest block SCN : 676215 (0.676215)
你如果尝试去修正上述错误，会陷入无尽的痛苦之中，oracle的block check太严格了。
SQL_testdb>startup pfile=/dras20/testdb/inittestdb.ora
ORACLE instance started.
Total System Global Area 504858456 bytes
Fixed Size 743256 bytes
Variable Size 285212672 bytes
Database Buffers 218103808 bytes
Redo Buffers 798720 bytes
Database mounted.
Database opened.
SQL_testdb>select count(*) from dba_tables;
COUNT(*)
----------
816
[P550_04_LA:oracle@:/dras20/testdb]#exp scott/tiger@testdb file=emp.dmp tables=emp
Export: Release
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Connected to: Oracle9i Enterprise Edition Release
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release
Export done in US7ASCII character set and AL16UTF16 NCHAR character set
server uses ZHS16GBK character set (possible charset conversion)
About to export specified tables via Conventional Path ...
. . exporting table EMP 14 rows exported
EXP-00091: Exporting questionable statistics.
Export terminated successfully with warnings.
SQL_testdb>delete from icol$ where obj#=127;
3 rows deleted.
SQL_testdb>delete from icol$ where obj#=128;
2 rows deleted.
SQL_testdb>delete from
delete from
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [13011], [2], [4194336], [5],[4194336], [3], [], []
SQL_testdb>delete from obj$ where obj# =127;
1 row deleted.
SQL_testdb>delete from obj$ where obj# =128;
1 row deleted.
SQL_testdb>delete from seg$ where ts#=0 and file#=1 and block#=977;
1 row deleted.
SQL_testdb>delete from seg$ where ts#=0 and file#=1 and block#=985;
1 row deleted.
SQL_testdb>commit;
Commit complete.
SQL_testdb>create unique index SYS.I_DEPENDENCY1_BCK on SYS.DEPENDENCY$ (D_OBJ#, D_TIMESTAMP, ORDER#) tablespace SYSTEM;
Index created.
SQL_testdb>create index SYS.I_DEPENDENCY2_BCK on SYS.DEPENDENCY$ (P_OBJ#, P_TIMESTAMP) tablespace SYSTEM;
Index created.
SQL_testdb>select count(*) from DEPENDENCY$;
COUNT(*)
----------
49930
SQL_testdb>select owner,index_name,tablespace_name,status from dba_indexes where table_name='DEPENDENCY$';
OWNER INDEX_NAME
------------------------------ ------------------------------
TABLESPACE_NAME STATUS
------------------------------ --------
SYS I_DEPENDENCY1_BCK
SYSTEM VALID
SYS I_DEPENDENCY2_BCK
SYSTEM VALID
SQL_testdb>select object_id,data_object_id from dba_objects where object_name='DEPENDENCY$';
OBJECT_ID DATA_OBJECT_ID
---------- --------------
96 30367
这是我能想到的比较好的拯救方法。有朋友不断的在跟我要这个系列文章的详细处理过程，我不愿意给的原因是处理过程过于internal和复杂，而且我其实已经把最核心的思路和方法都写出来了。其实我只是把我的想法变成了现实而已，如果你也对internal感兴趣，为什么一定要指望别人呢？为什么不尝试自己动手试一下？
Leave a comment