zoukankan      html  css  js  c++  java
  • Redo丢失的4种情况及处理方法

    转载:http://blog.itpub.net/23135684/viewspace-626935/

    一.说明:
    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字段)。

    例子:

    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:APPORADATAORCLREDO03.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://space.itpub.net/23135684/viewspace-627343

    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恢复。

    五.结论:
    非正常关闭的当前日志丢失,可能导致数据库启动后的混乱,并可能造成少量数据的丢失。其他情况不会导致数据的丢失。
  • 相关阅读:
    [转] KVM I/O slowness on RHEL 6
    QEMU KVM libvirt 手册(3)
    QEMU KVM libvirt手册(2): monitor
    QEMU KVM libvirt 手册(1): 安装
    CentOS7下JSP连接Mysql
    使用Tomcat搭建基于域名的虚拟机
    CentOS7下搭建Tomcat服务器
    Nginx在线服务状态下平滑升级或新增模块
    源码安装LNMP
    二进制包安装Mysql
  • 原文地址:https://www.cnblogs.com/jimeper/p/3976666.html
Copyright © 2011-2022 走看看