提示：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来重建。
IXDBA.NET社区论坛
二、是日志组中有活动的事务，数据库需要媒体恢复，日志组需要用来同步，有两种补救办法
A:最好的办法就是通过不完全恢复，可以保证数据库的一致性，但是这种办法要求在归档方式下，并且有可用的备份
B:通过强制性恢复，但是可能导致数据库不一致。
下面的情况假定当前日志损坏，并且没有备份，所以只有采取强制性恢复：
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;
