注：OGG是款很强大的异构和同构同步软件，知识点很多，但在使用过程中，即使很多地方比较清楚，但也难免会遇到一些很难遇到的坑，以下就是在使用OGG同步一套数据量比较大的Oracle 10G核心库到 19C的过程中遇到的坑，坑很浅，但确实不注意的话也能绊倒人。

一、问题描述：

在使用OGG同步Oracle 10G到19C的过程中，确实遇到了不少坑，有些坑虽然很浅，但确实不好发现，比如今天早上发现的这个坑。

早上同事在检查OGG源端和目标端的序列号是否正常同步时，发现XXX用户的序列号没有正常同步，并将这问题反馈给我，我当时第一反应是：不应该啊，其它几个配置的用户都能正常同步，方案是我写的，之前都同步过好多次，同样的配方，咋还不一样的味道呢。

二、问题排查：

首先查看了下写的方案，方案上没问题啊，也都测试过，咋单独XXX会有问题呢。

然后理一下思路，首先该问题应该不在目标端，如果是目标端有问题，肯定数据都不能正常同步了，如果有问题肯定在10G 源端。然后登陆10G 源端，查看了下源端的抽取进程和投递进程，投递进程没问题。

再看下抽取进程，猛地一看，也没啥问题，但仔细一瞧，发现抽取进程的 配置后面多了一个 ；，正常就一个 ；但此时XXX对应的序列配置项后多了 ；难道是因为这个问题导致的。

然后分别将目标端应用进程停了，然后再分别停了源端投递进程和抽取进程，修改了下抽取进程配置项，将那个多余的 ； 去掉，然后又按照顺序分别重启了抽取进程、投递进程、应用进程，进程正常启动，没有报错。

等过了一段时间，让同事排查下XXX序列能否正常同步，得到反馈开始同步，延迟1.5小时。

三、结论：

配置OGG的进程时，一定要好好检查配置项，不要轻易放过任何细节的东西，就如本次报错，直接查看OGG报错日志，没有给出报错信息，日志里不报错的问题项反而更难排查，所以更需要在日常操作时多小心注意。