Oracle隐含参数：allow_resetlogs_corruption的使用

提示：Oracle的隐含参数只应该在测试环境或者在Oracle Support的支持下使用

oracle中redo文件损坏时：
1：如果损坏的是非当前redo文件而且已经归档：
此时可以使用alter database clear logfile group xx 清空该日志文件。
2：如果损坏的是非当前redo文件，并且该文件组没有归档：
此时使用alter database clear unarchived logfile group xx;强行清空日志
3：归档模式下当前日志的损坏有两种情况：
一、是数据库是正常关闭，日志文件中没有未决的事务需要实例恢复，当前日志组的损坏就可以直接用alter database clear unarchived logfile group n来重建。
二、是日志组中有活动的事务，数据库需要媒体恢复，日志组需要用来同步，有两种补救办法
A:最好的办法就是通过不完全恢复，可以保证数据库的一致性，但是这种办法要求在归档方式下，并且有可用的备份
B:通过强制性恢复，但是可能导致数据库不一致。

[@more@]

下面的情况假定当前日志损坏，并且没有备份，所以只有采取强制性恢复：
SQL> startup force;
ORACLE instance started.
Total System Global Area 97588504 bytes
Fixed Size 451864 bytes
Variable Size 33554432 bytes
Database Buffers 62914560 bytes
Redo Buffers 667648 bytes
Database mounted.
ORA-00354: corrupt redo log block header
ORA-00353: log corruption near block 3 change 897612314 time 10/19/2005 14:19:34
ORA-00312: online log 3 thread 1: '/opt/oracle/oradata/conner/redo03.log'
损坏的是active的日志文件:
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM
---------- ---------- ---------- ---------- ---------- --- ----------------
1 1 159 10485760 1 NO INACTIVE 897592312 19-OCT-05
2 1 158 10485760 1 NO INACTIVE 897572310 19-OCT-05
3 1 160 10485760 1 NO ACTIVE 897612314 19-OCT-05
4 1 161 1048576 1 NO CURRENT 897612440 19-OCT-05
只好使用另外一个隐含参数_allow_resetlogs_corruption强制启动数据库，设置此参数之后，在数据库Open过程中，Oracle会跳过某些一致性检查，从而使数据库可能跳过不一致状态，Open打开:
SQL> alter system set "_allow_resetlogs_corruption"=true scope=spfile;
System altered.
SQL> shutdown immediate;
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.
Total System Global Area 97588504 bytes
Fixed Size 451864 bytes
Variable Size 33554432 bytes
Database Buffers 62914560 bytes
Redo Buffers 667648 bytes
Database mounted.
SQL> recover database using backup controlfile until cancel;
ORA-00279: change 897612315 generated at 10/19/2005 16:54:18 needed for thread 1
ORA-00289: suggestion : /opt/oracle/oradata/conner/archive/1_160.dbf
ORA-00280: change 897612315 for thread 1 is in sequence #160
Specify log: {=suggested | filename | AUTO | CANCEL}
cancel
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/oradata/conner/system01.dbf'
ORA-01112: media recovery not started
SQL> alter database open resetlogs;
Database altered.
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area 97588504 bytes
Fixed Size 451864 bytes
Variable Size 33554432 bytes
Database Buffers 62914560 bytes
Redo Buffers 667648 bytes
Database mounted.
Database opened.
幸运的时候数据库就可以成功Open，如果不幸可能会遇到一系列的Ora-600错误（最常见的是2662错误），或者在openOra-600错误，或者在open以后操作数据库数据时刻出现Ora-600错误，此时就需要使用多种手段继续进行调整恢复。
如果注意观察alert日志，我们可能会发现类似以下日志:
Fri Jun 10 16:30:25 2005
alter database open resetlogs
Fri Jun 10 16:30:25 2005
RESETLOGS is being done without consistancy checks. This may result in a corrupted database. The database should be recreated.
RESETLOGS after incomplete recovery UNTIL CHANGE 240677200
Resetting resetlogs activation ID 3171937922 (0xbd0fee82)
Oracle告诉我们，强制resetlogs跳过了一致性检查，可能导致数据库损坏，数据库应当重建。不一致恢复最后恢复到的Change号是：240677200。通常使用此方法Open数据库之后，应该立即通过导出、导入重建数据库。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/509190/viewspace-862851/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/509190/viewspace-862851/