【Oracle数据恢复】Redo Log重做日志文件坏块Corruption的解决 ORA-16038 ORA-00354 ORA-00353 ORA-00367 ORA-01624

当数据库打开时若某一个redo log重做日志文件存在日志损坏/坏块corruption,则可能出现以下错误:

 

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

 

诗檀软件专业数据库修复团队

 

服务热线 : 13764045638   QQ号:47079569    邮箱:service@parnassusdata.com

 

ORA-16038 log %s sequence# %s cannot be archived
ORA-354 corrupt redo log block header
ORA-353 log corruption near block  change time 
ORA-367 checksum error in log file header

[oracle@mlab2 ~]$ oerr ora 16038
16038, 00000, "log %s sequence# %s cannot be archived"
// *Cause:  An attempt was made to archive the named file, but the
//          file could not be archived. Examine the secondary error
//          messages to determine the cause of the error.
// *Action: No action is required.

[oracle@mlab2 ~]$ oerr ora 354
00354, 00000, "corrupt redo log block header"
// *Cause:  The block header on the redo block indicated by the accompanying
//          error, is not reasonable.
// *Action: Do recovery with a good version of the log or do time based
//          recovery up to the indicated time. If this happens when archiving,
//          archiving of the problem log can be skipped by clearing the log
//          with the UNARCHIVED option. This must be followed by a backup of
//          every datafile to insure recoverability of the database.
[oracle@mlab2 ~]$ oerr ora 353
00353, 00000, "log corruption near block %s change %s time %s"
// *Cause:  Some type of redo log corruption has been discovered. This error
//          describes the location of the corruption. Accompanying errors
//          describe the type of corruption.
// *Action: Do recovery with a good version of the log or do incomplete
//          recovery up to the indicated change or time.
www.askmaclean.com
[oracle@mlab2 ~]$ oerr ora 367
00367, 00000, "checksum error in log file header"
// *Cause:  The file header for the redo log contains a checksum that does
//          not match the value calculated from the file header as read from
//          disk. This means the file header is corrupted
// *Action: Find the correct file and try again.

 

 

 

 

对于不同状态的在线日志文件online redo logfile 损坏/坏块,有不同的解决方案。

对于以下2种情况将不能drop online的redo logfile,他们是:

  1. 如果仅仅有2个redo logfile groups
  2. 损坏的redo logfile文件属于当前日志组 current logfile group; V$LOG.STATUS=CURRENT

 

 

解决方案大致如下:

 

可以通过clear 命令来清理有问题的日志文件,语法如下:

alter database clear <unarchived> logfile group <integer>;
alter database clear <unarchived> logfile ‘<filename>’;

 

例如:

alter database clear logfile group 1;
alter database clear unarchived logfile group 1;

 

 

对于status=current 或者 status=active的日志将无法被清理, 如果清理会报 ORA-01624:

 

SQL> alter database clear unarchived logfile group 5;
alter database clear unarchived logfile group 5
*
ERROR at line 1:
ORA-01624: log 5 needed for crash recovery of instance G10R25 (thread 1)
ORA-00312: online log 5 thread 1: '/s01/G10R25/onlinelog/o1_mf_5_954q1vdo_.log'
www.askmaclean.com
[oracle@vrh8 ~]$ oerr ora 1624
01624, 00000, "log %s needed for crash recovery of instance %s (thread %s)"
// *Cause:  A log cannot be dropped or cleared until the thread's checkpoint
//          has advanced out of the log.
// *Action: If the database is not open, then open it. Crash recovery will
//          advance the checkpoint. If the database is open force a global
//          checkpoint. If the log is corrupted so that the database cannot
//          be opened, it may be necessary to do incomplete recovery until
//          cancel at this log.

 

 

对于status=active的日志较为简单,只要能顺利完成一个alter system checkpoint就可以将其状态改为INACTIVE之后再CLEAR。

对于status=current的online redo logfile则比较麻烦,一般需要动用隐藏参数”_ALLOW_RESETLOGS_CORRUPTION”

关注dbDao.com的新浪微博

扫码关注dbDao.com 微信公众号:

Comments

  1. The LGWR terminates with the following error while Opening the database.ORA-00321: log 2 of thread 1, cannot update log file headerORA-00312: online log 2 thread 1: ‘/u01/oradata/corrupt/redo_2b.log’ORA-27069 :-skgfdisp: attempt to do I/O beyond the range of the fileThe redo log file size at OS level has become 0 bytes due to Hardware problem.Perform the following Steps to Confirm the same.Go to unix prompt :-ls -lrt for example :-ls -lrt /u01/oradata/corrupt/redo_2b.log-rw-r—– 1 oracle dba 0 Oct 21 23:51 redo_02b.logExecute Select * from v$log at mount stage to check the actual size of the redo log file.default we need two redo log groups to start the database.If there are only two redo group and the problem is with One of the Group do the following :-Add a new group in Mount Stage.To add one member——————–SQL> ALTER DATABASE ADD LOGFILE (‘/u01/oradata/corrupt/redo_3a.log’) size < >M;To add two member———————SQL> ALTER DATABASE ADD LOGFILE (‘/u01/oradata/corrupt/redo_3a.log’ ,’/u01/oradata/corrupt/redo_3b.log’ ) size <>M;Drop the problematic Group containing the redo log file.SQL>ALTER DATABASE DROP LOGFILE GROUP ;SQL> ALTER DATABASE OPEN ;If there are more than Two group :-Drop the Group containing the redo log file which has been zeroed out at OS level.SQL>ALTER DATABASE DROP LOGFILE GROUP ;SQL> ALTER DATABASE OPEN ;Option 2========If the status of the redo log file is INACTIVE,ACTIVE,CURRENT and multiplexed redo log member of the Group is good do the following :-SQL> Shutdown Immediate ;Copy the good multiplex member of the Redo log Group to the location where the other member of redo log file of the same group has been zeroed out.Rename the Copied member to the Original redo log file name which has been zeroed out.For example :-If Group1 Contains two members /u01/redo1a.log and /u02/redo1b.log .The Second member /u01/redo1b.log has been zeroed out at OS level but the first member /u01/redo1a.log is still intact.SQL>Shutdown immediate;Copy the good redo log member to the location of redo log member which has been zeroed outcp /u01/redo1a.log /u01/redo1b.logSQL> StartupOption 3========If the the status of the redo log file is CURRENT and the redo log file is not multiplexed or both themember of redo log group have been zeroed out then the best option is to do an Point in time recoveryBefore the error occurred.

Speak Your Mind

TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569