大家應該還記得上次本大濕分享過一遍文章《OceanBase數(shù)據(jù)同步挖掘日志慢解決方案》該方案引入OracleGoldenGate(以下簡稱OGG)進行數(shù)據(jù)同步。完美地解決了因OB挖掘日志慢影響整個項目割接進度問題。本以為該事件可以告一段落了，誰知在后面的一次OGG數(shù)據(jù)初始化過程中問題頻頻爆發(fā)。本大濕也是一路披荊斬棘，節(jié)節(jié)擊破。下面就帶大家一起體驗下叢林探險的整個心酸歷程。

踩坑之前先給大家介紹下業(yè)務流程:XXX系統(tǒng)XXX張配置表數(shù)據(jù)從Oracle端通過阿里OMS工具實時同步到OB端，其它約XXX張業(yè)務數(shù)據(jù)表需要通過阿里OMS工具從OB端實時同步到Oracle端。

坑位1：業(yè)務日志表從ORACLEADG端導出數(shù)據(jù)失敗

某晚因集團版本需求生產(chǎn)端變更了表結(jié)構(gòu)，因該方案中OGG部署于ADG環(huán)境無法自動同步DDL操作到目標端導致OGG同步失敗，需要對OGG同步中的表進行數(shù)據(jù)初始化操作。目標庫到源端ADG庫創(chuàng)建DBLINK，通過IMPDP工具參數(shù)network_link方式不落地遷移數(shù)據(jù)。

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相關資料分析為觸發(fā)OracleBug需要更新補丁，考慮到更新補丁時間較長，并且Oracle11g已不再提供補丁下載服務，因此決定從生產(chǎn)進行數(shù)據(jù)初始化操作，問題得以解決。

坑位2：OGG數(shù)據(jù)同步初始化完成后，出現(xiàn)抽取進程異常終止。

OGG運行日志ggserr.og出現(xiàn)如下錯誤：

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源端對象結(jié)構(gòu)

檢查OGG同步表配置信息，Oracle目標端對象結(jié)構(gòu)

發(fā)現(xiàn)目標端的表NOTNULL非空約束被DISABLE了，將表上的DISABLE非空約束改為ENABLE后，重啟OGG抽取進程表同步恢復正常。

坑位2：OGG同步過程中長事務造成“Lagat Chkpt”延遲。

OGG是基于事務級的實時復制工具，也就是說OGG只復制已提交的事務，在遇到事務的commit或rollback之前，它會將每個事務的操作存儲在稱為cache的托管虛擬內(nèi)存池中。內(nèi)存再大也有不夠用的時候，當事務數(shù)據(jù)超過一定的閾值或者當前空閑內(nèi)存無法滿足分配請求時，OGG進程會將最少使用的oldbuffer swap 到磁盤上的dirtmp中

1. 監(jiān)控ggserr.log 中的長事務警告，可以通過配置extract 進程參數(shù)warnlongtrans 調(diào)整警告頻率 或者在抽取進程中配置參數(shù):  
    edit params exta

 warnlongtrans5h,checkintervals 1h  

備注：此參數(shù)的含義是每隔1h檢查一下長交易，如果超過5h的長交易就會記錄在根目錄的ggserr.log中

2、監(jiān)控數(shù)據(jù)庫中的長事務

 ---判斷是否有大事務sql
selecta.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是可選的，表示只查看其中一個節(jié)點上的未提交交易；Countn也是可選的，表示只顯示n條記錄。

跳過事務（不建議）                                                                  

Ggsci>sendextract ,skiptrans                                            

語法:SENDEXTRACT <進程名>,SKIPTRANS <5.17.27634> THREAD <2> //跳過交易

強制認為事務已經(jīng)提交（不建議）  

Ggsci>send extract ,forcetrans                              

語法:SENDEXTRACT <進程名>,FORCETRANS <5.17.27634> THREAD <1> //強制認為該交易已經(jīng)提交                                                                                     

建議所有的事務提交或回滾操作都在數(shù)據(jù)庫中進行。 

樣例:檢查OGG同步日志ggserr.log發(fā)現(xiàn)存在長事務

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.

處理過程：

在抽取進程中添加參數(shù)BR參數(shù)：BRBrInterval 1H, BRDir ./dirtmp

說明:將OGG抽取進程每次做檢查點時間有默認的4小時改為1小時，這樣OGG將長事務狀態(tài)及時寫入到磁盤，確保抽取進程的捕獲性能，減少Lagat Chkpt 延遲。

基于OracleGoldenGate部署簡單、運維比較方便并且可以靈活地在同類和異類系統(tǒng)（包括不同版本的OracleDatabase、不同的硬件平臺）之間以及Oracle數(shù)據(jù)庫和非Oracle數(shù)據(jù)庫（包括MicrosoftSQL Server、用于開放系統(tǒng)和z/OS的IBMDB2、Sybase等等）之間移動數(shù)據(jù)。因此被廣泛應用在日常運維中。今天的OGG故障分享到此結(jié)束，使用能夠幫助大家在日常運維OGG的過程中少走一些彎路。