# OGG数据同步异常问题总结 > 作者/来源: UCloud 运营管理员 > 发布时间: 2023-01-11T05:20:00.000Z > 分类: 解决方案 > 标签: 数据库, 存储 > 原文链接: http://117.50.162.249:3000/yun/articles/790 --- # OGG数据同步异常问题总结 > 来源: https://www.ucloud.cn/yun/130087.html > 作者: IT那活儿 > 发布日期: 发布于2023-01-11 13:20 OGG数据同步异常问题总结 [ 事件背景 ] 大家应该还记得上次本大湿分享过一遍文章《OceanBase数据同步挖掘日志慢解决方案》该方案引入OracleGoldenGate(以下简称OGG)进行数据同步。完美地解决了因OB挖掘日志慢影响整个项目割接进度问题。本以为该事件可以告一段落了，谁知在后面的一次OGG数据初始化过程中问题频频爆发。本大湿也是一路披荆斩棘，节节击破。下面就带大家一起体验下丛林探险的整个心酸历程。 [ 踩坑过程 ] # 踩坑之前先给大家介绍下业务流程:XXX系统XXX张配置表数据从Oracle端通过阿里OMS工具实时同步到OB端，其它约XXX张业务数据表需要通过阿里OMS工具从OB端实时同步到Oracle端。 ![](https://ucloud-blog.cn-bj.ufileos.com/articles/130087/images/130087_000.png) 坑位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数据同步初始化完成后，出现抽取进程异常终止。 ![](https://ucloud-blog.cn-bj.ufileos.com/articles/130087/images/130087_001.png) 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源端对象结构 ![](https://ucloud-blog.cn-bj.ufileos.com/articles/130087/images/130087_002.png) 检查OGG同步表配置信息，Oracle目标端对象结构 ![](https://ucloud-blog.cn-bj.ufileos.com/articles/130087/images/130087_003.png) 发现目标端的表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 ![](https://ucloud-blog.cn-bj.ufileos.com/articles/130087/images/130087_004.png) 说明:将OGG抽取进程每次做检查点时间有默认的4小时改为1小时，这样OGG将长事务状态及时写入到磁盘，确保抽取进程的捕获性能，减少Lagat Chkpt 延迟。 [ 分析总结 ] # 基于OracleGoldenGate部署简单、运维比较方便并且可以灵活地在同类和异类系统（包括不同版本的OracleDatabase、不同的硬件平台）之间以及Oracle数据库和非Oracle数据库（包括MicrosoftSQL Server、用于开放系统和z/OS的IBMDB2、Sybase等等）之间移动数据。因此被广泛应用在日常运维中。今天的OGG故障分享到此结束，使用能够帮助大家在日常运维OGG的过程中少走一些弯路。