在线redo log或数据文件SCN不一致的解决思路

在线redo log或数据文件SCN不一致的解决思路

 

一、非当前redo损坏:
只要clear redo
alter database clear logfile group 1;
如还没归档则用alter database clear unarchived logfile group 2;

二、当前redo损坏，通过加入隐含参数方式恢复！
一般步骤如下：
1：首先加入_ALLOW_RESETLOGS_CORRUPTION = TRUE隐含参数，最后resetlogs打开数据库，如果无法打开，进入第二步(如数据文件SCN不一致也可参考每二步）。

2：查看日志信息，根据具体报错信息，确认方法，本例是出现ORA-00600: internal error code, arguments: [2662], [1], [801031970], [1], [809070934], [746586114], [], []
ORA-600 [2662] "Block SCN is ahead of Current SCN"，说明当前数据库的数据块的SCN早于当前的SCN，主要是和存储在UGA变量中的dependent SCN进行比较，如果当前的SCN小于它，数据库就会产生这个ORA-600 [2662]的错误了.于是想到使用ADJUST_SCN事件来调整当前的SCN，使其大于dependent SCN. 此时我们可以通过Oracle的内部事件来调整SCN:
解决这个问题一般方法是：
调整SCN有两种常用方法:
1.通过immediate trace name方式(在数据库Open状态下，即通过用_allow_resetlogs_corruption=TRUE隐含参数打开数据库之后报错600)
alter session set events 'IMMEDIATE trace name ADJUST_SCN level x';
2.通过10015事件(在数据库无法打开，mount状态下)
alter session set events '10015 trace name adjust_scn level x';
注:level 1为增进SCN 10亿 (1 billion) (1024*1024*1024),通常Level 1已经足够。也可以根据实际情况适当调整。

3：一般情况下redo损坏的时候，undo数据也大都不一致，因此通过scn调整完毕，resetlogs数据库后还会出现ORA-00600: internal error code, arguments: [4194]错误，这个错误可以通过设置undo解决：
尝试将undo改变成手工管理的，然后重启数据库，
现不行的话设置隐含参数：_corrupted_rollback_segments
有时将undo改变成手工管理，问题解决。