ORACLE无法OPEN，处理三板斧

mount下先查询数据文件头的检查点是否一致
查询 v$datafile_header ，CHECKPOINT_CHANGE#均一致，FUZZY为YES

SQL> select file#, fuzzy, to_char(CHECKPOINT_CHANGE#) from v$datafile_header;

1)对于open resetlogs时数据文件中有脏数据的情况，可以设置

_allow_resetlogs_corruption= TRUE

来规避。
2)如果出现ORA-01555错误，导致数据库无法open，可以设置

_CORRUPTED_ROLLBACK_SEGMENTS
undo_management = 'MANUAL'

的方式来规避
3)出现ORA-600 [2662]错误时，先通过多次重启open的方法来观察Current SCN BASE增长速度。
如果Current SCN BASE和Current SCN BASE相差不远，重启几次数据库就课可以打开。
4)如果Current SCN BASE和Current SCN BASE相差很远，mount之后先

alter session  set events '10015 trace name adjust_scn level 10';

加速增长。
然后open
5)如果加入10015事件adjust_scn以后，Current SCN BASE增长还是很慢，有些版本必须加入

_allow_error_simulation  = TRUE

才能使10015事件生效
6)如果Current SCN BASE增长还是很慢，加入

_smu_debug_mode = 268435456

直接增长SCN WRAP的方法来加速
7)还可以通过_minimum_giga_scn来加速(本案例未使用)
8) 如果SCN号一致以后报错ORA-600[6006]，ORA-600[4137]的话，需要添加参数

*.event="10513 trace name context forever,level 2"
*.db_block_checking=false

9) 对于open resetlogs打开以后的数据库，最好将业务用户导出以后重建数据库，以防止数据库出现不可预知的错误。ORACLE官方建议是open resetlogs以后需要重建数据库。

参数，事件，错误说明：
1)_ALLOW_RESETLOGS_CORRUPTION=true：允许resetlogs时数据文件中有脏数据
2)_CORRUPTED_ROLLBACK_SEGMENTS:将回滚段标记为损坏
3)ORA-600 [2662] [a] [b] [c] [d] [e]：
Arg [a] Current SCN WRAP：当前(控制文件)的SCN WRAP
Arg [b] Current SCN BASE：当前(控制文件)的SCN BASE
Arg [c] dependent SCN WRAP：目标SCN WRAP
Arg [d] dependent SCN BASE：目标SCN BASE
Arg [e] Where present this is the DBA where the dependent SCN came from.
SCN可以用十六进制表示0Xffff.ffffffff。为了方便，oracle把前面的4个字节表示scn wrap，后面的8个字节表示scn base。scn最低值是0X0000.00000000，最高值是0Xffff.ffffffff。高位是scn wrap，低位是scn base。
SCN= (SCN_WRAP * 4294967296) + SCN_BASE，当SCN_BASE足够大时，SCN_WRAP就会加1，也就是说SCN_WRAP是SCN的高位，SCN_BASE是SCN的低位。
4294967296=2^32
4)10015 ADJUST_SCN事件：加速Current SCN BASE增长
5)_allow_error_simulation=true,该值设为false时会阻止ADJUST_SCN事件
6)_smu_debug_mode= 268435456，增长SCN WRAP，这个参数需要和_allow_error_simulation=true同时使用
7)_minimum_giga_scn=n：把SCN向前推进nG，只有Current SCN和dependent SCN相差nG时这个参数才起效，否则无效。
8)*.event="10513 trace name context forever,level 2"禁止SMON回滚恢复事务