154
基於scn備份解決dg歸檔丟失的方法論
當主備同步中斷了，備庫想快一點恢複，偏偏這個時候歸檔太多恢複不過來或者說需要的歸檔直接丟了，有些人可能會選擇重新搭建備庫。如果庫小的話還是可以的，但是如果主庫比較大可能耗費的時間會很久，而且容易出一些問題。單單是全庫備份恢複這個時間就不會短，更何況中間還會涉及到很多東西。
那麼我們今天就是來聊聊有沒有什麼更好的辦法來處理這種情況。因為這種情況還是比較常見的，至少我遇到過好幾次了。
這裏我們回顧一下dg的三種同步模式；
這種保護模式是為了確保主庫故障時，不會發生數據丟失。要提供這種級別的保護，恢複所需的重做數據必須在事務提交之前，同時寫到本地聯機重做日誌和至少一個備用數據庫上的備重做日誌。若如果主庫無法寫重做流到備庫，主庫將會關閉。
提供了可能的最高級別的數據保護，而不用與主數據庫的可用性相折中。
與最大保護模式的區分
與最大保護模式相同：在恢複所需的重做數據，必須在事務提交之前同時寫到本地聯機重做日誌和至少一個備用數據庫上的備重做日誌。
與最大保護模式不相同：如果故障導致主數據庫無法寫重做流到異地備庫重做日誌時，主數據庫不會關閉，在沒有達到net_timeout之前主庫會hang住，但是並不是shutdown。而後主數據庫以最大性能模式運行直到故障消除，並且解決所有重做日誌文件的中斷。當所有中斷解決之後，主數據庫自動繼續以最大可用性模式運行。
這種模式確保如果主數據庫故障，但是隻有當第二次故障沒有阻止完整的重做數據集從主數據庫發送到至少一個備用數據庫時，不發生數據丟失。
3.最大性能模式
這種保護模式（默認）提供了可能的最高級別的數據保護，而不影響主數據庫的性能。這是通過允許事務在恢複該事務所需重做日誌在寫到本地聯機重做日誌後，可以立即提交而實現的。
主數據庫的重做數據流也寫到至少一個備用數據庫，但是那個重做流相對於創建重做數據的事務是異步導入的，就不用 LGWR SYNC了，而之前兩種模式都要用LGWR SYNC。
當所用的網絡連接有足夠的帶寬，這種模式提供了近似於最大可用性模式的數據保護級別，並且對數據庫性能的影響最小。
最大保護和最大可用性模式需要備庫重做日誌文件配置在配置中至少一個備用數據庫上
為了保證主庫不受影響，至少到目前為止我接觸的生產環境的dg都是最大性能模式。但是這種環境會出現一種情況。由於某種原因，當備庫出了一些故障、網絡不通或者其他情況，導致主備同步中斷，主庫的在線日誌或者歸檔沒辦法正常傳輸到備庫。這樣主庫產生一個又一個的歸檔，但是這些歸檔都沒辦法傳到備庫。當然我們在恢複了出現的問題之後會從斷了的地方重新傳到備庫以完成同步。
不過這中間可能會有一些情況，比如：我們本地的歸檔空間有限，主備的同步一時半會恢複不了，如果一直留著歸檔，當歸檔空間滿了就會影響主庫正常運行。不得不刪除一部分。也有可能主備恢複時間過長，產生了很多很多歸檔，將它們傳到備庫應用會消耗很多很多時間。
當主備同步中斷了，備庫想快一點恢複，偏偏這個時候歸檔太多恢複不過來或者說需要的歸檔直接丟了。這個時候我們該怎麼辦？
其實我們這次的題目已經提出了解決方法，就是利用基於scn的備份去恢複我們的備庫，從而繞開中間過多或者丟失的歸檔。
那麼基於scn備份究竟是什麼意思呢?
我們都知道我們傳統的dg都是屬於物理dg，下麵是物理dg的簡單解釋：
物理備用數據庫：以基於塊對塊的主數據庫同樣的磁盤數據庫結構，物理備用數據庫物理等同於主數據庫。
特性：
- 數據庫的每一個塊的內容包括塊的邏輯位置都和主庫完全一致
- DG通過執行重做應用，維護物理備用數據庫
- 物理STANDBY 打開flashbackdatabase後可以完全讀寫打開
- 物理備用數據庫使用通過oracle恢複機製，從歸檔重做日誌文件或直接從備係統上的備重做日誌文件用用重做數據來恢複。
- 物理備用數據庫可用於執行備份
- 物理備用數據庫使用重做應用技術使用低級別的恢複機製應用更改，繞過了所有SQL基本代碼層，因此應用海量重做數據最有效，性能大於邏輯備份。
大家看了物理備庫的簡單解釋之後需要注意的是，其實主備保持一致是不是就是主備的每一個塊內容都一樣？數據庫一般的塊是8K，如果每個8K都一樣，是不是就意味著兩邊數據庫內容是一樣的？
假如當前備庫應用到了100號歸檔，這個時候主備的網絡斷了，主庫一直生成歸檔生成到了150號，這期間一直沒有傳遞歸檔到備庫。當我們恢複了主備的網絡，主庫生成的101到150這50個歸檔都傳送到了備庫。
那麼此時，備庫應用完這50個歸檔是不是備庫就和主庫保持一致了，都是150號歸檔的時候塊的內容？如果我們將101到150這一段時間塊的改變找出來，在備庫上麵進行修改，這樣是不是就等同於應用了這50個歸檔？
我們單獨拿一個塊來說，假如100號歸檔的時候數據庫內這個塊記錄了一列的值為5，150號歸檔的時候數據庫內這個塊記錄這一行的值為6。當我們將這個5改成6時，是否就意味著這個塊完成了101-150號歸檔的所有改變？
反過來說，假如100號歸檔的時候數據庫內這個塊記錄了一列的值為5，150號歸檔的時候數據庫內這個塊記錄這一行的值還是為5那麼我們就可以不修改他，他還是完成了101-150號歸檔的所有改變。
所以到這裏我們應該明白了，找到這段時間塊的改變，全部應用到備庫，我們就不用去恢複那些過多的或者缺失的歸檔。
如何完成一次基於scn的恢複？
所以回到我們的方法，我們找到備庫端數據文件中最低的scn，然後在主庫去基於這個scn進行備份，這個時候rman回去掃描整個主庫的塊，如果塊內的scn小於備庫端數據文件中最低的scn，則證明這個塊從備庫應用到的時間點到現在是沒有改變的，就忽略掉這個塊。
如果塊內的scn大於備庫端數據文件中最低的scn證明在這個階段這個快進行了修改，就記錄下這個塊的內容。等拿到備庫端去恢複的時候就替換這個塊的內容。
當然我們是有官方文檔的支撐的，並不是我們憑空想象出來的處理方法，這裏提供官方mos的id，供大家自行去查看：
Steps to perform for Rolling Forward aPhysical Standby Database using RMAN Incremental Backup. (Doc ID 836986.1)
我們需要注意的是這個方法適用的版本在10.2以後：
Oracle Database - Enterprise Edition - Version 10.2.0.1 to later
1、查找備庫數據文件最低的scn
select CHECKPOINT_CHANGE# fromv$datafile_header order by 1;
select CHECKPOINT_CHANGE# fromv$database order by 1;
2、執行增量備份
rman target /
run
{configure controlfile autobackup on;
sql 'alter system switch logfile';
BACKUP INCREMENTAL FROM SCN 15078013867424 DATABASE FORMAT '/IC_%d_%u/'tag 'FORSTANDBY';
}
3、恢複控製文件
restore standby controlfile ;
4、恢複數據庫
recover database;
本文來自雲棲社區合作夥伴“數據和雲”，了解相關信息可以關注“數據和雲”微信公眾號
最後更新：2017-11-07 12:03:46