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


      这篇文章重点讨论Redo丢失的几种情况,及每种情况的处理方法。

    一.
    说明:
    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:\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 1;

    数据库已更改。

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

    第四种的测试案例:

    [oracle@prod dbs]$
    [oracle@prod dbs]$
    [oracle@prod dbs]$ sqlplus / as sysdba

    SQL*Plus: Release 11.2.0.4.0 Production on Mon Oct 22 14:01:31 2018

    Copyright (c) 1982, 2013, Oracle. All rights reserved.


    Connected to:
    Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
    With the Partitioning, OLAP, Data Mining and Real Application Testing options

    SQL> select * from v$log;

    GROUP# THREAD# SEQUENCE# BYTES BLOCKSIZE MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME
    ---------- ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- --------- ------------ ---------
    1 1 1 52428800 512 1 NO CURRENT 986240 22-OCT-18 2.8147E+14
    2 1 0 52428800 512 1 YES UNUSED 0 0
    3 1 0 52428800 512 1 YES UNUSED 0 0

    SQL> select * from v$logfile ;

    GROUP# STATUS TYPE MEMBER IS_
    ---------- ------- ------- ----------------------------------------- -------------------------
    3 ONLINE /data/datafile/prod3/redo03.log NO
    2 ONLINE /data/datafile/prod3/redo02.log NO
    1 ONLINE /data/datafile/prod3/redo01.log NO

    SQL>
    SQL>
    SQL> exit
    Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
    With the Partitioning, OLAP, Data Mining and Real Application Testing options
    [oracle@prod dbs]$ rm /data/datafile/prod3/redo01.log
    [oracle@prod dbs]$ rm /data/datafile/prod3/redo02.log
    [oracle@prod dbs]$ rm /data/datafile/prod3/redo03.log
    [oracle@prod dbs]$
    [oracle@prod dbs]$
    [oracle@prod dbs]$
    [oracle@prod dbs]$ sqlplus / as sysdba

    SQL*Plus: Release 11.2.0.4.0 Production on Mon Oct 22 14:02:17 2018

    Copyright (c) 1982, 2013, Oracle. All rights reserved.


    Connected to:
    Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
    With the Partitioning, OLAP, Data Mining and Real Application Testing options

    SQL> shutdown abort
    ORACLE instance shut down.
    SQL>
    SQL>
    SQL> exit
    Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
    With the Partitioning, OLAP, Data Mining and Real Application Testing options
    [oracle@prod dbs]$
    [oracle@prod dbs]$
    [oracle@prod dbs]$ sqlplus / as sysdba

    SQL*Plus: Release 11.2.0.4.0 Production on Mon Oct 22 14:02:29 2018

    Copyright (c) 1982, 2013, Oracle. All rights reserved.

    Connected to an idle instance.

    SQL> startup
    ORACLE instance started.

    Total System Global Area 1185853440 bytes
    Fixed Size 2252664 bytes
    Variable Size 754974856 bytes
    Database Buffers 419430400 bytes
    Redo Buffers 9195520 bytes
    Database mounted.
    ORA-00313: open failed for members of log group 1 of thread 1
    ORA-00312: online log 1 thread 1: '/data/datafile/prod3/redo01.log'
    ORA-27037: unable to obtain file status
    Linux-x86_64 Error: 2: No such file or directory
    Additional information: 3


    SQL>
    SQL> create pfile from spfile ;

    File created.

    SQL> exit
    Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
    With the Partitioning, OLAP, Data Mining and Real Application Testing options[oracle@prod dbs]$
    [oracle@prod dbs]$
    [oracle@prod dbs]$
    [oracle@prod dbs]$ echo "*._allow_resetlogs_corruption=TRUE">> initprod3.ora

    [oracle@prod dbs]$ cat initprod3.ora
    prod3.__db_cache_size=419430400
    prod3.__java_pool_size=16777216
    prod3.__large_pool_size=83886080
    prod3.__oracle_base='/u01/app/oracle'#ORACLE_BASE set from environment
    prod3.__pga_aggregate_target=486539264
    prod3.__sga_target=704643072
    prod3.__shared_io_pool_size=0
    prod3.__shared_pool_size=167772160
    prod3.__streams_pool_size=0
    *.audit_file_dest='/u01/app/oracle/admin/prod3/adump'
    *.audit_trail='db'
    *.compatible='11.2.0.4.0'
    *.control_files='/data/datafile/prod3/control01.ctl','/data/datafile/prod3/control02.ctl'
    *.db_block_size=8192
    *.db_domain=''
    *.db_name='prod3'
    *.diagnostic_dest='/u01/app/oracle'
    *.dispatchers='(PROTOCOL=TCP) (SERVICE=prod3XDB)'
    *.local_listener='LISTENER_PROD3'
    *.memory_target=1189085184
    *.open_cursors=300
    *.processes=150
    *.remote_login_passwordfile='EXCLUSIVE'
    *.undo_tablespace='UNDOTBS1'
    *._allow_resetlogs_corruption=TRUE

    [oracle@prod dbs]$
    [oracle@prod dbs]$ sqlplus / as sysdba

    SQL*Plus: Release 11.2.0.4.0 Production on Mon Oct 22 14:04:20 2018

    Copyright (c) 1982, 2013, Oracle. All rights reserved.


    Connected to:
    Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
    With the Partitioning, OLAP, Data Mining and Real Application Testing options

    SQL> startup nomount pfile='/u01/app/oracle/product/11.2.0/db_1/dbs/initprod3.ora';
    ORA-01081: cannot start already-running ORACLE - shut it down first
    SQL> shutdown immediate
    ORA-01109: database not open


    Database dismounted.
    ORACLE instance shut down.
    SQL> startup nomount pfile='/u01/app/oracle/product/11.2.0/db_1/dbs/initprod3.ora';
    ORACLE instance started.

    Total System Global Area 1185853440 bytes
    Fixed Size 2252664 bytes
    Variable Size 754974856 bytes
    Database Buffers 419430400 bytes
    Redo Buffers 9195520 bytes
    SQL> alter database mount ;

    Database altered.

    SQL> alter database open ;
    alter database open
    *
    ERROR at line 1:
    ORA-00313: open failed for members of log group 1 of thread 1
    ORA-00312: online log 1 thread 1: '/data/datafile/prod3/redo01.log'
    ORA-27037: unable to obtain file status
    Linux-x86_64 Error: 2: No such file or directory
    Additional information: 3


    SQL> recover database until cancel ;
    ORA-00279: change 986243 generated at 10/22/2018 13:59:43 needed for thread 1
    ORA-00289: suggestion : /u01/app/oracle/product/11.2.0/db_1/dbs/arch1_1_990194382.dbf
    ORA-00280: change 986243 for thread 1 is in sequence #1


    Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
    auto
    ORA-00308: cannot open archived log '/u01/app/oracle/product/11.2.0/db_1/dbs/arch1_1_990194382.dbf'
    ORA-27037: unable to obtain file status
    Linux-x86_64 Error: 2: No such file or directory
    Additional information: 3


    ORA-00308: cannot open archived log '/u01/app/oracle/product/11.2.0/db_1/dbs/arch1_1_990194382.dbf'
    ORA-27037: unable to obtain file status
    Linux-x86_64 Error: 2: No such file or directory
    Additional information: 3


    ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
    ORA-01194: file 1 needs more recovery to be consistent
    ORA-01110: data file 1: '/data/datafile/prod3/system01.dbf'


    SQL> alter database open ;
    alter database open
    *
    ERROR at line 1:
    ORA-01589: must use RESETLOGS or NORESETLOGS option for database open


    SQL> alter database open resetlogs ;

    Database altered.

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

    FILE# CHECKPOINT_CHANGE# FUZ
    ---------- ------------------ ---
    1       986247   YES
    2       986247   YES
    3      986247   YES
    4      986247   YES

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

    FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
    ---------- ------------------ ------------
    1           986247
    2           986247
    3          986247
    4          986247

    SQL


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

  • 相关阅读:
    个人总结
    第二阶段第十次站立会议
    第二阶段第九次站立会议
    vim编辑器使用方式
    centos正确关机方式
    python315题的漫漫通关之路
    Django之视图函数
    Django之路由系统
    Django之静态文件配置
    Django之MTV
  • 原文地址:https://www.cnblogs.com/chendian0/p/10328258.html
Copyright © 2020-2023  润新知