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的过程中少走一些弯路。