Oracle 如何从丢失联机重做日志和ORA-312 和ORA-313中恢复 ORA-00312: 联机日志 线程 : '' ORA-00313: 无法打开日志组 (用于线程 ) 的成员

如果自己搞不定可以找诗檀软件专业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