[事件背景]

大家應該還記得上次本大濕分享過一遍文章《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.xidsqn
fromv$transaction b, v$session a
where /*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的過程中少走一些彎路。

總結

以上是生活随笔為你收集整理的table类型数据提交_OGG数据同步异常问题总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。