某行今天報告一個3T的庫，恢復後無法OPEN，要求我方介入。
到現場之前想當然的覺得無非不就是resetlog走起，結果到了以後用戶說已經resetlog過了，從磁帶恢復要兩天，心涼半截。
接手系統，recover database需要歸檔日誌。詢問用戶得知備份已不存在。好吧，不管了。
增加隱藏參數_allow_resetlogs_corruption=true
起手alter database open resetlogs;
open時報錯ora-03113 end-of-file on communication channel
重新正常startup啓動數據庫
報錯如下
ORA-00704/ORA-01555
select ctime, mtime, stime from obj$ where obj# = :1
Errors in file /oracle/admin/db/udump/db_ora_128889.trc:
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00604: error occurred at recursive SQL level 1
ORA-01555: snapshot too old: rollback segment number 40 with name “_SYSSMU2$” too small
Error 704 happened during db open, shutting down database
USER: terminating instance due to error 704
Instance terminated by USER, pid = 1286288
ORA-1092 signalled during: alter database open resetlogs…
這時候就犯了常識性錯誤，認爲是UNDO的問題，直接手動建個PFILE，修改undo_management=manual,增加corrupt_rollback_segment
重新啓動數據庫，故障依舊。
在UNDO這個問題上嘗試幾次未果後，查閱META，提示可能是SCN的問題。
於是手動推進SCN
SQL> startup mount pfile='/tmp/mouse.ora'
ORACLE instance started.
Total System Global Area 8076850392 bytes
Fixed Size 736984 bytes
Variable Size 2536870912 bytes
Database Buffers 4536870912 bytes
Redo Buffers 2371584 bytes
Database mounted.
SQL> alter session set events '10015 trace name ADJUST_SCN level 10';
Session altered.
SQL> alter database open;
故障依舊。
增加*._allow_error_simulation=TRUE
故障依舊。
於是用ORADEBUG走起。
oradebug setmypid
oradebug DUMPvar SGA kcsgscn_
oradebug poke 0x700000100E12 4 0x700000100E49
alter database open;
數據庫依然無法啓動，但是alert日誌報錯變了，顯示ORA-00600[2252]。
有戲，說明推進SCN的思路是對的。
既然上兩種推進都無果，那麼下面只有用隱藏參數了。10G給我們提供了一個好參數：_minimum_giga_scn,我們可以使用file header的scn求出
例：
col scn for 99999999999999999
SQL> select to_number('b5ff28cc1fd','xxxxxxxxxxxx') scn from dual;
SCN
------------------
12506719109629
SQL>select 12506719109629/1024/1024/1024 giga from dual;
GIGA
----------
11647.7898
於是增加隱藏參數_minimum_giga_scn=1000，數據庫成功打開。