ORA-00354，ORA-00353和ORA-00312的处理方法
在日志文件损坏或者dump这些损坏的日志文件的时候，通常回收到类似下面的错误：
ORA-00354: corrupt redo log block header
ORA-00353: log corruption near block 3740 change 0 time 04/11/2006 13:49:56
ORA-00312: online log 1 thread 1: '/oracle/oradata/TSMISC02/redo01.log'
或者：
sys@TSMISC02> ALTER SYSTEM DUMP LOGFILE '/oracle/oradata/TSMISC02/redo01.log';
ALTER SYSTEM DUMP LOGFILE '/oracle/oradata/TSMISC02/redo01.log'
*
ERROR at line 1:
ORA-00354: corrupt redo log block header
ORA-00353: log corruption near block 3740 change 6918597 time 04/10/2006 23:53:24
ORA-00334: archived log: '/oracle/oradata/TSMISC02/redo01.log'
Elapsed: 00:00:03.36
sys@TSMISC02>
这里首先介绍一下oracle使用日志文件的策略。每一个数据库至少有两个或多个日志文件组（redo log group），每个组中至少有一个日志成员（redo log member）。日志文件的主要功能是真实完整的记录对数据库作的全部修改。在出现故障时，如果不能将修改数据永久地写入数据文件，则系统将利用日志前滚来恢复数据库数据文件。日志文件主要是保护数据库以防止故障。
如果LGWR 至少能够访问一个组内的某一个成员，那么oracle就会对这个组内的可访问成员继续照常进行读写操作，也就是说，LGWR 将忽略组内的不可用成员。如果在日志切换时LGWR 无法访问下一个组的所有成员或者损坏的日志文件时改组中日志成员，数据库的正常操作就无法进行了。这也就是oracle常说的，为了防止日志文件的故障或丢失，强烈建议镜象日志(mirrored redo log)，即，在不同磁盘上维护至少两个或多个日志文件（redo log member）副本的作用——只要组内有一个可用的成员，oracle就会继续“正常”操作。
回到这里，如果数据库发生日志文件的上述损坏，不管是哪种原因造成的，解决方法无外乎是使用完好的文件恢复已经损坏的文件，或者初始化损坏的文件组等等（日志文件的故障处理不做这里的重点介绍，我将会在其他的文章中逐一说明和举例）。
我们这里主要是使用了_disable_logging＝true这个隐含参数（实际性能故障诊断时，你可以通过alert.log找到相关信息）造成了归档数据库中，所有日志不能归档，最终数据库不能继续操作的问题，因此解决方法就是：
（a）如果是使用了隐含参数，那么去掉这个隐含参数：
alter system set "_disable_logging"=false scope=both;
（b）然后，初始化损坏的redo log：
alter database clear unarchived logfile '<logilename>';
例如：
sys@TSMISC02> alter system set "_disable_logging"=false scope=both;
System altered.
Elapsed: 00:00:00.01
sys@TSMISC02>
sys@TSMISC02> alter database clear unarchived logfile '/oracle/oradata/TSMISC02/redo02.log';
Database altered.
Elapsed: 00:00:00.18
sys@TSMISC02> alter database clear unarchived logfile '/oracle/oradata/TSMISC02/redo03.log';
Database altered.
Elapsed: 00:00:00.17
sys@TSMISC02>
