1. 首页
  2. IT资讯

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. 首先检查重做日志文件状态,看看报错的日志文件的状态是否为CurrentSQL> 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. 目的

记录华西妇科医院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]错误,存储过程、同义词部分表的约束没有导出。这也再次提醒我们了使用了隐含参数打开的数据库必须重建,不能继续使用。

Oracle重做日志丢失的故障处理 (zt)

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

  1. 处理结果

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

  1. 总结与展望
    1. 关键点分析
  • 理解_allow_resetlogs_corruption隐含参数。
  • 使用10015内部事件调整Oracle SCN号。
  • 尽量不要使用隐含参数,这些参数是oracle所不推荐使用的,也不是万能的!如果使用了可能会存在一些遗留的问题,如果非要使用,建议使用后一定要exp/imp重建建立数据库。
  1. 推广分析

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

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

主题测试文章,只做测试使用。发布者:布吉卡,转转请注明出处:http://www.cxybcw.com/195009.html

联系我们

13687733322

在线咨询:点击这里给我发消息

邮件:1877088071@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息

QR code