前些时间收到一个ogg问题咨询,现象为业务发现某个通过ogg同步的表源端和目标端数据量不一致,但是进程状态为running,并未看到报错,且不确定其他表格是否也存在这种现象。着手帮忙排查,大致排查过程如下:
检查ogg错误日志,确认没有报错输出检查进程状态
确认进程状态为running,没有abended过
进一步检查进程具体信息,定位到对应的表,查看相关信息
源端挖掘进程:stats 进程名
目标端应用进程:stats 进程名
从进程的具体统计信息看到,源端和目标端的处理操作数量不对等,对于insert和delete操作两边是一致的,但是对于update操作,可以看到目标端丢弃了1147条
4.查看discard文件 搜索该表相关信息,发现报错

在discard文件中,可以明确看到该表有相关的1403错误,该表是存在数据不一致的,一般遇到这种报错ogg进程都是会异常停止的,但是在相关时间段的ggserr.log日志中却没有进程异常相关输出
怀疑是参数配置有问题,对于该报错多了忽略处理,进一步检查该进程参数配置
5.检查进程配置参数
发现进程配置文件中配置了
reperror 1403,DISCARD,该配置表示,当遇到1403报错的时候只在discard文件中做记录,进程不停止,仍旧继续往下。
至此整个实际数据不一致,但是进程却正常的原因找到了,就是该参数导致的,一般针对1403错误我们需要进程abend并及时处理,否则时间越久,数据不一致可能就会越严重。当然这个参数只是在遇到1403报错时,没有将进程停止,导致我们没有及时发现报错,至于为什么会出现1403报错,需要进一步排查(后续发现是有人在源端重启过挖掘进程且修改过时间点导致数据缺失)。
处理办法:
1.去掉该参数
2.对有问题的表进行重新初始化,保证数据一致
编辑推荐:
下一篇:
相关推荐
-
雷神推出 MIX PRO II 迷你主机:基于 Ultra 200H,玻璃上盖 + ARGB 灯效
2 月 9 日消息,雷神 (THUNDEROBOT) 现已宣布推出基于英
-
制造商 Musnap 推出彩色墨水屏电纸书 Ocean C:支持手写笔、第三方安卓应用
2 月 10 日消息,制造商 Musnap 现已在海外推出一款 Oce
热文推荐
- OGG-参数谨慎使用(一)
OGG-参数谨慎使用(一)
26-03-03 - hyper xp,hyper xp的操作步骤,hyper-v批量管理工具的使用指南
- hyper-v虚拟化,hyper-v虚拟化的操作步骤,hyper-v批量管理工具的使用指南
- hyper v 网络,hyper v 网络的操作步骤,hyper-v批量管理工具的使用指南
- hyper v server,hyper v server的操作步骤,hyper-v批量管理工具的使用指南
- 一次低代码(APEX)的故障处理
一次低代码(APEX)的故障处理
26-03-03 - OGG DDL触发器引发的故障系列(三)
OGG DDL触发器引发的故障系列(三)
26-03-03 - hyper v与vmware,hyper v与vmware的操作步骤,hyper-v批量管理工具的使用指南
- OGG DDL触发器引发的故障系列(四)
OGG DDL触发器引发的故障系列(四)
26-03-03 - 数据库管理-第288期 杀!会话(20250128)
数据库管理-第288期 杀!会话(20250128)
26-03-03
