GoldenGate间断性休眠的troubleshooting

GoldenGate（以下简称ogg）简单易用，老司机的环境中在很多场景下使用了ogg。“俗话说常在河边走，哪有不湿鞋”，ogg用的多了自然也会遇到一些问题，以下老司机分享两个ogg问题。尤其是问题一，希望大家不要再踩坑。简单的复习下，ogg主要有三类进程：

1、extract进程：运行在数据库源端，实时捕获源端数据库表和日志数据；

2、pump进程：其作用是把源端本地trail文件以数据块的形式通过TCP/IP协议发送到目标端（推荐的方式）。pump进程本质是extract进程的一种特殊形式，如果不使用trails文件，extract进程可以在抽取完数据以后，直接投递到目标端；

3、Replicat进程：通常我们也把它叫做应用进程。运行在目标端，负责读取目标端trail文件中的内容，并将其解析为DML、DDL语句或消息记录，然后应用或投递到目标系统。

我们看看老司机的环境架构：源端Extract进程实时抽取增量数据并由Pump进程投递到oggfor bigdata（Adapter）的Replicat进程解析并将增量数据实时投递到kafka。架构图如下：

接下来分享下如上架构遇到的一些问题。

问题一、Ogg19+Oracle DB 19.6 Extract Hangs

近期将一套11g的数据库迁移到了19c上，同时老环境中的ogg相关进程也对应迁移到了19c上面。在新环境里Extract进程会不定时的hang，lag经常超过1个小时，这对于此类进程对应的下游实时应用是灾难性的。

老司机怎么会容忍lag超过1个小时呢，说出来也是泪，因为老司机也不知道发生了什么。1个小时都过去了，老司机都不知道发生了什么，那老司机干嘛去了。莫慌，捋一捋，老司机查看了report、errorlog、HCrpt、长事务、数据库event等信息，并且多次重启了hang状态进程。从日志中看到的都是有关长事务的warning，但数据库中没有查询到长事务。

经过日志分析，老司机决定加上SKIPEMPTYTRANS参数并调整了内存限制max_sga_size至4096。进程的原始参数配置如下：

参数调整后，赶紧重启进程，很不幸问题依旧。于是也就有了后来的一次又一次延迟超过1小时和老司机被应用围着一圈又一圈的场景。

相应日志没有提供其它可用信息，参数配置也已经是较优的状态。老司机严重怀疑这是ogg的bug导致，于是向官方求助，同时老司机也在mos上找到了类似问题的文档IntegratedExtract Hangs After Upgrade To Ogg 19/oracle Db 19.5 (Doc ID2649420.1)。

到此大家应该认为这个问题解决了，后来的过程咱不说了，就告诉大家这个问题经历了一个月时间才得到官方的有效回复，官方实际给出了另一个bug，且是内部bug，无mos文档可查。官方也给出了workground，将TRANLOGOPTIONSINTEGRATEDPARAMS (max_sga_size 2048,parallelism4)中的parallelism调整为1。Workground应用后经过几个星期的验证，问题已得到有效解决。

问题二、 ogg到kafka“lag”优化

在这里老司机说的“lag”并非在ogg中执行infoall看到的lag，实际上在老司机的环境中，执行infoall得到的lag结果为0。请大家耐心往下看。

我们来看下一条kafkatopic中的数据示例：

说明：oggforbigdata解析投递到Kafka中的消息字段以“|”分隔，第一个字段为操作类型，示例数据操作类型为“I”，即insert操作；第二个字段为表属主及表名；第三个字段为该条记录在源端数据库中的提交时间；第四个字段为kafka接收该条记录的时间；后续字段分别为ogg标识位和表字段对应信息。

我们可以很明显的看到第三个字段和第四个字段的时间差超过3秒，实际生产表记录显示的时间差甚至超过10s。这意味着一条记录在数据库中提交，然后被ogg捕捉并投递到kafka所需时间要几秒甚至10几秒，这怎么可能？老司机又执行了一次infoall看了看lag，结果仍然为0。至此大家应该知道老司机说的是啥“lag”了。于是老司机轮起了三板斧分别对extract和replicat进程进行了优化，以提高复制的效率。

在源端extract进程中加入了如下参数：

FLUSHCSECS 1     刷新extract内存缓冲区时间间隔

EOFDELAYCSECS 1  控制读到trail末尾检查新数据的频率

在目标端replicat进程中调整了如下参数：

GROUPTRANSOPS 1  控制在需要提交之前可以分组到事务中的最大批处理操作数

MAXTRANSOPS 1    将大型源事务拆分为目标系统上的较小事务

以上参数调整后，“lag”明显缩短。但也有部分进程的lag（infoall查看的结果）不断增加，老司机判断是进程中涉及表变更量太大，replicat进程调整的参数反而降低了进程效率，将参数GROUPTRANSOPS值调整为10000，进程lag终于消除了。对于这部分进程虽然做了反操作，“lag”值也没能缩短，但最终不会被应用围着了，“lag”和lag相比，老司机更欢“lag”。老司机的目标是将“lag”缩短至3秒以内。好消息是上述参数加入后“lag”明显缩短，坏消息是“lag”仍然大于3秒。由于官方回复这是正常现象，至此老司机也不再折腾。