源端RAC数据库删除实例操作时GoldenGate的运维流程

文章背景

周六下午突然接到一个颇为头疼的任务——尽快为某客户提供一个 GoldenGate 操作方案，大体背景如下：

客户的生产环境是 Oracle 11GR2 的三节点的 RAC ，上面部署了两套 GoldenGate软件，一套抽取在线日志 + 归档文件、一套为 ALO （ Archived Log Only ，即只读归档）模式，由于数据库方面的原因，需要尽快做删除其中一个实例的操作，由于上面部署了 GoldenGate 软件，需要给出具体的运维流程，以保证删除实例的操作不影响GoldenGate 的数据同步。

笔者没有接触过这种场景，为了保持真实性，只好找三节点的环境做测试了，最终在几位同事的热心协助下，经过一天多的奋斗，终于在周一凌晨完成模拟环境下的测试并输出具体方案。

下文中，笔者将以 Q&A 的方式说明操作的关键点。

Q1: 不进行人工干预的情况下，源端删除实例的操作对GoldenGate 有何影响：

A1:

源端删除实例的操作主要影响 GoldenGate 抽取进程的运行。

针对 ALO 模式的 GoldenGate 抽取进程，由于 GoldenGate 需要获取各个实例的归档信息进行排序，因此不能缺少任一个节点的归档文件。删除实例的操作将使得GoldenGate 抽取进程因缺少被删除节点归档文件而无法正常工作，最终导致同步中断。注意，此处无法正常工作的表现形式不是显式的 ERROR 信息或者 WARNNING 信息，而是源端数据库发生变化，但队列文件无任何变更，且 current
checkpoint 一直不变。

针对抽取在线日志 + 归档文件方式的 GoldenGate 抽取进程，由于删除实例的操作会触发数据库侧在线日志组被删除的操作， GoldenGate 找不到相应日志组的时候会出现报错，笔者在虚拟机中遇到的错误如下：





除此之外，还有一种特殊的情况，那就是 GoldenGate 仍然为抽取在线日志 + 归档日志的模式，但由于 GoldenGate 软件的 BUG ，在被删除实例停止且尚未执行删除操作的时候， GoldenGate 就已经停止工作（状态 RUNNING ，队列文件无任何变更，且 current
checkpoint 一直不变）。这两天里面笔者在 Oracle DATABASE 11.2.0.1 的2 节点 RAC 环境以及 Oracle Database 11.2.0.2 的 3 节点 RAC 环境下分别作了测试，仅在 Oracle
Database 11.2.0.1 的 2 节点 RAC 环境遇到这种情况，此环境还有一个异常就是当一个节点空闲另一个节点上完全没有事务的时候，抽取进程直到另外一个节点有事务提交的时候才成功抽取。

Q2: GoldenGate 该如何配合源端执行删除实例的操作？

A2 ：

由于具体方案过于琐碎，笔者这里先说明大致的思路，涉及的细节下文会另外描述。

笔者分三个阶段进行处理。

第一阶段为“前期准备阶段”，此阶段在删除实例的工程实施前进行，主要工作包括参数测试以及调整、长事务处理。

第二阶段为“停止待删除实例阶段”，此阶段 Oracle DBA 将进行停止待删除实例的操作， GoldenGate 的重点工作为保障此实例后，抽取进程仍然可以正常工作，抽取变化数据。这样做是为了让删除实例阶段， GoldenGate 抽取进程的 current checkpoint 能到达甚至超过实例被删除的时间点。

第三阶段为“删除实例阶段”，此阶段 Oracle GoldenGate 将执行删除实例的操作，GoldenGate 的重点工作为确保队列文件延续性的前提下，重建抽取进程，使得GoldenGate 抽取进程能在调整后的环境下正常工作。

在完成整个文档后，笔者给自己提了一个问题：“删除实例当天， Oracle DBA 一气呵成地执行停止实例、删除实例操作，之后再作 GoldenGate 的调整，这样做沟通成本会降低，但可不可行呢？”

从刚开始规划方案到现在，笔者一直担心出现下述状况，源端数据库在三个节点的RAC 环境下，而 GoldenGate 却仅以两个节点方式去处理，这种做法必然造成抽取进程的数据丢失。那么， DBA “一气呵成”的做法能否避免这种状况呢？

至少从笔者测试的情况来看，停止实例后，就疑似因为 BUG 而 current checkpoint停滞不前，无法到达停止实例的时间点。测试环境尚且如此，谁能保证生成环境操作当天不遇到意外呢？于是我最终肯定了之前的想法，分两个阶段处理停止实例和删除实例。

Q3: GoldenGate 哪些技术细节对配合源端执行删除实例的操作存在影响？

A3:

笔者以列表形式总结如下：

技术细节	影响点
由于 GoldenGate 的 BUG ，抽取进程的 Bound Recovery 功能将无法使用	1） 需要进行长事务清理，具体处理原则需要事前拍板； 2） 需要保留足够的归档文件； 3） 调整抽取进程前需要检查 recovery checkpoint 。
ALO 模式的 GoldenGate 需要各个节点归档日志才能继续工作	1） 必要时需要进行手工切换在线日志并传输的操作，以触发 ALO 模式GoldenGate 抽取进程工作 2） 如需在某个实例停止的情况下继续工作，则需要使用 GoldenGate 参数THREADOPTIONS PROCESSTHREADS 。
THREADOPTIONS PROCESSTHREADS 为 undocumented参数	请在项目准备阶段测试此参数是否可行。
抽取在线日志 + 归档日志的模式下可能存在 BUG ，导致停止某个实例的情况下 current checkpoint 停滞不前	必要时采用 GoldenGate 参数THREADOPTIONS PROCESSTHREADS 。
正常情况下，抽取在线日志 + 归档日志的模式，删除实例的操作会触发数据库相应在线日志组被删除，进而导致GoldenGate 进程 ABEND	这是正常现象，仅需要按流程重建抽取进程即可
重建 GoldenGate 抽取进程涉及各实例的 current checkpoint 和 recovery checkpoint ，前者必须先修改，此外还涉及队列文件的 current checkpoint	1） 重建的过程务必注意操作的顺序 2） 重建完毕后务必对各个 checkpoint作检查，确保结果一致
GoldenGate 所识别的实例顺序不一定等于数据库的实例顺序	1） THREADOPTIONS PROCESSTHREADS EXCEPT 后跟的实例好为数据库实例 2） ALTER 操作后跟的 THREAD 参数执行的是 GoldenGate 识别的实例顺序 3） 启用此参数后，安全起见，应该利用自定义的表作一次检查

Q4: GoldenGate 如何保障某个实例被停止后抽取进程正常工作？

A4:

通常情况下，被停止的实例并非 GoldenGate 所部署的实例的话，仅会影响 ALO模式的 GoldenGate 抽取进程，导致此进程因没有归档文件而 current checkpoint 停滞不前。

解决方案为使用 THREADOPTIONS PROCESSTHREADS 参数，具体例子如下：



其中的数字为数据库的实例号。

笔者在测试中遇到一个异常，由于之前设定的归档路径重叠，而 GoldenGate 因实例已经终止无法获取 log_archive_format 参数设置，而无法启动，最终解决方法为在参数文件中补充相应配置，具体例子如下：





对于抽取在线日志 + 归档日志的 GoldenGate 抽取进程，如果遇到 BUG 而出现current checkpoint 停滞不前的情况，也可以参照 ALO 模式的处理方式，添加THREADOPTIONS
PROCESSTHREADS 参数。

Q5: 哪些手段能进一步保障整数据库删除实例相应的GoldenGate 配合流程？

A5:

为减少外界的干扰，可考虑通过下述手段进一步判断

1） 暂停管理进程的自动重启策略

2） 暂停管理进程的队列文件清理策略

删除抽取进程后，原有的队列文件可能会被管理进程误删，为避免这种情况，可暂停管理进程相应策略。

3） 抽取进程启用 REPORTCOUNT 参数，监控记录变更情况

参考配置如下：





此参数可以让 GoldenGate 进程每分钟报告报告变更的记录情况，输出结果例子如下：





此值可以与平时的情况相比，协助分析是否出现异常。

4） 配置 GoldenGate 监控表并捕获变更情况，协助分析进程工作情况

在各实例分别创建一个数据库表，以实例 1 为例，表名 goldengate.node1 ，自动脚本每个 5 秒钟往这个表插入一条数据。

将新增的几个表加入 GoldenGate 抽取进程策略，并以独立的队列文件存储。每当关键操作时，通过对 GoldenGate STATS 信息的监控判断 GoldenGate 有没有抽取相应实例的变更信息。

5） 抽取进程调整前后暂停投递进程工作，避免抽取进程异常改造误修改数据

在每次 GoldenGate 抽取进程调整之前，在停止抽取进程后，确认投递进程已经追平的前提下，暂停投递进程工作。

待确认抽取进程已经正常工作后，才恢复投递进程工作。

假如抽取进程出现异常，且抽取了错误的数据，则通过修改投递进程时间点的方式跳过相应的记录避免错误的数据入库。

Q6: 重建抽取进程期间 GoldenGate 如何准确修改各个checkpoint?

A6:

步骤 1 ）获取现有队列文件的 checkpoint 信息并清理旧进程

Oracle GoldenGate 重建抽取进程前，需要通过 info xxx,showch 的命令获取当前的 checkpoint 信息，此步骤非常关键，务必执行准确。

在获取抽取进程信息后，就可以进行删除旧的抽取进程，开始重建工作。

步骤 2 ）添加新的抽取进程

添加进程的语句与以往的创建方式是类似的，但 threads 需要相应减 1 ，例子如下：





步骤 3 ）为新的抽取进程添加队列文件

添加进程后，需要配置相应的队列文件，与以往创建方式不同，这里需要加入原有队列文件的 current checkpoint 信息。例子如下：

从之前的 info xxx,showch 中获取队列文件 current checkpoint 信息如下：





相应增加队列文件命令如下：





步骤 4 ）确认 GoldenGate 识别实例顺序信息

接下来需要确认 GoldenGate 识别的实例顺序是否与数据库配置一致，操作例子如下：





得到的关键信息如下：





上述信息仅需要留意顺序即可，其中错误的“ THREAD #:2 ”信息将在实例启动后自动调整，无需特殊处理。除此之外，我们还可以通过下述语句获取实例顺序信息：





如果出现 GoldenGate 识别顺序与数据库实际情况不一样，那么接下来的 ALTER EXT 命令就要替换相应的 THREAD 参数。

步骤 5 ）修改抽取进程的 current checkpoint 信息。

接下来的操作为修改抽取进程的 current checkpoint ，由于此操作会触发 recovery checkpoint 信息变更，因此必须先于 recovery checkpoint 调整。

例如从旧的 checkpoint 信息得到关键信息如下：





相应的执行语句例子如下：





步骤 6 ）修改抽取进程的 recovery checkpoint 信息。

修改抽取进程 recovery checkpoint 信息的操作并非 Oracle GoldenGate 所Support 的操作，因此在执行期间， GoldenGate 会要求用户确认，此处按 Y 让流程继续即可。

例如从旧的 checkpoint 信息得到关键信息如下：





相应执行的语句例子如下：





步骤 7 ）检查 GoldenGate 抽取进程时间点信息

此步骤为最终的检查项，目的在于验证抽取进程时间点信息是否一致。