eygle.com   eygle.com
eygle.com eygle
eygle.com  
 

« Oracle初学者入门指南-什么是DSI? | Blog首页 | Oracle初学者入门指南-什么是Metalink -MOS ? »

案例:Move系统表DEPENDENCY$导致索引失效的数据库故障

今天看到有一个朋友因为Move了一个系统表DEPENDENCY$,在没有Rebuild索引的情况下,重起数据库,结果收到ORA-01502错误,数据库无法启动.
Thu Nov 17 01:55:30 2005
Errors in file /dcdb/admin/hidc/udump/hidc_ora_56602.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

在这种情况下,最好的情况是拥有备份,能够从备份中恢复.如果没有备份就很麻烦了(本案例恰恰没有备份).
D.C.B.A讨论这个问题的时候,开始想到了3个办法:
1.通过某种手段跳过索引检测
事实证明在9i中这很难;而且这是在Bootstrap$的检测过程中发生的.
2.通过BBED进行修复
这种方法应该可行,但是会极其复杂小心.
3.使用DUL或类DUL工具
最后这种方法是万不得已.

DCBA在跟进这个案例,参考:
http://www.anysql.net/blog/p/movesystem.php
但是我们应该记住,永远不要让你的数据库处于这样的境地,这真的很危险.

这一问题的根本原因在于,数据库启动过程中,会进行如下验证:
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#

这一验证会导致如下执行计划:
STAT #9 id=1 cnt=1 pid=0 pos=1 obj=0 op='NESTED LOOPS  (cr=6 r=3 w=0 time=694 us)'
STAT #9 id=2 cnt=1 pid=1 pos=1 obj=18 op='TABLE ACCESS BY INDEX ROWID OBJ#(18) (cr=3 r=0 w=0 time=104 us)'
STAT #9 id=3 cnt=1 pid=2 pos=1 obj=36 op='INDEX UNIQUE SCAN OBJ#(36) (cr=2 r=0 w=0 time=64 us)'
STAT #9 id=4 cnt=1 pid=1 pos=2 obj=22 op='TABLE ACCESS CLUSTER OBJ#(22) (cr=3 r=3 w=0 time=576 us)'
STAT #9 id=5 cnt=1 pid=4 pos=1 obj=11 op='INDEX UNIQUE SCAN OBJ#(11) (cr=2 r=2 w=0 time=406 us)'

这里的'INDEX UNIQUE SCAN OBJ#(36)"就导致了最后的错误:
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
EXEC #1:c=0,e=633371,p=39,cr=619,cu=1,mis=0,r=0,dep=0,og=2,tim=1105782888673612
ERROR #1:err=1092 tim=1563018104


可惜Oracle并不允许置所有索引于不顾,否则就有救了.

套用一句名言:幸运的数据库大致相同,不幸的数据库却各有各的不幸.

历史上的今天...
    >> 2011-11-18文章:
    >> 2010-11-18文章:
    >> 2009-11-18文章:
    >> 2008-11-18文章:
    >> 2007-11-18文章:
           我的装修以及装修的生意
    >> 2006-11-18文章:
    >> 2004-11-18文章:
           使用USE_CONCAT提示

无觅

By eygle on 2005-11-18 13:46 | Comments (7) | Case | Internal | 541 |

7 Comments

据那人说现在已经有人在帮他恢复。我猜应该是用DUL来恢复的,用BBED从原理上也是可以恢复的,不过会不断碰到新问题,很不好弄。

幸运的数据库大致相同,不幸的数据库却各有各的不幸.

托尔斯泰名言的数据库版本 :-)

该数据库已经恢复了,而实际上,我上面提到的三种方法都是有效的.

你提到的DBCA连接并不存在,能提供这个问题解决的过程给我看看么,thanks

这种问题是很少会遇到的,解决过程也很复杂,所以没提供解决过程!

我觉得,避免不幸的最好办法是不要乱动,特别是重要系统(生产环境)的系统表。

能不动自然是好的,可是很多时候不得不动啊.


CopyRight © 2004~2020 云和恩墨,成就未来!, All rights reserved.
数据恢复·紧急救援·性能优化 云和恩墨 24x7 热线电话:400-600-8755 业务咨询:010-59007017-7040 or 7037 业务合作: marketing@enmotech.com