大家应该还记得上次本大湿分享过一遍文章《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中

1. 监控ggserr.log 中的长事务警告，可以通过配置extract 进程参数warnlongtrans 调整警告频率 或者在抽取进程中配置参数:  
    edit params exta

 warnlongtrans5h,checkintervals 1h  

备注：此参数的含义是每隔1h检查一下长交易，如果超过5h的长交易就会记录在根目录的ggserr.log中

2、监控数据库中的长事务

 ---判断是否有大事务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是可选的，表示只查看其中一个节点上的未提交交易；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的过程中少走一些弯路。