某行今天报告一个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，数据库成功打开。