關系型數據庫在日常運行中，不可避免會用到事務，而RDBMS與NoSQL的一個主要區別就是事務支持粒度;同時，事務也是保證數據一致性的主要手段。在使用GoldenGate進行數據同步時，對事務的管理，特別是長事務的管理，是日常運維工作中的一項重點。

長事務的產生有多種可能，比如一個SQL語句處理的數據量過大，如果系統資源不足，作業執行可能長達數小時以上;又或者在一個事務中，多次循環、分批次執行多個SQL語句，而只在事務的最后才提交

又或者用戶在其終端上通過數據庫客戶端修改了數據，但是一直未提交，也未回退，且該客戶的電腦一直未關機，這種事務持續時間可達數天或數月。雖然某些事務對生產系統影響不大，但GoldenGate為了保證數據同步中的完整性，對事務所在的日志文件有一定要求。

長事務如果一直未提交，在使用GoldenGate初始化或數據泵導出存量數據時，該事務修改的數據將無法導出到目標庫;而啟動增量捕獲時，GoldenGate只會從進程添加(或register)那一刻開始解析日志，當前未提交的事務不會被捕獲。另外，在日常同步中，長事務會占用更多的內存資源，且對日志的保留時間也有更高要求。

所以，在采用GoldenGate進行數據同步的環境中，有必要對長事務進行監控及管理;如果對業務系統中執行的SQL非常了解，且都是短平快的事務，則可以不用特別考慮長事務的影響。

BR原理

在了解GoldenGate如何管理長事務之前，我們先了解GoldenGate在抽取增量時的一個功能特性：

基于邊界的恢復(BoundedRecovery，簡稱BR)。

為了更快的恢復GoldenGate的抽取過程，GoldenGate在重新啟動后，默認不會從未提交事務的開始時間點讀取日志(視事務的運行時長而定)，而會根據本地暫存的數據和最后一次保存點(BR)開始讀取。

基于BR的恢復，是常規Extract(抽取進程)檢查點機制的一部分。

它可以確保Extract在任何原因(計劃的或計劃外的)停止之后，無論Extract停止時有多少未提交事務，以及它們有多“舊”，抽取進程都可以有效地恢復這些事務。

我們來看一個示例圖：

BR在9點開始，默認每4小時執行Checkpoint(13點、17點…)，但抽取進程在16:50停止，所以17點的BRcheckpoint實際并沒有發生;

基于BR的處理邏輯，第一次13點checkpoint時，由于T3,T4未執行超過4小時，所以不會被checkpoint寫入磁盤;而T1、T5由于事務已經超過4小時，所以緩存在內存中的事務數據及狀態會寫入磁盤;

在16:50停止抽取進程exa時，各事務的處理邏輯如下：

T1，T3在15:00已經提交，不會受到影響;

因為T2執行時間未超過4小時，所以緩存在內存中的數據會被丟棄，不會保存到磁盤，所以exa重啟后，T2的日志讀取點仍然是事務開始時間13:15;

基于相同的原因，T4緩存在內存中的數據也會被丟棄，由于一直未得到checkpoint機會，所以抽取進程會從事務的開始時間(9:10)開始解析日志;

最后，T5因為在13:00做過一次checkpoint，所以抽取進程下次啟動時，不會再從頭解析此事務的日志，而是讀取磁盤上的BR數據后，從13點開始解析該事務的日志。

從上圖可以看出，使用了BR技術之后，數據庫理論上只需要保留最近8小時的日志(圖中T4事務);但如果BR恢復失敗(如參數文件有修改或其它原因無法使用BR恢復)，則GoldenGate會使用普通的恢復模式，此時，需要從最早未提交事務的開始時間點重新解析日志，一般情況下，可能需要不止8小時的日志;

GoldenGate在21:00重啟后，會先基于BR保存的checkpoint數據進行恢復，再結合日志進行抽取，其間已提交的事務因為已處理而直接跳過，不用再做處理，從而提升GoldenGate抽取進程的效率;

官方手冊上，不建議修改BRcheckpoint的間隔時間，因為超過4小時的事務一般都是長事務。

在GoldenGate中查看BR恢復點

在了解了BR的原理之后，我們來看一下在GoldenGate中如何查看一個具體的BR恢復點。

通過如下命令，可查看GoldenGate抽取進程對應的BR檢查點。

長事務檢測

通過對BR原理的了解和查看，我們現在來看在GoldenGate中如何檢測和監測長事務，一般有兩種方式。

方法一、在GGSCI命令行中查看

查看20分鐘以上的長事務，但未找到符合條件的事務。

需要指出的是，即使有長事務，也不意味著GoldenGate有很大的延遲，如果GoldenGate有足夠的資源緩存long-trans，抽取進程仍然會讀取和解析當前的redo log，所以實際的lag會很小。

方法二、配置GoldenGate抽取參數

通過在抽取進程中配置監控參數，當有符合條件的長事務時，則會在日志文件中輸出告警日志。

當有符合條件的長事務時，會在日志文件中生成相應的告警信息：

長事務的處理

針對前面的BR原理和長事務的監測，為了確保GoldenGate的同步不會因為事務超長而造成歸檔日志積壓太多，可以通過以下方式解決。

在GoldenGate中跳過長事務

如果確認抽取的表不在長事務中，則可以在GoldenGate命令行手工跳過。

針對上面GoldenGate查到的長事務，可執行以下命令跳過。

再次查看，在GoldenGate中已經看不到剛才的事務。

需要注意的是，上述語句只是在GoldenGate中跳過了對該事務的解析，而對該事務的執行沒有任何改變，即該事務在數據庫上所占用的資源不會產生任何影響。

數據庫中處理長事務

基于GoldenGate showtrans的結果：

可根據上述返回的XID值，在源庫中查詢事務對應的信息，包括機器名、IP、執行SQL語句、SID等，以幫助DBA進一步判斷分析，或通過kill語句殺掉不需要的事務。

也可以根據返回的sid/serial#，在數據庫上kill掉對應的事務：

格式如下：

不過在執行kill命令之前，一定要確保了解這個操作的影響，特別是在生產環境，需要慎之又慎。