Oracle 如何从丢失联机重做日志和ORA-312 和ORA-313中恢复

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

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

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

 

 

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.


ORA-00313 oerr ora 313
00313, 00000, "open failed for members of log group %s of thread %s"
// *Cause:  The online log cannot be opened. May not be able to find file.
// *Action: See accompanying errors and make log available.


 

适用于:

Oracle Database – Standard Edition – Version 9.0.1.0 and later
Oracle Database – Enterprise Edition – Version 9.0.1.0 and later
Oracle Database – Personal Edition – Version 9.0.1.0 and later
Generic UNIX

目的

本文旨在介绍在丢失联机重做日志后一些常见恢复情况

范围

所有要恢复Oracle数据库的Oracle support Analyst,DBA和顾问

详细内容

在丢失联机重做日志文件后恢复:情况

如果媒体故障影响了一个数据库的联机重做日志,则适当恢复过程取决于以下:

– 联机重做日志的配置:镜像或非镜像
– 媒体故障的类型:临时或永久
– 受媒体故障影响的联机重做日志类型:CURRENT, ACTIVE, UNARCHIVED,或INACTIVE

– 在丢失归档日志文件前数据库被正常关闭

 

1) 在丢失复用联机重做日志组的一个成员后恢复
如果数据库的联机重做日志是多路复用的,且每个联机重做日志组至少有一个成员未受媒体故障影响,则数据库继续正常运行,但错误信息被写入日志writer跟踪文件和数据库的 alert_SID.log。

执行计划

如果硬件问题是临时的,则更正它。log writer 进程访问之前不可用的联机重做日志文件,就像问题从不存在。

如果硬件问题是永久的,则drop 损坏成员,并使用以下步骤添加一个新成员。

替换重做日志组的一个受损成员:

在V$LOGFILE中定位受损成员的文件名。如果文件无法访问,状态为INVALID:

SQL> SELECT GROUP#, STATUS, MEMBER FROM V$LOGFILE WHERE STATUS=’INVALID’;

GROUP#    STATUS       MEMBER
——-   ———–  ———————
0002      INVALID      /oracle/oradata/trgt/redo02.log
+ Drop 受损成员。
例如,要从组2中drop成员 redo01.log,发出:

SQL> ALTER DATABASE DROP LOGFILE MEMBER ‘/oracle/oradata/trgt/redo02.log’;
+ 在组中添加新成员。
例如,要添加redo02.log到组2,发出:

SQL> ALTER DATABASE ADD LOGFILE MEMBER ‘/oracle/oradata/trgt/redo02b.log’ TO GROUP 2;

+ 如果你想要添加的文件已存在,则它必须与其他组成员大小相同,且你必须指定REUSE。

例如:

SQL> ALTER DATABASE ADD LOGFILE MEMBER ‘/oracle/oradata/trgt/redo02b.log’ REUSE TO GROUP 2;

2) 丢失非活跃联机重做日志组

如果所有INACTIVE状态的联机重做日志组的成员都受损,则过程取决于你是否可以修复损坏非活跃重做日志组的媒体问题。

如果故障是… 临时的…那么解决这个问题。需要时,LGWR可以重新使用重做日志组。

 

如果故障是… 永久的…那么受损的非活跃联机重做日志组最终停止正常的数据库操作。

执行计划

通过发出“ALTER DATABASE CLEAR LOGFILE”手动重新初始化损坏组

当数据库打开或关闭时,你可以清除非活跃重做日志组。

该过程取决于损坏组是否已被归档。

要清除一个已被归档的非活跃,联机重做日志组

如果数据库被关闭,则启动新实例并mount数据库:
STARTUP MOUNT

重新初始化受损的日志组。
例如,要清除重做日志组2。发出以下语句:

ALTER DATABASE CLEAR LOGFILE GROUP 2;
清除非活跃,尚未归档的重做

清除尚未归档重做日志使其不归档被重新使用。如果在日志中最后一个变化之前启动备份,此操作使得备份不能使用,除非该文件在日志中的第一个变化前6被脱机。因此,如果你需要被清除的日志文件来恢复备份,则你就不能恢复该备份。此外,由于丢失的日志,它可以防止从备份中完全恢复。

要清除一个非活跃,未被归档的联机重做日志组:

如果数据库被关闭,则启动新的实例并mount数据库:

STARTUP MOUNT
使用UNARCHIVED 关键字清除日志。例如,要清除日志组2,发出:

ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 2;

 

如果有脱机的数据文件需要被清除的日志使其联机,则需要关键字UNRECOVERABLE DATAFILE。数据文件和它的整个表空间需要被drop的,因为需要使其联机的重做正在被清除,且没有它的副本。

例如输入:

ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 2 UNRECOVERABLE DATAFILE;

注:如果这是在Active(当前)日志文件上执行,就会发生错误:

立即备份整个数据库,包括控制文件,让你有一个备份,你可以使用完全恢复而不依赖于清除日志组。

立即备份整个数据库,包括控制文件,这样你就有一个能用于完全恢复的备份,而无需依赖于被清除的日志组。

 

CLEAR LOGFILE 操作失败

当无法进行以下操作,ALTER DATABASE CLEAR LOGFILE 会由于媒体故障显示I/O 错误:

* 通过以当前配置的重做日志文件名重建重做日志文件,将它重新定位到其他媒体
* 重新使用当前配置的日志文件名来重建重做日志文件,因为这个名字本身是无效的或不可用的(例如,由于媒体故障)

在这些情况下,ALTER DATABASE CLEAR LOGFILE语句(在收到I/ O错误之前)已成功通知控制文件,日志已被清除,且不需要归档。

在CLEAR LOGFILE语句试图创建新的重做日志文件,并对其写入0的步骤中,发生I / O错误。这一事实反映在V $ LOG.CLEARING_CURRENT中。

3) 在正常关闭后丢失联机日志 

你使数据库在归档日志模式,立即关闭并删除联机重做日志之一,在这种情况下,只有2组,每组有1个日志成员。当你尝试打开数据库时,会收到以下错误:

ora-313 open failed for members of log group 2 of thread 1.
ora-312 online log 2 thread 1 ‘filename’

恢复丢失的日志是不可能的,所以要执行以下操作!

mount数据库,并在v$log中查看被删除日志是否是最新的。

– 如果丢失的日志不是当前的,只要drop日志组(alter database drop logfile group N)。

如果只有2个日志组,那么drop这个之前就必须添加另一组。

– 如果丢失的日志是当前的,只要执行伪恢复,然后打开重置日志。

sql> connect / as sysdba
sql> startup mount
sql> recover database until cancel;
(cancel immediately)
sql> alter database open resetlogs;

 

确保在尝试打开数据库之前,联机日志文件的位置(目录)存在。如果不可用,则创建它并重新运行resetlogs,否则这会给错误

注:如果实例恢复所需的当前联机日志丢失,则必须将数据库还原并恢复到最后一个可用的归档日志文件。

 

参考

NOTE:1366482.1 – Open Resetlogs Reports Errors ORA-00313 and ORA-00312 to Alert
NOTE:230829.1 – Recover database after disk loss

Comment

*

沪ICP备14014813号-2

沪公网安备 31010802001379号