Data Guard跳歸檔恢復的案例

其實這個時候問題已經很嚴峻了。

我們首先在備庫1上檢視SCN的情況。
idle> col CURRENT_SCN format 99999999999999999999999999999
idle>SELECT CURRENT_SCN FROM V$DATABASE;
                   CURRENT_SCN
------------------------------
                  188670376120

備庫2上的SCN情況如下：
SQL> col CURRENT_SCN format 99999999999999999999999999999
SQL> SELECT CURRENT_SCN FROM V$DATABASE;
                   CURRENT_SCN
------------------------------
                  188611153769
可以看到延遲已經很大了。可能透過這個數字對比還不夠明顯。從後臺日誌可以看到，上一次啟動到READ ONLY的時候是在3月份了，也就意味著這個問題已經過去了快半年了。這種情況下增量恢復還有希望嗎，在主庫端檢視了下最近的歸檔情況，發現這個資料庫的資料變更頻率很低，基本是每天一次，所以近半年的時間大概是150~180個左右的歸檔，好像還能勉強接受。

在備庫1增量匯出的情況如下，我們基於SCN 188611153769，也就是備庫2上一個較舊的SCN
[@TEST.test.com backup_stage]$ rman target /
Recovery Manager: Release 10.2.0.4.0 - Production on Mon Aug 15 11:32:56 2016
Copyright (c) 1982, 2007, Oracle.  All rights reserved.
connected to target database: TEST (DBID=1731005384, not open)
RMAN> BACKUP INCREMENTAL FROM SCN 188611153769 DATABASE FORMAT '/home/oracle/backup_stage/stest2_%U' tag 'FORSTANDBY';
在真實環境嘗試，和實驗還是有很大的差別，短暫的等待後竟然丟擲了一個錯誤。

不過虛驚一場，這個是備份的路徑問題，導致空間不足，切換了一個路徑再次嘗試，很快就完成了，大概用了7分鐘的時間。

這個時候複製到備庫2上會恢復，當然還是需要先恢復控制檔案，可以從主庫生成一個映象過去，或者從備庫2複製也可以。
否則在恢復的時候會丟擲類似下面的錯誤。

備庫2先註冊這個增量備份，/U01/backup_stage/increment_backup是增量備份存放的路徑
[@stest4.test.com ~]$ rman target /
RMAN> catalog start with '/U01/backup_stage/increment_backup';
Starting implicit crosscheck backup at 15-AUG-16
using target database control file instead of recovery catalog
採用下面的方式恢復:
RMAN>  recover database noredo ;
恢復的時間更短，大概是1分多鐘。

後臺的日誌會輸出類似下面的內容：

恢復後檢視SCN的情況如下，已經有了更新。
SQL> col CURRENT_SCN format 9999999999999999999999
SQL> SELECT CURRENT_SCN FROM V$DATABASE;
            CURRENT_SCN
-----------------------
           188670376925
後面所做的就是開啟恢復模式。
SQL> recover managed standby database disconnect from session;
Media recovery complete.
這個時候檢視資料庫日誌就會發現備庫2很快就追評了歸檔GAP，一切又恢復了正常。
透過這個案例可以看到Data Guard的恢復在有些時候還是有一些捷徑可走，明白了原理，加上點運氣，問題就可以引刃而解。