文章背景
周六下午突然接到一个颇为头疼的任务——尽快为某客户提供一个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:
笔者以列表形式总结如下：
Q4: GoldenGate如何保障某个实例被停止后抽取进程正常工作？
A4:
通常情况下，被停止的实例并非GoldenGate所部署的实例的话，仅会影响ALO模式的GoldenGate抽取进程，导致此进程因没有归档文件而current checkpoint停滞不前。
解决方案为使用THREADOPTIONS PROCESSTHREADS参数，具体例子如下：
THREADOPTIONS PROCESSTHREADS EXCEPT 2
其中的数字为数据库的实例号。
笔者在测试中遇到一个异常，由于之前设定的归档路径重叠，而GoldenGate因实例已经终止无法获取log_archive_format参数设置，而无法启动，最终解决方法为在参数文件中补充相应配置，具体例子如下：
TRANLOGOPTIONS ALTARCHIVEDLOGFORMAT THREADID 2 %t_%s_%r.dbf
对于抽取在线日志+归档日志的GoldenGate抽取进程，如果遇到BUG而出现current checkpoint停滞不前的情况，也可以参照ALO模式的处理方式，添加THREADOPTIONS PROCESSTHREADS参数。
Q5:哪些手段能进一步保障整数据库删除实例相应的GoldenGate配合流程？
A5:
为减少外界的干扰，可考虑通过下述手段进一步判断
1）暂停管理进程的自动重启策略
2）暂停管理进程的队列文件清理策略
删除抽取进程后，原有的队列文件可能会被管理进程误删，为避免这种情况，可暂停管理进程相应策略。
3）抽取进程启用REPORTCOUNT参数，监控记录变更情况
参考配置如下：
REPORTCOUNT EVERY 1 MINUTES, RATE
此参数可以让GoldenGate进程每分钟报告报告变更的记录情况，输出结果例子如下：
127256 records processed as of 2013-06-24 17:30:07 (rate 255,delta 331)
此值可以与平时的情况相比，协助分析是否出现异常。
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，例子如下：
add ext ext_onl, tranlog, begin now, threads 2
步骤3）为新的抽取进程添加队列文件
添加进程后，需要配置相应的队列文件，与以往创建方式不同，这里需要加入原有队列文件的current checkpoint信息。例子如下：
从之前的info xxx,showch中获取队列文件current checkpoint信息如下：
Current Checkpoint (current write position):
Sequence #: 1
RBA: 230371
Timestamp: 2013-06-23 17:20:19.258601
Extract Trail: ./dirdat/eonl/ss
相应增加队列文件命令如下：
ADD EXTTRAIL ./dirdat/eonl/ss, EXTRACT ext_onl, megabytes 100, seqno 1, rba 230371
步骤4）确认GoldenGate识别实例顺序信息
接下来需要确认GoldenGate识别的实例顺序是否与数据库配置一致，操作例子如下：
info ext_onl, showch
得到的关键信息如下：
Read Checkpoint #1
Oracle RAC Redo Log
Startup Checkpoint (starting position in the data source):
Thread #: 1
Sequence #: 0
RBA: 0
Read Checkpoint #2
Oracle RAC Redo Log
Startup Checkpoint (starting position in the data source):
Thread #: 2
Sequence #: 0
RBA: 0
上述信息仅需要留意顺序即可，其中错误的“THREAD #:2”信息将在实例启动后自动调整，无需特殊处理。除此之外，我们还可以通过下述语句获取实例顺序信息：
select distinct thread# from v$log;
如果出现GoldenGate识别顺序与数据库实际情况不一样，那么接下来的ALTER EXT命令就要替换相应的THREAD参数。
步骤5）修改抽取进程的current checkpoint信息。
接下来的操作为修改抽取进程的current checkpoint，由于此操作会触发recovery checkpoint信息变更，因此必须先于recovery checkpoint调整。
例如从旧的checkpoint信息得到关键信息如下：
Current Checkpoint (position of last record read in the data source):
Thread #: 1
Sequence #: 17
RBA: 9194144
Current Checkpoint (position of last record read in the data source):
Thread #: 3
Sequence #: 10
RBA: 5740032
相应的执行语句例子如下：
alter EXT_ALO,extseqno 17,extrba 9194144,thread 1
alter EXT_ALO,extseqno 10,extrba 5740032,thread 2
步骤6）修改抽取进程的recovery checkpoint信息。
修改抽取进程recovery checkpoint信息的操作并非Oracle GoldenGate所Support的操作，因此在执行期间，GoldenGate会要求用户确认，此处按Y让流程继续即可。
例如从旧的checkpoint信息得到关键信息如下：
Recovery Checkpoint (position of oldest unprocessed transaction in the data source):
Thread #: 1
Sequence #: 17
RBA: 9193488
Recovery Checkpoint (position of oldest unprocessed transaction in the data source):
Thread #: 3
Sequence #: 10
RBA: 5739536
相应执行的语句例子如下：
alter EXT_ALO,ioextseqno 17,ioextrba 9193488,thread 1
alter EXT_ALO,ioextseqno 10,ioextrba 5739536,thread 2
步骤7）检查GoldenGate抽取进程时间点信息
此步骤为最终的检查项，目的在于验证抽取进程时间点信息是否一致。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/29960155/viewspace-1352828/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/29960155/viewspace-1352828/
1280
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
