Redo丟失的4種情況及處理方法

Redo丟失的4種情況及處理方法

一.說明：
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日誌引發的“恐慌” 

Oracle RAC下調節Redo log file 檔案大小

Oracle非關鍵檔案恢複,Redo、臨時檔案、索引檔案、密碼檔案

Oracle Redo Log 機制 小結

Oracle Redo log 大小及組數的設定（線上修改日誌組數目及群組成員個數）

current online Redo logfile 丟失的處理方法

例子：

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的內容可參考文章：

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》：