[转]Oracle Hidden Parameter:_allow_resetlogs_corruption

本文转自eygle博客，原文地址：http://www.eygle.com/archives/2005/10/oracle_hidden_allow_resetlogs_corruption.html

提示：Oracle的隐含参数只应该在测试环境或者在Oracle Support的支持下使用。
在使用_disable_logging进一步的测试中，试图通过switch logfile进行日志切换，结果重起居然报出日志文件损坏。

 SQL> startup
 ORACLE instance started.

 Total System Global Area    bytes
 Fixed Size                    bytes
 Variable Size               bytes
 Database Buffers            bytes
 Redo Buffers                  bytes
 Database mounted.
 Database opened.
 SQL> select count(*) from t;
 select count(*) from t
                      *
 ERROR at line :
 ORA-: table or view does not exist

 SQL> create table t as select * from dba_users;

 Table created.

 SQL> select count(*) from t;

   COUNT(*)
 ----------
         

试图通过switch logfile触发检查点:

 SQL> alter system switch logfile;

 System altered.

 SQL> insert into t select * from t;

  rows created.

 SQL> commit;

 Commit complete.

 SQL> select count(*) from t;

   COUNT(*)
 ----------
         

日志文件损坏(未测试是否可以重复出现):

 SQL> startup force;
 ORACLE instance started.

 Total System Global Area    bytes
 Fixed Size                    bytes
 Variable Size               bytes
 Database Buffers            bytes
 Redo Buffers                  bytes
 Database mounted.
 ORA-: corrupt redo log block header
 ORA-: log corruption near block  change  time // ::
 ORA-: online log  thread : '/opt/oracle/oradata/conner/redo03.log'

损坏的是active的日志文件:

SQL> select * from v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIM
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ---------
                                         NO  INACTIVE              -OCT-
                                         NO  INACTIVE              -OCT-
                                         NO  ACTIVE                -OCT-
                                          NO  CURRENT               -OCT-

只好使用另外一个隐含参数_allow_resetlogs_corruption强制启动数据库，设置此参数之后，在数据库Open过程中，Oracle会跳过某些一致性检查，从而使数据库可能跳过不一致状态，Open打开:

 SQL> alter system set "_allow_resetlogs_corruption"=true scope=spfile;

 System altered.

 SQL> shutdown immediate;
 ORA-: database not open

 Database dismounted.
 ORACLE instance shut down.
 SQL> startup mount;
 ORACLE instance started.

 Total System Global Area    bytes
 Fixed Size                    bytes
 Variable Size               bytes
 Database Buffers            bytes
 Redo Buffers                  bytes
 Database mounted.
 SQL> recover database using backup controlfile until cancel;
 ORA-: change  generated at // :: needed for thread
 ORA-: suggestion : /opt/oracle/oradata/conner/archive/1_160.dbf
 ORA-: change  for thread  is in sequence #

 Specify log: {=suggested | filename | AUTO | CANCEL}
 cancel
 ORA-: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
 ORA-: file  needs more recovery to be consistent
 ORA-: data file : '/opt/oracle/oradata/conner/system01.dbf'

 ORA-: 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    bytes
 Fixed Size                    bytes
 Variable Size               bytes
 Database Buffers            bytes
 Redo Buffers                  bytes
 Database mounted.
 Database opened.

幸运的时候数据库就可以成功Open，如果不幸可能会遇到一系列的Ora-600错误（最常见的是2662错误）此时就需要使用多种手段继续进行调整恢复。

如果注意观察alert日志，我们可能会发现类似以下日志:

 Fri Jun  ::
 alter database open resetlogs
 Fri Jun  ::
 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
 Resetting resetlogs activation ID  (0xbd0fee82)

Oracle告诉我们，强制resetlogs跳过了一致性检查，可能导致数据库损坏，数据库应当重建。
不一致恢复最后恢复到的Change号是：240677200

通常使用此方法Open数据库之后，应该立即通过导出、导入重建数据库。