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