前些时间收到一个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.对有问题的表进行重新初始化，保证数据一致
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/29956245/viewspace-3071267/ ，如需转载，请注明出处，否则将追究法律责任。
上一篇：
OGG DDL触发器引发的故障系列（二）
下一篇：
OGG DDL触发器引发的故障系列（三）
请登录后发表评论
登录
全部评论
