GoldenGate（以下簡稱ogg）簡單易用，老司機的環境中在很多場景下使用了ogg。“俗話說常在河邊走，哪有不濕鞋”，ogg用的多了自然也會遇到一些問題，以下老司機分享兩個ogg問題。尤其是問題一，希望大家不要再踩坑。簡單的復習下，ogg主要有三類進程：

1、extract進程：運行在數據庫源端，實時捕獲源端數據庫表和日志數據；

2、pump進程：其作用是把源端本地trail文件以數據塊的形式通過TCP/IP協議發送到目標端（推薦的方式）。pump進程本質是extract進程的一種特殊形式，如果不使用trails文件，extract進程可以在抽取完數據以后，直接投遞到目標端；

3、Replicat進程：通常我們也把它叫做應用進程。運行在目標端，負責讀取目標端trail文件中的內容，并將其解析為DML、DDL語句或消息記錄，然后應用或投遞到目標系統。

我們看看老司機的環境架構：源端Extract進程實時抽取增量數據并由Pump進程投遞到oggfor bigdata（Adapter）的Replicat進程解析并將增量數據實時投遞到kafka。架構圖如下：

接下來分享下如上架構遇到的一些問題。

問題一、Ogg19+Oracle DB 19.6 Extract Hangs

近期將一套11g的數據庫遷移到了19c上，同時老環境中的ogg相關進程也對應遷移到了19c上面。在新環境里Extract進程會不定時的hang，lag經常超過1個小時，這對于此類進程對應的下游實時應用是災難性的。

老司機怎么會容忍lag超過1個小時呢，說出來也是淚，因為老司機也不知道發生了什么。1個小時都過去了，老司機都不知道發生了什么，那老司機干嘛去了。莫慌，捋一捋，老司機查看了report、errorlog、HCrpt、長事務、數據庫event等信息，并且多次重啟了hang狀態進程。從日志中看到的都是有關長事務的warning，但數據庫中沒有查詢到長事務。

經過日志分析，老司機決定加上SKIPEMPTYTRANS參數并調整了內存限制max_sga_size至4096。進程的原始參數配置如下：

參數調整后，趕緊重啟進程，很不幸問題依舊。于是也就有了后來的一次又一次延遲超過1小時和老司機被應用圍著一圈又一圈的場景。

相應日志沒有提供其它可用信息，參數配置也已經是較優的狀態。老司機嚴重懷疑這是ogg的bug導致，于是向官方求助，同時老司機也在mos上找到了類似問題的文檔IntegratedExtract Hangs After Upgrade To Ogg 19/oracle Db 19.5 (Doc ID2649420.1)。

到此大家應該認為這個問題解決了，后來的過程咱不說了，就告訴大家這個問題經歷了一個月時間才得到官方的有效回復，官方實際給出了另一個bug，且是內部bug，無mos文檔可查。官方也給出了workground，將TRANLOGOPTIONSINTEGRATEDPARAMS (max_sga_size 2048,parallelism4)中的parallelism調整為1。Workground應用后經過幾個星期的驗證，問題已得到有效解決。

問題二、 ogg到kafka“lag”優化

在這里老司機說的“lag”并非在ogg中執行infoall看到的lag，實際上在老司機的環境中，執行infoall得到的lag結果為0。請大家耐心往下看。

我們來看下一條kafkatopic中的數據示例：

說明：oggforbigdata解析投遞到Kafka中的消息字段以“|”分隔，第一個字段為操作類型，示例數據操作類型為“I”，即insert操作；第二個字段為表屬主及表名；第三個字段為該條記錄在源端數據庫中的提交時間；第四個字段為kafka接收該條記錄的時間；后續字段分別為ogg標識位和表字段對應信息。

我們可以很明顯的看到第三個字段和第四個字段的時間差超過3秒，實際生產表記錄顯示的時間差甚至超過10s。這意味著一條記錄在數據庫中提交，然后被ogg捕捉并投遞到kafka所需時間要幾秒甚至10幾秒，這怎么可能？老司機又執行了一次infoall看了看lag，結果仍然為0。至此大家應該知道老司機說的是啥“lag”了。于是老司機輪起了三板斧分別對extract和replicat進程進行了優化，以提高復制的效率。

在源端extract進程中加入了如下參數：

FLUSHCSECS 1     ?刷新extract內存緩沖區時間間隔

EOFDELAYCSECS 1  ?控制讀到trail末尾檢查新數據的頻率

在目標端replicat進程中調整了如下參數：

GROUPTRANSOPS 1  ?控制在需要提交之前可以分組到事務中的最大批處理操作數

MAXTRANSOPS 1    ?將大型源事務拆分為目標系統上的較小事務

以上參數調整后，“lag”明顯縮短。但也有部分進程的lag（infoall查看的結果）不斷增加，老司機判斷是進程中涉及表變更量太大，replicat進程調整的參數反而降低了進程效率，將參數GROUPTRANSOPS值調整為10000，進程lag終于消除了。對于這部分進程雖然做了反操作，“lag”值也沒能縮短，但最終不會被應用圍著了，“lag”和lag相比，老司機更歡“lag”。老司機的目標是將“lag”縮短至3秒以內。好消息是上述參數加入后“lag”明顯縮短，壞消息是“lag”仍然大于3秒。由于官方回復這是正常現象，至此老司機也不再折騰。