GoldenGate 之 Bounded Recovery說明

時間 2019-11-06

標籤 goldengate bounded recovery 說明简体版

原文原文鏈接

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

l oracle在線日誌包含已提交的和未提交的事務，但OGG只會將已提交的事務寫入到隊列文件。所以，針對未提交的事務，特別是未提交的長事務，OGG會怎樣處理呢？shell

l 有些長事務是在批處理做業中，須要幾個小時才能執行完成，好比晚上跑批的做業。OGG在解析過程當中，會從這些事務一執行就開始讀取在線日誌，但這些事務可能會持續好久，在期間，在線日誌可能會切換到歸檔日誌，同時這期間也會有其它事務在執行和提交，若是長事務一直未提交，歸檔日誌又由於按期的rman備份而刪除，OGG將如何處理？oracle

針對以上狀況，OGG有2種處理方式，第一種就是使用正常恢復歸檔的方式，即恢復OGG須要的全部歸檔日誌，多是從長事務開始的那個歸檔開始，這樣OGG將從事務開始的檢查點開始解析；第二種方式就是使用Bounded Recovery的方式，下面的內容將討論這種方式。app

簡單來講，BR（Bounded Recovery ）默認的設置是4小時，即每4小時OGG抽取進程會作一個檢查點，在每一個檢查點的時間點上，OGG會檢查長事務，並將超過4小時的長事務的狀態寫入到磁盤（若是沒有達到4小時，則此事務不會被BR寫入），默認保存在OGG安裝目錄的BR目錄下。在每一個BR的間隔點，這個操做會一直持續，直到事務提交，或事務回滾。性能

下面的示例中，咱們設置BRINTERVAL爲20分鐘：測試

BR BRINTERVAL 20Mrest

下面是針對BR的官方文檔描述：日誌

使用磁盤持久保存數據，用於恢復長事務，讓抽取進程能夠確保捕獲性能（雖然只有在極端狀況下才會發生捕獲延遲）。若是抽取進程中止時，有些事務的開始時間遠在這個時間點以前，那麼系統須要佔用大量的日誌空間，也有可能這些日誌文件不在磁盤上或已被刪除。並且，從新從一個很早的日誌文件開始讀取事務，這種作法是不可接受的，由於這些日誌文件中的其它事務已經被解析並被寫入到隊列文件。htm

若是經過持久化數據能恢復這些長事務的狀態，那麼就能夠消除這個往返讀取的動做。極端的狀況下，若是有多個長事務，若是每一個事務都要求從起點從新讀取，那麼OGG的捕獲性能將大大下降。blog

在本示例中，咱們將BR的間隔設置爲20分鐘，而後執行一個insert語句，但不提交。此時，抽取進程會從在線日誌的某個點開始讀取，在線日誌的序號爲：#14878。

而後咱們切換幾組日誌，備份並刪除序號爲14878的日誌文件。咱們能夠看到每隔20分鐘，BR checkpoint就會執行，此時，長事務的狀態信息及數據就會被寫入到磁盤上。即便磁盤上沒有對應的歸檔日誌文件，抽取進程也不會再去讀取這些日誌，而是直接從磁盤上保存的BR數據中進行恢復，若是事務提交，則OGG會直接將BR目錄下的數據寫入到隊列中。

測試步驟以下：

執行下面的INSERT語句，但不提交，用於測試長事務的場景：

SQL> insert into myobjects

select object_id,object_name,object_type from dba_objects;

75372 rows created.

經過infor ext1檢查當前讀取的在線日誌序號，本測試中是14878

GGSCI 2> info ext1

EXTRACT EXT1 Last Started 2014-06-21 18:07 Status RUNNING

Checkpoint Lag 00:00:00 (updated 00:00:08 ago)

Process ID 15190

Log Read Checkpoint Oracle Redo Logs

2014-06-21 18:10:21 Seqno 14878, RBA 5936128

SCN 0.9137531 (9137531)

使用SEND EXTRACT SHOWTRANS查看是否有事務是打開狀態：

GGSCI 4> send ext1 showtrans

Sending SHOWTRANS request to EXTRACT EXT1 …

Oldest redo log file necessary to restart Extract is:

Redo Log Sequence Number 14878, RBA 116752

————————————————————

XID: 10.16.1533

Items: 75372

Extract: EXT1

Redo Thread: 1

Start Time: 2014-06-21:18:10:14

SCN: 0.9137521 (9137521)

Redo Seq: 14878

Redo RBA: 116752

Status: Running

INFO EXTRACT SHOWCH會顯示抽取進程檢查點的更多信息，包括當前事務（日誌）中的讀取點，寫入隊列文件的位置等。下面的示例中，第一個檢查點是抽取進程啓動時的讀取點：14861，接着是最先未提交事務的讀取點：序號14878，SCN：9137521，最後是抽取進程當前的日誌讀取檢查點，序號仍然是14878，但SCN是9137612，說明在這個未提交的事務以後，DB已經有一些其它操做。

GGSCI 5> info ext1 showch

EXTRACT EXT1 Last Started 2014-06-21 18:07 Status RUNNING

Checkpoint Lag 00:00:00 (updated 00:00:06 ago)

Process ID 15190

Log Read Checkpoint Oracle Redo Logs

2014-06-21 18:11:41 Seqno 14878, RBA 5977088

SCN 0.9137612 (9137612)

Current Checkpoint Detail:

Read Checkpoint #1

Oracle Redo Log

Startup Checkpoint (starting position in the data source):

Thread #: 1

Sequence #: 14861

RBA: 5918224

Timestamp: 2014-06-21 16:49:33.000000

SCN: 0.9129707 (9129707)

Redo File: /u01/app/oracle/fast_recovery_area/GGATE1/archivelog/2014_06_21/o1_mf_1_14861_9tbo7pys_.arc

Recovery Checkpoint (position of oldest unprocessed transaction in the data source):

Thread #: 1

Sequence #: 14878

RBA: 116752

Timestamp: 2014-06-21 18:10:14.000000

SCN: 0.9137521 (9137521)

Redo File: /u01/app/oracle/oradata/ggate1/redo03.log

Current Checkpoint (position of last record read in the data source):

Thread #: 1

Sequence #: 14878

RBA: 5977088

Timestamp: 2014-06-21 18:11:41.000000

SCN: 0.9137612 (9137612)

Redo File: /u01/app/oracle/oradata/ggate1/redo03.log

Write Checkpoint #1

GGS Log Trail

Current Checkpoint (current write position):

Sequence #: 3

RBA: 8130790

Timestamp: 2014-06-21 18:11:44.414364

Extract Trail: ./dirdat/zz

Trail Type: RMTTRAIL

大約20分鐘以後，咱們繼續使用showch，看看與前面的命令相比，輸出有哪些差別：

能夠看到，當前讀取的在線日誌序號已經變爲14884（之前是14878）。

但恢復檢查點仍然沒有變化，與上一個命令執行結果相同。

GGSCI 2> info ext1 showch

EXTRACT EXT1 Last Started 2014-06-21 18:07 Status RUNNING

Checkpoint Lag 00:00:00 (updated 00:00:04 ago)

Process ID 15190

Log Read Checkpoint Oracle Redo Logs

2014-06-21 18:40:34 Seqno 14884, RBA 72704

SCN 0.9139491 (9139491)

Current Checkpoint Detail:

Read Checkpoint #1

Oracle Redo Log

Startup Checkpoint (starting position in the data source):

Thread #: 1

Sequence #: 14861

RBA: 5918224

Timestamp: 2014-06-21 16:49:33.000000

SCN: 0.9129707 (9129707)

Redo File: /u01/app/oracle/fast_recovery_area/GGATE1/archivelog/2014_06_21/o1_mf_1_14861_9tbo7pys_.arc

Recovery Checkpoint (position of oldest unprocessed transaction in the data source):

Thread #: 1

Sequence #: 14878

RBA: 116752

Timestamp: 2014-06-21 18:10:14.000000

SCN: 0.9137521 (9137521)

Redo File: /u01/app/oracle/oradata/ggate1/redo03.log

Current Checkpoint (position of last record read in the data source):

Thread #: 1

Sequence #: 14884

RBA: 72704

Timestamp: 2014-06-21 18:40:34.000000

SCN: 0.9139491 (9139491)

Redo File: /u01/app/oracle/oradata/ggate1/redo03.log

經過上面的命令，咱們看到了BR檢查點的相關信息，前面咱們把BR間隔從默認4小時改成20分鐘，所以，每隔20分鐘（本示例中是：18:07，18:27，18:47...），長事務當前的狀態信息會被抽取進程寫入到磁盤上的BR目錄。

所以，咱們看到在18:27的BR間隔時間點，BR將在線日誌14881的信息持久到磁盤上，若是這個時候extract有錯誤或重啓，extract再也不須要從早於14881序號的redo或歸檔裏讀取數據。

BR Previous Recovery Checkpoint:

Thread #: 0

Sequence #: 0

RBA: 0

Timestamp: 2014-06-21 18:07:35.982719

SCN: Not available

Redo File:

BR Begin Recovery Checkpoint:

Thread #: 0

Sequence #: 14878

RBA: 116752

Timestamp: 2014-06-21 18:10:14.000000

SCN: 0.9137521 (9137521)

Redo File:

BR End Recovery Checkpoint:

Thread #: 1

Sequence #: 14881

RBA: 139776

Timestamp: 2014-06-21 18:27:38.000000

SCN: 0.9138688 (9138688)

Redo File:

在BR目錄中咱們能夠看到抽取進程ext1生成的一些文件：

GGSCI 4> info ext1

EXTRACT EXT1 Last Started 2014-06-21 18:07 Status RUNNING

Checkpoint Lag 00:00:00 (updated 00:00:06 ago)

Process ID 15190

Log Read Checkpoint Oracle Redo Logs

2014-06-21 18:41:35 Seqno 14884, RBA 131072

SCN 0.9139583 (9139583)

GGSCI 3> shell ls -l ./BR/EXT1

total 20

-rw-r—– 1 oracle oinstall 65536 Jun 21 18:27 CP.EXT1.000000015

drwxr-x— 2 oracle oinstall 4096 Jun 19 17:07 stale

此時，若是咱們刪除14878的歸檔日誌會怎樣呢？由於BR檢查點已經將包含長事務的日誌序號爲14878的信息寫入到磁盤，extract進程將再也不須要這些舊的歸檔文件。爲了測試這個功能，咱們將14878歸檔備份以後刪除，記住，這個序號是長事務開始時的序號，在抽取進程檢查點日誌中有記錄。

RMAN> backup archivelog sequence 14878 delete input;

Starting backup at 21-JUN-14

using target database control file instead of recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=24 device type=DISK

channel ORA_DISK_1: starting archived log backup set

channel ORA_DISK_1: specifying archived log(s) in backup set

input archived log thread=1 sequence=14878 RECID=30497 STAMP=850846396

channel ORA_DISK_1: starting piece 1 at 21-JUN-14

channel ORA_DISK_1: finished piece 1 at 21-JUN-14

piece handle=/u01/app/oracle/fast_recovery_area/GGATE1/backupset/2014_06_21/o1_mf_annnn_TAG20140621T234659_9tcb7msp_.bkp tag=TAG20140621T234659 comment=NONE

channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01

channel ORA_DISK_1: deleting archived log(s)

archived log file name=/u01/app/oracle/fast_recovery_area/GGATE1/archivelog/2014_06_21/o1_mf_1_14878_9tbpowlm_.arc RECID=30497 STAMP=850846396

Finished backup at 21-JUN-14

好，咱們如今來提交這個交易。

SQL> insert into myobjects

2 select object_id,object_name,object_type from dba_objects;

75372 rows created.

SQL> commit;

Commit complete.

在抽取進程ext1的日誌報告中，能夠看到有長事務的信息、BR檢查點的信息，並且每隔20分鐘，BR檢查點寫入的redo日誌序號是在增加的，即OGG抽取進程每20分鐘會將當前日誌序號寫入，同時在OGG日誌報告中體現出來。

2014-06-21 18:17:42 WARNING OGG-01027 Long Running Transaction: XID 10.16.1533, Items 75372, Extract EXT1, Redo Thread 1, SCN 0.9137521 (9137521), Redo Seq #14878, R

edo RBA 116752.

2014-06-21 18:27:41 INFO OGG-01971 The previous message, ‘WARNING OGG-01027′, repeated 1 times.

2014-06-21 18:27:41 INFO OGG-01738 BOUNDED RECOVERY: CHECKPOINT: for object pool 1: p23540_extr: start=SeqNo: 14878, RBA: 116752, SCN: 0.9137521 (9137521), Timest

amp: 2014-06-21 18:10:14.000000, end=SeqNo: 14881, RBA: 139776, SCN: 0.9138688 (9138688), Timestamp: 2014-06-21 18:27:38.000000, Thread: 1.

2014-06-21 18:47:50 INFO OGG-01738 BOUNDED RECOVERY: CHECKPOINT: for object pool 1: p23540_extr: start=SeqNo: 14885, RBA: 144912, SCN: 0.9139983 (9139983), Timest

amp: 2014-06-21 18:47:47.000000, Thread: 1, end=SeqNo: 14885, RBA: 145408, SCN: 0.9139983 (9139983), Timestamp: 2014-06-21 18:47:47.000000, Thread: 1.

2014-06-21 19:07:59 INFO OGG-01738 BOUNDED RECOVERY: CHECKPOINT: for object pool 1: p23540_extr: start=SeqNo: 14889, RBA: 176144, SCN: 0.9141399 (9141399), Timest

amp: 2014-06-21 19:07:56.000000, Thread: 1, end=SeqNo: 14889, RBA: 176640, SCN: 0.9141399 (9141399), Timestamp: 2014-06-21 19:07:56.000000, Thread: 1.

最後，記住一點：若是使用BR默認的4小時，則當前磁盤上至少要保存過去8小時的歸檔日誌，以便知足任何長事務的要求，固然，在實際生產環境中，每每要求保存的時間會更長。下面的圖示中