Oracle重做日志丢失的故障处理 （zt）

.

[@more@]

Oracle重做日志
Oracle的重做日志文件(Online redo logfile)循环记录了数据库所有的事务。它的大小、个数和存储位置对数据库性能和恢复有重要影响。它一般由大小相同的几组文件构成。我们可以查看数据库视图v$logfile知道redo logfile的个数和存储位置。对每一个Oracle数据库都要求至少具有两个联机重做日志。
每一次新的事务提交时，Oracle将该事务写入日志文件，但并非此时也将修改的数据块写回原数据文件。由于内存读写和磁盘I/O存在几个数量级的效率差别，Oracle通过减少数据文件的物理I/O读写来大大提高数据库的性能；同时，又通过优先写日志文件来保证数据的正确性和一致性。基于这种机制，重做日志文件在数据库的实例恢复和介质恢复时至关重要，是oracle数据库最重要的物理文件之一。
如果数据库在启动时检测到重做日志丢失，数据库将无法启动。如果数据库在运行时切换日志文件组，检测到下一组或者全部的重做日志丢失，数据库将会崩溃。由于磁盘介质损坏或者人为的误删除文件，造成严重后果的事件近期时有发生。本文列举了重做日志丢失的数据库恢复，但如果按照冗余原则合理分布日志文件组的成员，如果工程师了解日志文件的基本原理和使用原则，就完全可以避免出现下列问题。
恢复方法
故障现象
SQL> startup mount
Oracle Instance Started
Database mounted
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: '/ORACLE/ORADATA/H817/REDO01.LOG'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) The system cannot find the file specified.
恢复注意事项
以下所列举的恢复方法，都属于不完全恢复或者强制恢复，会丢失当前重做日志中的事务数据。一旦操作不当，将带来数据丢失等严重后果，请遵循以下几个恢复原则：
1. 请勿在生产系统上试用。
2. 如果生产系统出现重做日志文件丢失的故障，请勿自行操作破坏现场，应该立刻联系Oracle工程师。
3. 恢复成功之后，需要马上做一次数据库的全备份。
4. 建议重做日志文件一定要实现镜象在不同的磁盘上，避免这种情况的发生。
恢复方法
1. 首先检查重做日志文件状态，看看报错的日志文件的状态是否为Current
SQL> select * from v$log;
SQL> select * from v$logfile;
2. 如果重做日志文件状态为Inactive，我们可以直接清除该日志文件的内容：
SQL> alter database clear logfile '/ORACLE/ORADATA/H817/REDO01.LOG';
3. 如果重做日志文件状态为Current，恢复工作较为复杂，有以下四种情况：
1）通过下面步骤，数据库顺利打开
SQL> recover database until cancel;
Type Cancel when prompted
SQL>alter database open resetlogs;

2）第一种情况的'recover database until cancel' 操作遇到ORA-01547，ORA-01194，ORA-01110错误，需要整个数据库的物理备份，并根据归档日志恢复到错误时间点，前提是数据库是归档模式。
restore old backup
SQL> startup mount
SQL> recover database until cancel using backup controlfile;
SQL> alter database open resetlogs;

3）如果数据库是非归档模式，只能恢复整个物理备份，然后直接打开数据库。这种情况将丢失物理备份至故障发生前的全部数据。

4）如果数据库是非归档模式，且没有物理备份，只能通过特殊的隐含参数，允许数据库不一致的状况下打开数据库。这种恢复方法是没有办法之后的恢复方法，将导致数据库不一致，一般情况下不要采用。如确有需要，请在Oracle的技术人员指导下使用该方法。
 关闭数据库
SQL>shutdown immediate
 在init.ora中加入如下参数
_allow_resetlogs_corruption=TRUE
 重新启动数据库,利用until cancel恢复
SQL>recover database until cancel;
Cancel
 打开数据库
SQL>alter database open resetlogs;
 数据库被打开后，马上执行一个全库导出。
关闭数据库，在init.ora中去掉_all_resetlogs_corrupt参数

----------------------------------------------------------------

例子 ：

华西妇科医院数据库恢复技术报告

技术简报第一期

引言

1. 1. 目的

记录华西妇科医院Oracle数据库恢复记录

1. 术语
   1. Ora-00313

当Oracle在线日志redo日志文件损坏时,会出现Ora-00313 错误,不能使用alter database clear redofilename命令清除当前日志文件。

ORA-00313 open failed for members of log group string of thread string

Cause: The online log cannot be opened. The file may not be in the expected location.

1. Ora-00600

Ora-00600是Oracle内部错误，最常见的是bug导致，解决起来比较困难。但一些"经典"的600错误也可以通过努力解决。

ORA-00600 internal error code, arguments: [string], [string], [string], [string], [string], [string], [string], [string]

1. 人员

姓名	角色	说明
贺学兵	现场服务
张会兰	商务谈判
徐浪	远程判断故障

1. 参考资料

Oracel错误文档、ITPUB.NET、Oracle MetaLink

1. 处理过程
   1. 查看AlterOrcl.Ora文件

   应客户要求，18:00左右到达现场，查看AlterOrcl.ora文件，发现如下错误,Redo01.log日志文件在25日15:00左右物理损坏，导致数据库停止响应。

   Sun Jun 25 15:02:44 2006

   Errors in file d:oracleadminORCLudumpORA01084.TRC:

   ORA-00333: ??????? 1709 ?? 340 ??

   ORA-00312: ???? 1 ?? 1: 'D:ORACLEORADATAORCLREDO01.LOG'

   ORA-27091: skgfqio: ???? I/O ??

   OSD-04006: ReadFile() 失败,无法自文件读取

   O/S-Error: (OS 23) 数据错误 (循环冗余检查)。

1. 冷备份数据库

在冷备份数据库过程中，Redo01.log文件无法拷贝，Redo01文件物理上完全损坏了，操作系统无法识别，拷贝其他文件数据文件、控制文件和另外2个redo文件。

1. 尝试打开数据库，再现故障

启动数据库时，出现Ora-00312错误，提示Redo01日志文件损坏。

SQL> STARTUP mount;

ORACLE 例程已经启动。

Total System Global Area 322705436 bytes

Fixed Size 75804 bytes

Variable Size 70893568 bytes

Database Buffers 251658240 bytes

Redo Buffers 77824 bytes

数据库装载完毕。

SQL> alter database open;

alter database open

*

ERROR 位于第 1 行:

ORA-00368: ????????????

ORA-00353: ??????? 1888 ?? 3296409 ?? 06/25/2006 14:46:01

ORA-00312: ???? 1 ?? 1: 'D:ORACLEORADATAORCLREDO01.LOG'

1. 尝试清除(Clear)Redo01文件

如果是非当前Redo文件，可以使用clear命令清除redo文件，但由于是当前(状态为Current)Redo文件，clear 操作不成功。

SQL> alter database clear logfile 'D:ORACLEORADATAORCLREDO01.LOG';

alter database clear logfile 'D:ORACLEORADATAORCLREDO01.LOG'

ERROR 位于第 1 行:

ORA-01624: ??1?????????1

ORA-00312: ???? 1 ?? 1: 'D:ORACLEORADATAORCLREDO01.LOG'

1. 查看Redo日志文件

可以看到Redo01日志文件为当前使用的日志文件，所以无法执行Clear操作。由于数据库打开时，必须读取Redo文件内容，以进行事务处理和实例恢复，正常的处理过程无法跳过这个环节。决定使用_allow_resetlogs_corruption隐含参数，跳过当前日志文件的检查。使用Oracle隐含参数有一定的风险，可能会带来一些意想不到的错误，在使用隐含参数进行恢复前一定要做好数据库的冷备份。

SQL> select * from v$log;

GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIME

---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ----------

1 1 5065 1048576 1 NO CURRENT 3296082 25-6? -06

2 1 0 1048576 1 NO UNUSED 3295488 25-6? -06

3 1 5064 1048576 1 NO INACTIVE 3295780 25-6? -06

SQL> select * from v$logfile;

GROUP# STATUS MEMBER

---------- ------- ------------------------------------------------------------------------

1 D:ORACLEORADATAORCLREDO01.LOG

2 D:ORACLEORADATAORCLREDO02.LOG

3 D:ORACLEORADATAORCLREDO03.LOG

1. 使用_allow_resetlogs_corruption=true隐含参数，尝试打开数据库

在initOrcl.ora参数中加入_allow_resetlogs_corruption=true，重新启动数据库到Mount状态。进行介质恢复，最大限度的恢复数据。

SQL> startup mount;

ORACLE 例程已经启动。

Total System Global Area 322705436 bytes

Fixed Size 75804 bytes

Variable Size 70893568 bytes

Database Buffers 251658240 bytes

Redo Buffers 77824 bytes

数据库装载完毕。

SQL> recover database until cancel;

ORA-00279: ?? 3296082 (? 06/25/2006 12:23:46 ??) ???? 1 ????

ORA-00289: ??: D:ORACLEORA81RDBMSARC05065.001

ORA-00280: ?? 3296082 ???? 1 ???? # 5065 ???

指定日志: {=suggested | filename | AUTO | CANCEL}

auto

ORA-00308: ???????? 'D:ORACLEORA81RDBMSARC05065.001'

ORA-27041: ??????

OSD-04002: N^7(4r?*ND

O/S-Error: (OS 2) O5M3UR2;5=V86(5DND

ORA-01547: ??: RECOVER ??? OPEN RESETLOGS ???????

ORA-01194: ??1?????????????

ORA-01110: ???? 1: 'D:ORACLEORADATAORCLSYSTEM01.DBF'

出现了一些错误提示，不必理会，由于执行的是不完全恢复，使用resetlogs选项强行打开数据库。 打开数据库时，出现ORA-00603错误，数据库打开失败。

SQL> alter database open resetlogs;

alter database open resetlogs*

ERROR 位于第 1 行:

ORA-00603: ORACLE server session terminated by fatal error

根据ORA-00603的解释，查看相应的Trace文件，发现了Ora-00600 [2662]错误，使用隐含参数果然造成了意想不到的错误。继续分析Trace文件，还发现了Ora-00600 [4194]错误。

Tue Jun 27 18:34:25 2006

Errors in file d:oracleadminORCLudumpORA01612.TRC:

ORA-00603: ORACLE server session terminated by fatal error

ORA-00600: internal error code, arguments: [2662], [0], [3296087], [0], [3296364], [8388610], [], []

ORA-00600: internal error code, arguments: [2662], [0], [3296086], [0], [3296364], [8388610], [], []

1. 解决Ora-00600 [2662]错误

使用隐含参数_ALLOW_RESETLOGS_CORRUPTION后resetlogs打开数据库,我们可能会由于SCN不一致而遭遇到ORA-00600 2662号错误，可以通过Oracle的10015号内部事件在mount状态下调整SCN。

SQL> startup mount;

ORACLE 例程已经启动。

Total System Global Area 322705436 bytes

Fixed Size 75804 bytes

Variable Size 70893568 bytes

Database Buffers 251658240 bytes

Redo Buffers 77824 bytes

数据库装载完毕。

SQL> alter session set events '10015 trace name adjust_scn level 10';

会话已更改。

SQL> alter database open;

数据库已更改。

SQL> spool off;

可以看到，成功打开了数据库，但由于使用了隐含参数恢复数据库，需要重建数据库。

1. 重建数据库

使用EXP全库导出数据，导出时现了ora_00600 [4194]错误，存储过程、同义词部分表的约束没有导出。这也再次提醒我们了使用了隐含参数打开的数据库必须重建，不能继续使用。

最后使用ZLHIS服务器管理工具重建存储过程等对象。在对象检查时，发现大量的约束处理于无效状态，但数据又没有问题，可能是EXP导出时存在问题，删除这部分约束重建。至此，问题解决。

1. 处理结果

完成数据恢复，经用户核对，无数据丢失。

1. 总结与展望
   1. 关键点分析

• 理解_allow_resetlogs_corruption隐含参数。
• 使用10015内部事件调整Oracle SCN号。
• 尽量不要使用隐含参数，这些参数是oracle所不推荐使用的，也不是万能的！如果使用了可能会存在一些遗留的问题，如果非要使用，建议使用后一定要exp/imp重建建立数据库。

1. 推广分析

可作为一个恢复案例进行推广

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/35489/viewspace-1002662/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/35489/viewspace-1002662/