Bounded Recovery

首先，我們來看兩個OGG同步中可能的問題：

l oracle線上日志包含已送出的和未送出的事務，但OGG隻會将已送出的事務寫入到隊列檔案。是以，針對未送出的事務，特别是未送出的長事務，OGG會怎樣處理呢？ 

當 Extract 程序在 redo log 中遇到某個事務的起點（在 Oracle 中通常為第一個可執行的 sql 語句）時，便會将從該事務中捕獲到的所有資料緩存到記憶體中。即使開始該事務不包含任何資料，Extract 程序也必須将事務緩存到記憶體中，因為該事務中後面的操作可能包含要捕獲的資料。當Extract 程序在 redolog 中遇到事務的 commit 記錄，便會将緩存在記憶體中的整個事務寫入trail 檔案，并将其從記憶體中清除。當 Extract 程序遇到事務的  rollback 記錄時，便會丢棄緩存中緩存的整個事務。在 Extract 程序處理 commit 或 rollback 記錄之前，都會視事務為Open狀态（未送出或復原的），并持續不斷地收集該事務的資訊。

如果 Extract 在遇到事務的 commit 或 rollback 記錄之前停止，則在 Extract 程序重新開機後，必須對所有緩存在記憶體中的資訊進行恢複，重新從規定日志中抽取長事物的資訊，那麼這個恢複時間就會比較長。

l 有些長事務是在批處理作業中，需要幾個小時才能執行完成，比如晚上跑批的作業。OGG在解析過程中，會從這些事務一執行就開始讀取線上日志，但這些事務可能會持續很久，在期間，線上日志可能會切換到歸檔日志，同時這期間也會有其它事務在執行和送出，如果長事務一直未送出，歸檔日志又因為定期的rman備份而删除，OGG将如何處理？

針對以上情況，OGG有2種處理方式，

第一種就是使用正常恢複歸檔的方式，即恢複OGG需要的所有歸檔日志，可能是從長事務開始的那個歸檔開始，這樣OGG将從事務開始的檢查點開始解析；

第二種方式就是使用Bounded Recovery的方式，下面的内容将讨論這種方式。

簡單來說，BR（Bounded Recovery ）預設的設定是4小時，即每4小時OGG抽取程序會做一個檢查點，在每個檢查點的時間點上，OGG會檢查長事務，并将超過4小時的長事務的狀态寫入到磁盤（如果沒有達到4小時，則此事務不會被BR寫入），預設儲存在OGG安裝目錄的BR目錄下。在每個BR的間隔點，這個操作會一直持續，直到事務送出，或事務復原。

Bounded Recovery可以保證當Extract 程序出于任何原因（計劃停機或意外停機）停止後，無論在程序停止時的時間點上存在多少個未送出的事務還是這些事務持續的時間多麼久，Extract 程序都能進行高效地恢複。

注意 在将此參數修改為預設設定以外的其他設定時，請聯系 Oracle Support 擷取指導。大多數生産環境無需修改此參數。 

設定BRINTERVAL為20分鐘：

BR BRINTERVAL 20M

Use the BR parameter to control the Bounded Recovery (BR) feature. This feature currentlysupports Oracle databases

Bounded Recovery 的工作原理

在 Extract 程序處理 commit 或 rollback 記錄之前，都會視事務為Open狀态（未送出或復原的）,如果事務處于 open 狀态的時間超過 BR 參數的 BRINTERVAL選項中指定的Bounded Recovery 間隔，則 OGG 就視該事務為長時間運作的 open 事務。例如，如果 Bounded Recovery 間隔為4小時，則任何持續時間超過4小時的事務都可視為長時間運作的 open 事務。每隔一個 Bounded Recovery 間隔，Extract 都會進行一次Bounded Recovery 檢查點操作，該檢查點操作會将 Extract 程序的目前狀态和資料寫入磁盤，包括任何存在的長時間運作的事務的狀态和資料。如果 Extract 程序在一個Bounded Recovery檢查點之後停止，則該程序将從上一個Bounded Recovery間隔點或上一個BoundedRecovery 檢查點位置進行恢複，而不會從 redo log 或 archived log 中最早的長時間運作 open 事務的起始位置開始進行恢複。

Bounded Recovery的最大時間 （Extract 恢複到停止時間點的最大時間）永遠不會超過目前 Bounded Recovery 檢查點間隔的 2 倍。實際的恢複時間将由如下因素決定：

● 從 Extract 程序停止開始到最後一個有效的 Bounded Recovery 間隔之間的時間。

●整個恢複期間 Extract 程序的處理情況。

●之前寫入磁盤的事務的處理時間比。

Bounded Recovery 處理這些事務（丢棄這些事務）要比其在首次必須執行磁盤寫入時要快很多。 大多數事務資料的重新處理都包含此過程。

當 Extract 程序進行恢複時，該程序會 restore 最後一個Bounded Recovery 檢查點（包含任何長時間運作的事務）儲存的資料和狀态。

例如，如果一個事務處于 open 狀态的時間有 24 小時，Bounded Recovery 間隔為 4 小時。在這種情況下，Extract  程序最長恢複時間不會超過 8 小時（<=4*2），可能會小于該時間。這取決于 Extract 程序停止的時間點和最後一個有效的 Bounded Recovery 檢查點以及 Extract 程序在該期間的活動情況。

Bounded Recovery 解決的問題

利用磁盤的持久性來存儲和恢複長時間運作的事務，這種情形很少發生，但是一旦發生，這一特性将顯著地提高 Extract 程序執行恢複的性能。當 Extract 程序停止時其正在處理的長時間運作的事務在 redo log 中的起始位置通常都在一個非常早（距離目前時間非常久遠）的位置。一個長時間運作的事務很可能跨越了大量的老舊的日志檔案（online和archived log），這些比較早的日志檔案，有些早已認證備份轉移到其他的儲存設備或者直接删除了。如果通過讀取日志從長時間運作的事務在日志當中的起始位置開始進行恢複，則需要大量的時間成本，其實在資料庫中長時間運作的事務時非常少的，在此過程中大部分的工作實際上是又捕獲了一遍已經寫入 trail 或

Discarded 檔案的其他事務。利用 bounded recovery 可以 restore 磁盤上存留的長時間運作的事務資訊（同 Oracle 資料庫中的 restore 操作類似），可以避免上述的額外重複工作。

參考：

http://blog.csdn.net/xiangsir/article/details/8785484

http://www.cnblogs.com/margiex/p/4073081.html