Oracle GoldenGate 系列：Extract 進程的恢複原理

Extract 進程恢複原理

BR

適用於 Extract 進程（僅適用於 Oracle資料庫）

使用 BR 參數可以控制 GoldenGate 的 Bounded Recovery (BR) 功能。Bounded Recovery 功能僅支援 Oracle 資料庫。Bounded Recovery 是通用 Extract 檢查點工具的組件之一，可以保證當Extract 進程出於任何原因（計劃停機或意外停機）停止後，無論在進程停止時的時間點上存在多少個未提交的事務還是這些事務持續的時間多麼久，Extract 進程都能進行高效地恢複。

Bounded Recovery 為 Extract 進程恢複到停止的時間點然後恢複正常處理所花的時間設定了一個時間上限。

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

 

Extract 進程如何恢複未提交的事務

當 Extract 進程在 redo log 中遇到某個事務的起點（在 Oracle 中通常為第一個可執行檔 sql 語句）時，便會將從該事務中捕獲到的所有資料緩衝到記憶體中。即使開始該事務不包含任何資料，

 Extract 進程也必須將事務緩衝到記憶體中，因為該事務中後面的操作可能包含要捕獲的資料。

 

當Extract 進程在 redolog 中遇到事務的 commit 記錄，便會將緩衝在記憶體中的整個事務寫入trail 檔案，並將其從記憶體中清除。當 Extract 進程遇到事務的  rollback 記錄時，便會丟棄緩衝中緩衝的整個事務。在 Extract 進程處理 commit 或 rollback 記錄之前，都會視事務為

Open狀態（未提交或復原的），並持續不斷地收集該事務的資訊。

如果 Extract 在遇到事務的 commit 或 rollback 記錄之前停止，則在 Extract 進程重啟後，必須對所有緩衝在記憶體中的資訊進行恢複。此操作適用於 Extract 進程停止時所有處於 open 狀態的事務。

Extract 按照如下方式執行此恢複過程：

●
如果在 Extract 進程停止時，不存在處於 open 狀態的事務，則恢複操作從當前的

Extract 讀取檢查點開始，這是正常的恢複過程。

如果 redo log 中存在起始點非常接近於 Extract 進程停止時間點的 open事務，則 Extract進程會重新讀入 redolog，從其中最早的 open 事務的起始點開始恢複。此過程需要 Extract 進程對該進程停止前已經寫入 trail 或 discarded 檔案的事務執行額外的工作，這一重複的工作只需要處理相對較少的資料，屬於可接受的成本範圍內。這種恢複也可視為正常恢複。

 

●
如果存在一個或多個 Extract 進程視為長時間啟動並執行 open 事務，

 則 Extract 進程便會通過 BoundedRecovery 進行恢複。

 

Bounded Recovery 的工作原理

如果事務處於 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 操作類似），可以避免上述的額外重複工作。

 

Bounded Recovery 樣本

顯示的時間軸上，隨著時間的推進，一系列的事務開始處理。該圖清晰地示範了長時間啟動並執行事務如何以特定的時間間隔持久化（寫入或存留）到磁碟，然後在發生故障後進行恢複，它可以協助我們理解本例中所使用的相關術語：

 

●持久化對象是指緩衝中已在 Bounded Recovery 檢查點過程中持久化的任何對象。通常情況下，此對象就是事務的狀態或資料，不過緩衝中還應包含一些Extract 進程專用對象。這些對象統稱為持久化對象。

●
最早的非持久化對象是指當前 Bounded Recovery 檢查點之前最近的一個 BR 間隔內，緩衝中最早的 open對象。通常情況下，該對象就是該時間間隔內最早的 open 事務。Bounded Recovery 重新開始時，運行時處理就是從最早的非持久化對象的起始位置開始恢複的，在一般的交易處理中，該位置就是該事務在 redo log 中的起始位置。

 

在本例中，Bounded Recovery 間隔為4小時。如果 open 事務開始的時間點距離當前的 Bounded Recovery 檢查點超過一個 Bounded Recovery 間隔，則該事務就會在當前的 Bounded Recovery 檢查點被持久化。

在 BR 檢查點 n 處:

●
有 5 個處於 open 狀態的事務： T(27), T(45), T(801), T(950), T(1024)。所有其他的事務均已提交或復原。這些事務都從其起始點開始延時間軸不斷運行。

●啟動並執行時間超過一個 Bounded Recovery 間隔的事務有：T(27) 和 T(45)，在BR 檢查點 n 處，這些事務都會被持久化（寫入）磁碟。

●最早的非持久化對象是 T(801)。該事務不符合持久化到磁碟的條件，因為其啟動並執行時間還沒有超過一個 Bounded Recovery 間隔。作為最早的非持久化對象，T(801) 在日誌中的起點位置儲存在BR 檢查點 n的檢查點檔案中。如果 Extract 進程在
BR 檢查點 n 之後意外停止，則該進程將恢複到該日誌位置，然後才能重新開始讀取解析日誌的內容。如果在BR 檢查點 n之前的 BoundedRecovery 間隔中沒有最早的非持久化的對象，則 Extract 進程就會從當前 Bounded Recovery 檢查點的日誌位置重新開始讀取日誌。

 

在 BR 檢查點 n+1 處：

●
T(45) 在前一個BoundedRecovery間隔內已經變髒（發生過更新） ，因此該事務將寫入到一個新的持久化對象檔案中。舊的持久化對象檔案將在 BR 檢查點 n+1完成後刪除。

●
如果 Extract 進程在寫 BR 檢查點 n+1時或在 BR 檢查點 n 和
BR 檢查點 n+1 之間的任意Bounded Recovery 檢查點間隔內失敗，則 Extract 進程將從上一個有效 BR 檢查點 n 開始進行恢複。BR 檢查點 n重新開始的位置就是最早的非持久化事務T(801). 的起點。因此，在最壞情況下，Extract 進程的恢複停止的時間點所需的時間不會超過兩個 Bounded Recovery 間隔，在本例中，恢複的最長時間不會超過 8 小時。

 

在 BR 檢查點n+3000 處：

●
系統已經運行了很長時間了。T(27) 和 T(45) 是僅存的持久化事務。T(801) 和 T(950) 已在 BR Checkpoint n+2999 之前的某個時間點提交並寫入trail檔案。現在僅存的非持久化 open 事務為 T(208412) 和T(208863) 。

●
BR Checkpoint n+3000已寫完。

●
在 BRCheckpoint n+3000 之後的 BR 間隔內，發生了電源故障。

● 新 Extract 進程恢複到BRCheckpoint n+3000。 (27) 和 T(45) 從包含BRCheckpoint n 的狀態的持久化檢查點檔案還原出來。日誌讀取從 T(208412) 的起點開始恢複。

轉載請註明作者出處及原文連結：

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