如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!
诗檀软件专业数据库修复团队
服务热线 : 13764045638 QQ号:47079569 邮箱:service@parnassusdata.com
ORA-00354 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. ORA-00353 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. ORA-00312 oerr ora 312 00312, 00000, "online log %s thread %s: '%s'" // *Cause: This message reports the filename for details of another message. // *Action: Other messages will accompany this message. See the // associated messages for the appropriate action to take.
适用于:
Oracle Database – Enterprise Edition – 版本8.1.7.4 到12.1.0.1 [Release 8.1.7 to 12.1]
本文信息适用于任何平台。
** 05-Dec-2014检查相关性**
症状
在警报日志文件中报告以下错误:
ORA-354: corrupt redo log block header
ORA-353: log corruption near block %s change %s time %s
ORA-312: online log %s thread %s: ‘%s’
ORA-312: online log %s thread %s: ‘%s’
ORA-312 reports all the redo log file names for the same redo log group number. Example for redo log group number 3 which has two redo log file members:
ORA-00354: corrupt redo log block header
ORA-00353: log corruption near block 1892904 change 878787 time 12/05/2014 13:17:10
ORA-00312: online log 3 thread 1: ‘/oracle/dbs/log3_A.dbf’
ORA-00312: online log 3 thread 1: ‘/oracle/dbs/log3_B.dbf’
两个联机重做日志成员都在错误中被报告。
如果所有重做成员都损坏且数据库在归档日志模式下,警报日志还可能包含下一个信息:
ARCn: All Archive destinations made inactive due to error 354
….
CORRUPTION DETECTED: thread %d sequence %d log %d at block %d. Arch found corrupt blocks
示例:
ARC1: All Archive destinations made inactive due to error 354
….
CORRUPTION DETECTED: thread 1 sequence 28 log 3 at block 1892904. Arch found corrupt blocks
原因
在重做日志组中联机重做日志文件成员中可能的损坏。
如果Oracle在归档一个日志成员时检测到损坏,它会尝试从组中第二个成员读取系统重做块。如果发现重做日志组中所有成员的这个块都是损坏的,归档将无法进行。
原因通常由于错误OS或坏的硬件的overwrite/missed。
解决方案
验证哪些重做日志文件成员损坏
执行下一个语句来确认重做日志成员损坏:
alter system dump logfile ‘&name’ VALIDATE;
这是为了确认重做日志成员已损坏;如果重做日志成员损坏,它应当生成错误。例如:
SQL> alter system dump logfile ‘/oracle/dbs/t_log3.f’ validate;
alter system dump logfile ‘/oracle/dbs/t_log3.f’ validate
*
ERROR at line 1:
ORA-00354: corrupt redo log block header
ORA-00353: log corruption near block 1892904 change 869569 time 12/05/2014 13:17:10
ORA-00334: archived log: ‘/oracle/dbs/log3_A.f’
对同一重做日志组号的所有重做日志文件重复相同步骤。可以执行下一个查询来识别成员:
select member
from v$logfile
where group# = &group_number;
方案1
如果其中一个重做日志成员未损坏,则多次执行下一个命令直到相应重做日志组号在status=CURRENT视图中处于status=CURRENT。
alter system switch logfile;
select status
from v$log
where group#=&log_group_number;
或者等到重做日志被再使用,且块会被修复。
方案2
如果所有重做日志成员都损坏,按照Oracle文档来”clear [unarchived] logfile group”:
Section Clearing a Redo Log File in the Database Administrator’s Guide.
在清理重做日志组后,警告日志可能被更新以下信息:
WARNING! CLEARING REDO LOG WHICH HAS NOT BEEN ARCHIVED. BACKUPS TAKEN
BEFORE [Timestamp] (CHANGE [scn]) CANNOT BE USED FOR RECOVERY.
确保在清理重做日志组创建一个新备份。
同样注意重做日志组号的一个单独成员无法被清理;会生成错误ORA-1514 :
SQL> alter database clear unarchived logfile ‘/oracle/dbs/log3_A.dbf’;
alter database clear unarchived logfile ‘/oracle/dbs/log3_.dbf’
*
ERROR at line 1:
ORA-01514: error in log specification: no such log
ORA-01517: log member: ‘/oracle/dbs/t_log3_A.dbf’
这是预期的行为。
Comment