本文记录了一次Oracle GoldenGate (OGG) 捕获进程异常导致的数据同步问题及解决方案。面对缺失归档日志的问题，通过调整检查点时间戳确保进程正常启动，并使用特定参数避免后续异常。
系统事件:
周1一大早接到某保险客户电话，说某套系统源端OGG捕获进程ABENDED了，并且延时达34小时之久。考虑到目标端ODS数据仓库层需要实时同步过来的数据，火速赶往之，去看看到底是什么情况导致的。
查看报错信息：
GGSCI> info all
Program
MANAGER
EXTRACT
EXTRACT
EXTRACT
尝试重新start ,进程还是ABENDED，查看具体错误信息：
GGSCI > view report EDBCONTR
***********************************************************************
Copyright (C) 1995, 2009, Oracle and/or its affiliates.
***********************************************************************
--More--(89%)
2014-06-30 11:31:51
ce 101258 thread 2 under default destinations SQL
ved_log
eleted = 'N>, error retrieving redo file name for sequence 101258, archived = 1,
a 2306576.
2014-06-30 11:31:51
结合以往的经验，给我的第一预感就是节点2上101258对应的归档日志已经不存在了。
检查归档日志：
检查节点2上的归档日志，发现最早的一个归档日志号为101316.
经过和客户的确认，该系统归档日志默认保留4天，正常情况来讲，35小时的延时似乎属于4天内的范围内，怎么会出现Could not find archived log 这一错误呢？
继续分析：
首先确认下sequence 为101258对应的归档日志是哪天生成的？
SQL>select * from v$archived_log where sequence#=101258; select * from v$log_history; select * from v$loghist;
175079 850987275
结果为101258号归档的产生时间为 2014-6-23 9:21:14，对照归档日志保留4天的策略，23号产生的归档日志的确是不存在的。
可问题是捕获进程延时才35小时（推算下进程失败的时间为6月29号凌晨0点左右），可为什么启动后需要去找6月23号的归档日志呢？以下的检查帮我找到了原因：
GGSCI > info edbcontr,showch
EXTRACT
Checkpoint Lag
Log Read Checkpoint
Log Read Checkpoint
Current Checkpoint Detail:
Read Checkpoint #1
Read Checkpoint #2
Write Checkpoint #1
我们知道，当OGG捕获进程重启后，内部会进行Recovery 操作，会去读取恢复检查点（Recovery Checkpoint ）指定的归档日志，从上面的结果显示，该日志号为 Sequence #: 101258。
常规处理方法：
实际处理方法：
同客户确认，23号到29号的同步一直是正常的。
为此，我们的处理方法是：将Recovery Checkpoint 对应的Timestamp改成
Current Checkpoint 对应的Timestamp，均为2014-06-29 00:20:15
具体操作步骤：
GGSCI>alter extract EDBCONTR ,tranlog ,begin 2014-06-29 00:20:15
GGSCI>start EDBCONTR
进程能够正常起来了，但该过程中陆续有挂掉的现象，再重新start下仍然可以继续运行，主要报以下2个错误：
2014-06-30 12:22:37
FROM "YXXT"."SYS_EXPORT_SCHEMA_01" (bad syntax) (status = 942-ORA-00942: table o
r view does not exist
2014-06-30 12:25:01
从报错的情况来看，进程是在29号晚上0点左右abended掉的，而0点左右系统在执行expdp操作，故上述报错是进程abended的罪魁祸首。
错误1：SYS_EXPORT_SCHEMA_01这类表是业务用户在执行expdp导数据生成的，为防止这个错误，我通过在捕获进程参数文件里面添加tableexclude参数来排除掉这类表；
错误2：超过系统最大游标数，该错误有可能是错误1引起的，在expdp过程中系统超过了最大游标数，故报该错误。
总结：
1： 通过手工修改 Recovery Checkpoint Timestamp ，和Current Checkpoint Timestamp 保持一致，保证进程重启后，能够跳过去读Sequence #: 101258号日志，而是让进程去读取Log Read Checkpoint对应的日志（2014-06-29 00:20:15 Thread 2, Seqno 101361, RBA 8411200），从而保证进程的后续捕获并追平延时。至于为什么这2个时间相差这么长，怀疑是不是23号存在某个事务，一直到29号都没有commit导致的？当然需要测试验证下。
2： 通过添加tableexclude 参数排除expdp操作产生的SYS_EXPORT_SCHEMA_01类型的表，防止进程异常abended.
扫一扫
253
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
