自前些天寫了一個指令碼之後，今天特意測試了一下，沒想到一下子發現了一個大問題。有一套一主兩備的10gR2環境，一個異機備庫一直在READ ONLY狀態，也就意味著資料庫在開啟之後一直忘了恢復應用歸檔，然後在某一天發現時，已經延遲了好幾個月。無論怎樣，還得慶幸發現了這個問題。
目前來看一種行之有效的方法就是重搭備庫，但是這種修復方式需要大量的磁碟空間，而且需要恢復的時間較長，怎麼改進呢，可以考慮透過基於SCN的增量備份來跳歸檔恢復。目前的環境是一主兩備，再怎麼改進呢，我們可以基於備庫1來完成基於SCN的增量備份，在備庫2完成恢復，對於主庫幾乎是完全透明，無影響的。
整個示意圖如下，透過在Standby1上面基於SCN匯出增量備份，複製到備庫2上去恢復，最後再和主庫匯合即可。

所以在這個問題上，還是對10g的DG Broker頗有微詞，因為11g中是ADG不會存在這類問題，在10g中備庫為READ ONLY，哪怕丟失了大量的歸檔，備庫也是檢查透過的。
直到在切換到恢復模式的時候，後臺日誌還不清楚到底發生了什麼。

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

我們首先在備庫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的恢復在有些時候還是有一些捷徑可走，明白了原理，加上點運氣，問題就可以引刃而解。

Data Guard跳歸檔恢復的案例

相關文章