今天看到有一個朋友因為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 state
在這種情況下,最好的情況是擁有備份,能夠從備份中恢復.假如沒有備份就很麻煩了(本案例恰恰沒有備份).
和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并不答應置所有索引于不顧,否則就有救了.
套用一句名言:幸運的數據庫大致相同,不幸的數據庫卻各有各的不幸.
