自前些天寫了乙個指令碼之後，今天特意測試了一下，沒想到一下子發現了乙個大問題。有一套一主兩備的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
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的恢復在有些時候還是有一些捷徑可走，明白了原理，加上點運氣，問題就可以引刃而解。
oracle 歸檔和快速恢復區
select group sequence members,status from v log 檢視日誌組的狀態 shutdown immediate 致性關庫 startup mount 啟動到 mount 狀態 alter database archivelog 開啟歸檔模式 alter dat...
10g關閉歸檔 啟用閃回恢復區歸檔
一 關閉歸檔 1 啟動sql plus以管理身份登入oracle資料庫 sql connect as sysdba 2 關閉資料庫例項 sql shutdown immediate 3 備份資料庫 在對資料庫做出任何重要的改變之前，建議備份資料庫以免出現任何問題。4 啟動乙個新的例項並裝載資料庫，但...
dataguard引數的解釋
1.db name，資料庫 名字，需要保持同乙個data guard 中所有資料庫db name相同 primary端和 standby 端相同 db name ora10g db name ora10g 2.db unique name，對應資料庫的例項名，每乙個資料庫需要指定乙個唯一的名字 pr...