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

1、extract進(jìn)程：運(yùn)行在數(shù)據(jù)庫(kù)源端，實(shí)時(shí)捕獲源端數(shù)據(jù)庫(kù)表和日志數(shù)據(jù)；

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

3、Replicat進(jìn)程：通常我們也把它叫做應(yīng)用進(jìn)程。運(yùn)行在目標(biāo)端，負(fù)責(zé)讀取目標(biāo)端trail文件中的內(nèi)容，并將其解析為DML、DDL語句或消息記錄，然后應(yīng)用或投遞到目標(biāo)系統(tǒng)。

我們看看老司機(jī)的環(huán)境架構(gòu)：源端Extract進(jìn)程實(shí)時(shí)抽取增量數(shù)據(jù)并由Pump進(jìn)程投遞到oggfor bigdata（Adapter）的Replicat進(jìn)程解析并將增量數(shù)據(jù)實(shí)時(shí)投遞到kafka。架構(gòu)圖如下：

接下來分享下如上架構(gòu)遇到的一些問題。

問題一、Ogg19+Oracle DB 19.6 Extract Hangs

近期將一套11g的數(shù)據(jù)庫(kù)遷移到了19c上，同時(shí)老環(huán)境中的ogg相關(guān)進(jìn)程也對(duì)應(yīng)遷移到了19c上面。在新環(huán)境里Extract進(jìn)程會(huì)不定時(shí)的hang，lag經(jīng)常超過1個(gè)小時(shí)，這對(duì)于此類進(jìn)程對(duì)應(yīng)的下游實(shí)時(shí)應(yīng)用是災(zāi)難性的。

老司機(jī)怎么會(huì)容忍lag超過1個(gè)小時(shí)呢，說出來也是淚，因?yàn)槔纤緳C(jī)也不知道發(fā)生了什么。1個(gè)小時(shí)都過去了，老司機(jī)都不知道發(fā)生了什么，那老司機(jī)干嘛去了。莫慌，捋一捋，老司機(jī)查看了report、errorlog、HCrpt、長(zhǎng)事務(wù)、數(shù)據(jù)庫(kù)event等信息，并且多次重啟了hang狀態(tài)進(jìn)程。從日志中看到的都是有關(guān)長(zhǎng)事務(wù)的warning，但數(shù)據(jù)庫(kù)中沒有查詢到長(zhǎng)事務(wù)。

經(jīng)過日志分析，老司機(jī)決定加上SKIPEMPTYTRANS參數(shù)并調(diào)整了內(nèi)存限制max_sga_size至4096。進(jìn)程的原始參數(shù)配置如下：

參數(shù)調(diào)整后，趕緊重啟進(jìn)程，很不幸問題依舊。于是也就有了后來的一次又一次延遲超過1小時(shí)和老司機(jī)被應(yīng)用圍著一圈又一圈的場(chǎng)景。

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

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

問題二、 ogg到kafka“l(fā)ag”優(yōu)化

在這里老司機(jī)說的“l(fā)ag”并非在ogg中執(zhí)行infoall看到的lag，實(shí)際上在老司機(jī)的環(huán)境中，執(zhí)行infoall得到的lag結(jié)果為0。請(qǐng)大家耐心往下看。

我們來看下一條kafkatopic中的數(shù)據(jù)示例：

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

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

在源端extract進(jìn)程中加入了如下參數(shù)：

FLUSHCSECS 1     ?刷新extract內(nèi)存緩沖區(qū)時(shí)間間隔

EOFDELAYCSECS 1  ?控制讀到trail末尾檢查新數(shù)據(jù)的頻率

在目標(biāo)端replicat進(jìn)程中調(diào)整了如下參數(shù)：

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

MAXTRANSOPS 1    ?將大型源事務(wù)拆分為目標(biāo)系統(tǒng)上的較小事務(wù)

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