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

“專業(yè)、務(wù)實(shí)、高效、創(chuàng)新、把客戶的事當(dāng)成自己的事”是我們每一個(gè)人一直以來堅(jiān)持追求的企業(yè)文化。 創(chuàng)新互聯(lián)建站是您可以信賴的網(wǎng)站建設(shè)服務(wù)商、專業(yè)的互聯(lián)網(wǎng)服務(wù)提供商! 專注于成都網(wǎng)站制作、成都網(wǎng)站建設(shè)、軟件開發(fā)、設(shè)計(jì)服務(wù)業(yè)務(wù)。我們始終堅(jiān)持以客戶需求為導(dǎo)向，結(jié)合用戶體驗(yàn)與視覺傳達(dá)，提供有針對(duì)性的項(xiàng)目解決方案，提供專業(yè)性的建議，創(chuàng)新互聯(lián)建站將不斷地超越自我，追逐市場(chǎng)，引領(lǐng)市場(chǎng)！

l oracle在線日志包含已提交的和未提交的事務(wù)，但OGG只會(huì)將已提交的事務(wù)寫入到隊(duì)列文件。因此，針對(duì)未提交的事務(wù)，特別是未提交的長(zhǎng)事務(wù)，OGG會(huì)怎樣處理呢？

l 有些長(zhǎng)事務(wù)是在批處理作業(yè)中，需要幾個(gè)小時(shí)才能執(zhí)行完成，比如晚上跑批的作業(yè)。OGG在解析過程中，會(huì)從這些事務(wù)一執(zhí)行就開始讀取在線日志，但這些事務(wù)可能會(huì)持續(xù)很久，在期間，在線日志可能會(huì)切換到歸檔日志，同時(shí)這期間也會(huì)有其它事務(wù)在執(zhí)行和提交，如果長(zhǎng)事務(wù)一直未提交，歸檔日志又因?yàn)槎ㄆ诘膔man備份而刪除，OGG將如何處理？

針對(duì)以上情況，OGG有2種處理方式，第一種就是使用正?；謴?fù)歸檔的方式，即恢復(fù)OGG需要的所有歸檔日志，可能是從長(zhǎng)事務(wù)開始的那個(gè)歸檔開始，這樣OGG將從事務(wù)開始的檢查點(diǎn)開始解析；第二種方式就是使用Bounded Recovery的方式，下面的內(nèi)容將討論這種方式。

簡(jiǎn)單來說，BR（Bounded Recovery ）默認(rèn)的設(shè)置是4小時(shí)，即每4小時(shí)OGG抽取進(jìn)程會(huì)做一個(gè)檢查點(diǎn)，在每個(gè)檢查點(diǎn)的時(shí)間點(diǎn)上，OGG會(huì)檢查長(zhǎng)事務(wù)，并將超過4小時(shí)的長(zhǎng)事務(wù)的狀態(tài)寫入到磁盤（如果沒有達(dá)到4小時(shí)，則此事務(wù)不會(huì)被BR寫入），默認(rèn)保存在OGG安裝目錄的BR目錄下。在每個(gè)BR的間隔點(diǎn)，這個(gè)操作會(huì)一直持續(xù)，直到事務(wù)提交，或事務(wù)回滾。

下面的示例中，我們?cè)O(shè)置BRINTERVAL為20分鐘：

BR BRINTERVAL 20M

下面是針對(duì)BR的官方文檔描述：

使用磁盤持久保存數(shù)據(jù)，用于恢復(fù)長(zhǎng)事務(wù)，讓抽取進(jìn)程可以確保捕獲性能（雖然只有在極端情況下才會(huì)發(fā)生捕獲延遲）。如果抽取進(jìn)程停止時(shí)，有些事務(wù)的開始時(shí)間遠(yuǎn)在這個(gè)時(shí)間點(diǎn)之前，那么系統(tǒng)需要占用大量的日志空間，也有可能這些日志文件不在磁盤上或已被刪除。而且，重新從一個(gè)很早的日志文件開始讀取事務(wù)，這種做法是不可接受的，因?yàn)檫@些日志文件中的其它事務(wù)已經(jīng)被解析并被寫入到隊(duì)列文件。

如果通過持久化數(shù)據(jù)能恢復(fù)這些長(zhǎng)事務(wù)的狀態(tài)，那么就可以消除這個(gè)往返讀取的動(dòng)作。極端的情況下，如果有多個(gè)長(zhǎng)事務(wù)，如果每個(gè)事務(wù)都要求從起點(diǎn)重新讀取，那么OGG的捕獲性能將大大降低。

在本示例中，我們將BR的間隔設(shè)置為20分鐘，然后執(zhí)行一個(gè)insert語(yǔ)句，但不提交。此時(shí)，抽取進(jìn)程會(huì)從在線日志的某個(gè)點(diǎn)開始讀取，在線日志的序號(hào)為：#14878。

然后我們切換幾組日志，備份并刪除序號(hào)為14878的日志文件。我們可以看到每隔20分鐘，BR checkpoint就會(huì)執(zhí)行，此時(shí)，長(zhǎng)事務(wù)的狀態(tài)信息及數(shù)據(jù)就會(huì)被寫入到磁盤上。即使磁盤上沒有對(duì)應(yīng)的歸檔日志文件，抽取進(jìn)程也不會(huì)再去讀取這些日志，而是直接從磁盤上保存的BR數(shù)據(jù)中進(jìn)行恢復(fù)，如果事務(wù)提交，則OGG會(huì)直接將BR目錄下的數(shù)據(jù)寫入到隊(duì)列中。

測(cè)試步驟如下：

執(zhí)行下面的INSERT語(yǔ)句，但不提交，用于測(cè)試長(zhǎng)事務(wù)的場(chǎng)景：

SQL> insert into myobjects

select object_id,object_name,object_type from dba_objects;

75372 rows created.

通過infor ext1檢查當(dāng)前讀取的在線日志序號(hào)，本測(cè)試中是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查看是否有事務(wù)是打開狀態(tài)：

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會(huì)顯示抽取進(jìn)程檢查點(diǎn)的更多信息，包括當(dāng)前事務(wù)（日志）中的讀取點(diǎn)，寫入隊(duì)列文件的位置等。下面的示例中，第一個(gè)檢查點(diǎn)是抽取進(jìn)程啟動(dòng)時(shí)的讀取點(diǎn)：14861，接著是最早未提交事務(wù)的讀取點(diǎn)：序號(hào)14878，SCN：9137521，最后是抽取進(jìn)程當(dāng)前的日志讀取檢查點(diǎn)，序號(hào)仍然是14878，但SCN是9137612，說明在這個(gè)未提交的事務(wù)之后，DB已經(jīng)有一些其它操作。

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分鐘之后，我們繼續(xù)使用showch，看看與前面的命令相比，輸出有哪些差異：

可以看到，當(dāng)前讀取的在線日志序號(hào)已經(jīng)變?yōu)?4884（以前是14878）。

但恢復(fù)檢查點(diǎn)仍然沒有變化，與上一個(gè)命令執(zhí)行結(jié)果相同。

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檢查點(diǎn)的相關(guān)信息，前面我們把BR間隔從默認(rèn)4小時(shí)改為20分鐘，因此，每隔20分鐘（本示例中是：18:07，18:27，18:47...），長(zhǎng)事務(wù)當(dāng)前的狀態(tài)信息會(huì)被抽取進(jìn)程寫入到磁盤上的BR目錄。

因此，我們看到在18:27的BR間隔時(shí)間點(diǎn)，BR將在線日志14881的信息持久到磁盤上，如果這個(gè)時(shí)候extract有錯(cuò)誤或重啟，extract不再需要從早于14881序號(hào)的redo或歸檔里讀取數(shù)據(jù)。

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目錄中我們可以看到抽取進(jìn)程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

此時(shí)，如果我們刪除14878的歸檔日志會(huì)怎樣呢？因?yàn)锽R檢查點(diǎn)已經(jīng)將包含長(zhǎng)事務(wù)的日志序號(hào)為14878的信息寫入到磁盤，extract進(jìn)程將不再需要這些舊的歸檔文件。為了測(cè)試這個(gè)功能，我們將14878歸檔備份之后刪除，記住，這個(gè)序號(hào)是長(zhǎng)事務(wù)開始時(shí)的序號(hào)，在抽取進(jìn)程檢查點(diǎn)日志中有記錄。

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

好，我們現(xiàn)在來提交這個(gè)交易。

SQL> insert into myobjects

2 select object_id,object_name,object_type from dba_objects;

75372 rows created.

SQL> commit;

Commit complete.

在抽取進(jìn)程ext1的日志報(bào)告中，可以看到有長(zhǎng)事務(wù)的信息、BR檢查點(diǎn)的信息，而且每隔20分鐘，BR檢查點(diǎn)寫入的redo日志序號(hào)是在增長(zhǎng)的，即OGG抽取進(jìn)程每20分鐘會(huì)將當(dāng)前日志序號(hào)寫入，同時(shí)在OGG日志報(bào)告中體現(xiàn)出來。

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.

最后，記住一點(diǎn)：如果使用BR默認(rèn)的4小時(shí)，則當(dāng)前磁盤上至少要保存過去8小時(shí)的歸檔日志，以便滿足任何長(zhǎng)事務(wù)的要求，當(dāng)然，在實(shí)際生產(chǎn)環(huán)境中，往往要求保存的時(shí)間會(huì)更長(zhǎng)。下面的圖示中

T27, T45開始于BR N-1之前，會(huì)在BR N這個(gè)檢查點(diǎn)上記錄狀態(tài)；而T801是在BR N-1之后開始，在BR N檢查點(diǎn)時(shí)，由于不滿足BR interval的時(shí)間要求，因此不會(huì)被記錄到BR N這個(gè)檢查點(diǎn)上，而是會(huì)記錄在BR N+1這個(gè)檢查點(diǎn)上。

    一旦在BR N和BR N+1這個(gè)時(shí)間范圍內(nèi)，extract當(dāng)?shù)?，則T801的所有信息丟失，重啟extract之后，將會(huì)從T801開始的時(shí)間點(diǎn)解析日志。