OGG數據同步異常問題總結
大家應該還記得上次本大濕分享過一遍文章《OceanBase數據同步挖掘日志慢解決方案》該方案引入OracleGoldenGate(以下簡稱OGG)進行數據同步。完美地解決了因OB挖掘日志慢影響整個項目割接進度問題。本以為該事件可以告一段落了，誰知在后面的一次OGG數據初始化過程中問題頻頻爆發。本大濕也是一路披荊斬棘，節節擊破。下面就帶大家一起體驗下叢林探險的整個心酸歷程。
[踩坑過程]
踩坑之前先給大家介紹下業務流程:XXX系統XXX張配置表數據從Oracle端通過阿里OMS工具實時同步到OB端，其它約XXX張業務數據表需要通過阿里OMS工具從OB端實時同步到Oracle端。
坑位1：業務日志表從ORACLEADG端導出數據失敗
某晚因集團版本需求生產端變更了表結構，因該方案中OGG部署於ADG環境無法自動同步DDL操作到目標端導致OGG同步失敗，需要對OGG同步中的表進行數據初始化操作。目標庫到源端ADG庫創建DBLINK，通過IMPDP工具參數network_link方式不落地遷移數據。
Impdprating/******** directory=dumpdir network_link=lnk_orayjjf1flashback_scn=16827177429142 cluster=no schemas=ratinginclude=table:"in (select tname from rating.rating430 )"TABLE_EXISTS_ACTION=REPLACE logfile=rating430_imp.log
報錯如下:
Connectedto: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bitProduction
Withthe Partitioning, Real Application Clusters, Automatic StorageManagement, OLAP,
DataMining and Real Application Testing options
FLASHBACKautomatically enabled to preserve database integrity.
Starting"RATING"."SYS_IMPORT_SCHEMA_02": rating/********directory=dumpdir network_link=lnk_orayjjf1flashback_scn=16827177429142 cluster=no schemas=ratinginclude=table:"in (select tname from rating.rating430 )"TABLE_EXISTS_ACTION=REPLACE logfile=rating430_imp.log
Estimatein progress using BLOCKS method...
Processingobject type SCHEMA_EXPORT/TABLE/TABLE_DATA
Totalestimation using BLOCKS method: 57.07 GB
Processingobject type SCHEMA_EXPORT/TABLE/PROCACT_INSTANCE
Processingobject type SCHEMA_EXPORT/TABLE/TABLE
.. imported "RATING"."SET_XXX" 328795472 rows
ORA-39014:One or more workers have prematurely exited.
ORA-39029:worker 1 with process name "DW00" prematurely terminated
ORA-31671:Worker process DW00 had an unhandled exception.
ORA-00600:internal error code, arguments: [ORA-00600: internal error code,arguments: [kksgaGetNoAlloc_Int0], [58], [5], [], [], [], [], [], [],[], [], []
],[], [], [], [], [], [], [], [], [], [], []
ORA-02063:preceding line from LNK_ORAYJJF1
ORA-06512:at "SYS.KUPW$WORKER", line 1887
ORA-06512:at line 2
處理方案:
查詢MOS相關資料分析為觸發OracleBug需要更新補丁，考慮到更新補丁時間較長，並且Oracle11g已不再提供補丁下載服務，因此決定從生產進行數據初始化操作，問題得以解決。
坑位2：OGG數據同步初始化完成后，出現抽取進程異常終止。
OGG運行日志ggserr.og出現如下錯誤：
2020-10-28T01:35:46.953BEIST WARNING OGG-01431 Oracle GoldenGate Delivery for Oracle,rrating.prm: Aborted grouped transaction on RATXXX.SET_XXX, Mappingerror.
2020-10-28T01:35:46.953BEIST WARNING OGG-01003 Oracle GoldenGate Delivery for Oracle,rrating.prm: Repositioning to rba 63598507 in seqno 27.
2020-10-28T01:35:46.953BEIST WARNING OGG-01151 Oracle GoldenGate Delivery for Oracle,rrating.prm: Errormapping from RATXXX.SET_XXX to RATXXX.SET_XXX.
2020-10-28T01:35:46.955BEIST ERROR OGG-01296 Oracle GoldenGate Delivery for Oracle,rrating.prm: Errormapping from RATXXX.SET_XXX to RATXXX.SET_XXX.
2020-10-28T01:35:46.955BEIST INFO OGG-02333 Oracle GoldenGate Delivery for Oracle,rrating.prm: Reading oracle_log/ogg/dirdat/rrating/re000000027,current RBA 63,598,507, 0 records, m_file_seqno = 27, m_file_rba =63,598,806.
2020-10-28T01:35:46.955BEIST ERROR OGG-01668 Oracle GoldenGate Delivery for Oracle,rrating.prm: PROCESSABENDING.
處理過程：
檢查OGG同步表配置信息，Oracle源端對象結構
檢查OGG同步表配置信息，Oracle目標端對象結構
發現目標端的表NOTNULL非空約束被DISABLE了，將表上的DISABLE非空約束改為ENABLE后，重啟OGG抽取進程表同步恢復正常。
坑位2：OGG同步過程中長事務造成“Lagat Chkpt”延遲。
OGG是基於事務級的實時復制工具，也就是說OGG只復制已提交的事務，在遇到事務的commit或rollback之前，它會將每個事務的操作存儲在稱為cache的托管虛擬內存池中。內存再大也有不夠用的時候，當事務數據超過一定的閾值或者當前空閑內存無法滿足分配請求時，OGG進程會將最少使用的oldbuffer swap 到磁盤上的dirtmp中
-
監控ggserr.log 中的長事務警告，可以通過配置extract 進程參數warnlongtrans 調整警告頻率 或者在抽取進程中配置參數: edit params exta
warnlongtrans5h,checkintervals 1h
備注：此參數的含義是每隔1h檢查一下長交易，如果超過5h的長交易就會記錄在根目錄的ggserr.log中
2、監控數據庫中的長事務
---判斷是否有大事務sqlselecta.sid,a.serial#,a.user#,a.username,b.addr,b.USED_UBLK,b.USED_UREC,b.START_TIME,b.xidusn,b.XIDSLOT, b.xidsqnfromv$transaction b, v$session awhere *b.addr in (select a.taddrfrom v$session a where a.sid = '') and*/ b.addr=a.taddr order bystart_time
3、ggsci提供了如下命令來處理長事務
Ggsci> sendextract ,showtrans查看正在處理的未提交事務。
語法:sendextract <進程名>, showtrans [thread n] [count n]
備注:<進程名>為所要察看的進程名，如extsz/extxm/extjx等；Threadn是可選的，表示只查看其中一個節點上的未提交交易；Countn也是可選的，表示只顯示n條記錄。
跳過事務（不建議）
Ggsci>sendextract ,skiptrans
語法:SENDEXTRACT <進程名>,SKIPTRANS <5.17.27634> THREAD <2> /跳過交易
強制認為事務已經提交（不建議）
Ggsci>send extract ,forcetrans
語法:SENDEXTRACT <進程名>,FORCETRANS <5.17.27634> THREAD <1> //強制認為該交易已經提交
建議所有的事務提交或回滾操作都在數據庫中進行。
樣例:檢查OGG同步日志ggserr.log發現存在長事務
2020-10-30T18:10:08.469BEIST WARNING OGG-01027 Oracle GoldenGate Capture for Oracle,erating.prm: Long Running Transaction: XID 993.6.69598, Items 1,Extract ERATING, Redo Thread 1, SCN 3918.1906392113 (16829588257841),Redo Seq #631053, Redo RBA 506349584.
處理過程：
在抽取進程中添加參數BR參數：BRBrInterval 1H, BRDir ./dirtmp
說明:將OGG抽取進程每次做檢查點時間有默認的4小時改為1小時，這樣OGG將長事務狀態及時寫入到磁盤，確保抽取進程的捕獲性能，減少Lagat Chkpt 延遲。
[分析總結]
基於OracleGoldenGate部署簡單、運維比較方便並且可以靈活地在同類和異類系統（包括不同版本的OracleDatabase、不同的硬件平台）之間以及Oracle數據庫和非Oracle數據庫（包括MicrosoftSQL Server、用於開放系統和z/OS的IBMDB2、Sybase等等）之間移動數據。因此被廣泛應用在日常運維中。今天的OGG故障分享到此結束，使用能夠幫助大家在日常運維OGG的過程中少走一些彎路。