你好,游客 登录 注册 搜索
背景:
阅读新闻

Redo丢失的4种情况及处理方法

[日期:2014-11-26] 来源:Linux社区  作者:尛样儿 [字体: ]

一.说明:
1.以下所说的当前日志指日志状态为CURRENT,ACTIVE,非当前日志指日志状态为INACTIVE
2.不用考虑归档和非归档模式,2种模式下的Redo丢失情况一样。

二.丢失Redo的4种情况:
第一种情况:非当前日志,正常关闭。
第二种情况:非当前日志,非正常关闭。
第三种情况:当前日志,正常关闭。
第四种情况:当前日志,非正常关闭。

三.处理方法:
第一、二种情况的处理方法一样,直接把日志文件clear即可。
SQL> alter database clear logfile group 3;
SQL> alter database clear unarchived logfile group 3;//如果INACTIVE状态的在线Redo还未归档,增加关键字unarchived完成clear操作。(ACTIVE,INACTIVE都有可能未完成归档,归档是否完成可以查看v$log.archived字段)。

RMAN_RAC恢复至单机时Redo日志引发的“恐慌”  http://www.linuxidc.com/Linux/2014-10/108695.htm

Oracle RAC下调节Redo log file 文件大小 http://www.linuxidc.com/Linux/2014-10/107837.htm

Oracle非关键文件恢复,Redo、临时文件、索引文件、密码文件 http://www.linuxidc.com/Linux/2014-09/107394.htm

Oracle Redo Log 机制 小结 http://www.linuxidc.com/Linux/2014-09/107129.htm

Oracle Redo log 大小及组数的设置(在线修改日志组数目及组成员个数) http://www.linuxidc.com/Linux/2014-09/106796.htm

current online Redo logfile 丢失的处理方法 http://www.linuxidc.com/Linux/2014-08/105979.htm

例子:

SQL> startup mount

ORACLE 例程已经启动。

Total System Global Area  263639040 bytes

Fixed Size                  1384012 bytes

Variable Size            167772596 bytes

Database Buffers          88080384 bytes

Redo Buffers                6402048 bytes

数据库装载完毕。
SQL> select group#,thread#,status,archived from v$log;

    GROUP#    THREAD# STATUS                          ARCHIV

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

        1          1 CURRENT                          NO

        3          1 ACTIVE                          NO

        2          1 INACTIVE                        YES

 


SQL> alter database clear logfile group 3;

alter database clear logfile group 3

*

第 1 行出现错误:

ORA-01624: 日志 3 是紧急恢复实例 orcl (线程 1) 所必需的

ORA-00312: 联机日志 3 线程 1: 'E:\APP\ORADATA\ORCL\REDO03.LOG'


SQL> alter database clear logfile group 2;

数据库已更改。

第三种情况的处理办法:
SQL>startup mount;
SQL>recover database until cancel;
SQL>alter database open resetlogs;


例子1:


SQL> shutdown immediate

数据库已经关闭。

已经卸载数据库。

ORACLE 例程已经关闭。

SQL> startup mount

ORACLE 例程已经启动。

 


Total System Global Area  263639040 bytes

Fixed Size                  1384012 bytes

Variable Size            167772596 bytes

Database Buffers          88080384 bytes

Redo Buffers                6402048 bytes

数据库装载完毕。

SQL> alter database open resetlogs;

alter database open resetlogs

*

第 1 行出现错误:

ORA-01139: RESETLOGS 选项仅在不完全数据库恢复后有效

SQL> recover database until cancel;

完成介质恢复。

SQL> alter database open resetlogs;

数据库已更改。

例子2(第三种情况的第二个处理方法):

SQL> shutdown immediate

数据库已经关闭。

已经卸载数据库。

ORACLE 例程已经关闭。

SQL> startup mount

ORACLE 例程已经启动。

Total System Global Area  263639040 bytes

Fixed Size                  1384012 bytes

Variable Size            167772596 bytes

Database Buffers          88080384 bytes

Redo Buffers                6402048 bytes

数据库装载完毕。

SQL> select group#,thread#,status,archived from v$log;


    GROUP#    THREAD# STATUS                          ARCHIV

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

        1          1 CURRENT                          NO

        3          1 INACTIVE                        YES

        2          1 INACTIVE                        YES

 


SQL> alter database clear logfile group 2;

 


数据库已更改。

SQL> alter database clear logfile group 3;

数据库已更改。

SQL> alter database clear unarchived logfile group 3;

数据库已更改。

这里CURRENT的Redo日志文件组能被clear unarchived。

SQL> alter database open;

数据库已更改。

如果Redo日志文件丢失,clear操作完成之后将在原有位置创建新的Redo日志文件。

第四种情况的处理方法:
1.通过备份来还原、恢复数据。
2.通过修改参数文件中的参数
_allow_resetlogs_corruption=TRUE
来强制启动数据库。//虽然能够启动数据库到open状态,但是启动后的数据库数据字典、数据有可能导致不一致的情况出现,故需要在open下把整个数据库export,然后删除库,重建,再将export的数据import到新的数据库中。

四.验证数据库是否正常关闭的方法

SQL> select open_mode from v$database;

OPEN_MODE

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

READ WRITE

SQL> select status from v$instance;

STATUS

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

OPEN

SQL> select file#,checkpoint_change#,fuzzy from v$datafile_header;

    FILE# CHECKPOINT_CHANGE# FUZ

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

        1            1165820 YES

        2            1165820 YES

        3            1165820 YES

        4            1165820 YES

        FUZZY bit in datafile header means that there may have been writes into a datafile after the last checkpoint. E.g. there may be changes written to datafile with higher SCN than checkpoint_change# stored in datafile header (seen from v$datafile_header.checkpoint_change#).
        FUZYY表示模糊性,意思是,该数据文件处于模糊状态,在最近一次CHECKPOINT后,该文件上的数据可能被修改过了,但没来得及更新到该文件上(或者该文件不知道),需要读取日志信息来判断。

SQL> select file#,checkpoint_change#,last_change# from v$datafile;

    FILE# CHECKPOINT_CHANGE# LAST_CHANGE#

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

        1            1165820

        2            1165820

        3            1165820

        4            1165820

由于数据库是打开的状态,所以终止SCN是空,SCN的内容可参考文章:http://www.linuxidc.com/Linux/2014-11/109877.htm

SQL> shutdown immediate

数据库已经关闭。

已经卸载数据库。

ORACLE 例程已经关闭。

SQL> startup mount

ORACLE 例程已经启动。

Total System Global Area  313860096 bytes

Fixed Size                  1384352 bytes

Variable Size            155189344 bytes

Database Buffers          150994944 bytes

Redo Buffers                6291456 bytes

数据库装载完毕。

SQL> select file#,checkpoint_change#,fuzzy from v$datafile_header;

    FILE# CHECKPOINT_CHANGE# FUZ

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

        1            1166324 NO

        2            1166324 NO

        3            1166324 NO

        4            1166324 NO

        在正常管理数据库的情况下,FUZZY字段都应该是NO,表示没有模糊不清的SCN存储在数据文件中。

SQL> select file#,checkpoint_change#,last_change# from v$datafile;

    FILE# CHECKPOINT_CHANGE# LAST_CHANGE#

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

        1            1166324      1166324

        2            1166324      1166324

        3            1166324      1166324

        4            1166324      1166324

        正常关闭数据库的终止SCN应该和启动SCN相同。FUZZY等于NO,��数据库的终止SCN等于启动SCN等于数据文件SCN,那么可以认为数据库是正常关闭,且在打开数据库之前不需要执行实例恢复或Crash恢复。

SQL> alter database open;

数据库已更改。

SQL> shutdown abort

ORACLE 例程已经关闭。

SQL> startup mount

ORACLE 例程已经启动。

Total System Global Area  313860096 bytes

Fixed Size                  1384352 bytes

Variable Size            155189344 bytes

Database Buffers          150994944 bytes

Redo Buffers                6291456 bytes

数据库装载完毕。

SQL> select file#,checkpoint_change#,fuzzy from v$datafile_header;

    FILE# CHECKPOINT_CHANGE# FUZ

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

        1            1166327 YES

        2            1166327 YES

        3            1166327 YES

        4            1166327 YES

        非正常关闭数据库实例,FUZZY字段的值是YES。

SQL> select file#,checkpoint_change#,last_change# from v$datafile;

    FILE# CHECKPOINT_CHANGE# LAST_CHANGE#

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

        1            1166327

        2            1166327

        3            1166327

        4            1166327
        非正常关闭数据库实例,终止SCN依然为空。那么,在数据库被打开之前必须使用归档Redo日志完成实例恢复或Crash恢复。

五.结论:
非正常关闭的当前日志丢失,可能导致数据库启动后的混乱,并可能造成少量数据的丢失。其他情况不会导致数据的丢失。

相关文章:《alter system archive log current / all / switch logfile》:http://www.linuxidc.com/Linux/2014-11/109875.htm

更多Oracle相关信息见Oracle 专题页面 http://www.linuxidc.com/topicnews.aspx?tid=12

本文永久更新链接地址http://www.linuxidc.com/Linux/2014-11/109876.htm

linux
相关资讯       redo  Redo丢失 
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数

       

评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款