今天给客户做数据恢复,发现必须使用隐藏参数_allow_resetlogs_corruption,结果一用报出了ORA-00600 2662的错误。
客户那边说丢失了一个数据文件CUUG.DBF,只有一个以前的冷备份(结果就备份了这一个数据文件............#@#@¥...)。接管客户系统时,那边dba已经将控制文件重建了。无语中......
将以前的数据文件拷贝回来,重新注册归档日志后,开始恢复。报错:
提示ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below ORA-01194: file 1 needs more recovery to be consistent ORA-01110: data file 1: '/opt/oracle/product/10.2.0/oradata/orcl1/system01.dbf'
看下数据文件的SCN:
SQL> select CHECKPOINT_CHANGE# from v$datafile_header; CHECKPOINT_CHANGE# ------------------ 591931 591931 591931 591931 505927
然后看下归档日志:
/opt/oracle/product/10.2.0/flash_recovery_area/ORCL1/archivelog/2012_05_19/o1_mf_1_9_7vh78q75_.arc 591800 591805 /opt/oracle/product/10.2.0/flash_recovery_area/ORCL1/archivelog/2012_05_19/o1_mf_1_8_7vh78gwc_.arc 590306 591800 /opt/oracle/product/10.2.0/flash_recovery_area/ORCL1/archivelog/2012_05_19/o1_mf_1_10_7vh7b2xs_.arc 591805 591931
这眼看普通恢复没戏了.....归档日志不连续。
开启隐藏参数
sql> alter system set "_allow_resetlogs_corruption"=true scope=spfile;
再次尝试打开数据库,开始提示ORA-00600错误了。
Wed May 23 15:06:44 2012 SMON: enabling cache recovery Wed May 23 15:06:44 2012 Errors in file /opt/oracle/product/10.2.0/admin/orcl1/udump/orcl1_ora_4268.trc: ORA-00600: internal error code, arguments: [2662], [0], [545944], [0], [590505], [4194313], [], [] Wed May 23 15:06:44 2012 Incremental checkpoint up to RBA [0x1.3.0], current log tail at RBA [0x1.3.0] Wed May 23 15:06:44 2012 Errors in file /opt/oracle/product/10.2.0/admin/orcl1/udump/orcl1_ora_4268.trc: ORA-00600: internal error code, arguments: [2662], [0], [545944], [0], [590505], [4194313], [], [] Wed May 23 15:06:44 2012 Error 600 happened during db open, shutting down database USER: terminating instance due to error 600 Instance terminated by USER, pid = 4268
ORA-00600 [2662]含义:
A data block SCN is ahead of the current SCN.
The ORA-600 [2662] occurs when an SCN is compared to the dependent SCN
stored in a UGA variable.
If the SCN is less than the dependent SCN then we signal the ORA-600 [2662]
internal error.
ORA-600 [2662] [a] [b] [c] [d] [e]
Arg [a] Current SCN WRAP
Arg [b] Current SCN BASE
Arg [c] dependent SCN WRAP
Arg [d] dependent SCN BASE
Arg [e] Where present this is the DBA where the dependent SCN came from.
可见参数b=545944,参数d=590505,确实数据块SCN小于dependent SCN。
这里需要使用oracle内部事件来增加SCN:
在数据库open状态下:
sql> alter session set events 'IMMEDIATE trace name adjust_scn level 1';
数据库不能open时:
sql> alter session set events '10015 trace name adjust_scn level 1';
level 1=10亿(1024*1024*1024),一般增进level 1就足够了。
10g以后,还需要设置参数_allow_error_simulation为TRUE,否则该事件不能生效。
sql> alter system set '_allow_error_simulation'=true scope=spfile;
重启数据库后,再次open:
Database Characterset is AL32UTF8 Wed May 23 15:28:18 2012 Incremental checkpoint up to RBA [0x4.3.0], current log tail at RBA [0x4.37.0] replication_dependency_tracking turned off (no async multimaster replication found) Starting background process QMNC QMNC started with pid=21, OS id=4490 Wed May 23 15:28:23 2012 LOGSTDBY: Validating controlfile with logical metadata Wed May 23 15:28:23 2012 LOGSTDBY: Validation complete Completed: alter database open
数据库终于open了,但部分数据已丢失,不能再恢复。
因为修改了这部分隐藏参数_allow_resetlogs_corruption,为保证后续使用, 剩下的就是exp再imp了。