在维护GoldenGate过程中，由于各种意外情况，难免还是会遇到各种各样的问题。掌握一些常见的GoldenGate故障诊断和错误分析的方法是非常有必要的，而且掌握这些错误分析工具也进一步加深对GoldenGate产品的认识与对GoldenGate原理的理解。

GoldenGate运行起来后，随着时间的推移可能会碰到各种各样的问题，下面就来介绍常见的异常现象以及常见的异常处理方法。

1.1  异常处理的一般步骤

首先确定是GoldenGate的哪类进程有故障（是抽取，投递还是复制进程有问题），解决故障的一般思路如下。

（1）通过GGSCI>view report命令查找ERROR字样，确定错误原因并根据其信息进行排除。

（2）通过GGSCI>view ggsevt查看告警日志信息。

（3）检查两端数据库是否正常运行，网络是否连通。

（4）通过logdump工具对队列文件进行分析。


1.2  RAC单节点失败

在RAC环境下，GoldenGate软件安装在共享目录下，可以通过任一个节点连接到共享目录，启动GoldenGate运行界面。如果其中一个节点失败，导致GoldenGate进程中止，可直接切换到另外一个节点继续运行。

操作步骤如下。

（1）以Oracle用户登录源系统（使用另外一个正常的节点）。

（2）确认将GoldenGate安装的所在文件系统装载到另一节点相同目录。

（3）确认GoldenGate安装目录属于Oracle用户及其所在组。

（4）确认Oracle用户及其所在组对GoldenGate安装目录拥有读写权限。

（5）进入GoldenGate安装目录。

（6）执行。/ggsci进入命令行界面。

（7）执行start mgr启动MGR。

（8）执行start er *启动所有进程。

检查各进程是否正常启动，即可进入正常复制。


1.3  Extract常见异常

以下为列举的一些常见错误信息作参考用。

Extract进程包括抽取与投递进程，投递进程报错大部分原因是由于网络故障。对于源数据库，抽取进程ext**如果变为abended，则可以通过在GGSCI中使用view report命令查看报告，可以通过搜索ERROR快速定位错误。

一般情况下，抽取异常的原因是因为其无法找到对应的归档日志，可以通过到归档日志目录命令行下执行

示例1：

ls –lt arch_x_xxxx.arc

查看该日志是否存在，如不存在则可能的原因如下。

日志已经被压缩。

GoldenGate无法自动解压缩，需要人工解压缩后才能读取。

日志已经被删除。

如果日志已经被删除，需要进行恢复才能继续复制。

一般需要定期备份归档日志，并清除旧的归档日志。需要保证归档日志在归档目录中保留足够长时间之后，才能被备份和清除。即定期备份清除若干小时之前的归档，而不是全部归档。保留时间计算如下。

某归档文件保留时间抽取进程处理完该文件中所有日志所需的时间。

可以通过命令行或者GoldenGate Director Web界面，运行info extxx showch命令查看抓取进程ext处理到哪条日志序列号。在此序列号之前的归档，都可以被安全的清除。

抽取进程在抽取不支持的数据对象时也会abend，report文件会有详细的报错信息，根据report文件来定位错误信息然后再排错即可。


下面再单独列出更多的几个故障。

（1）Extract: Application failded to initialize（Win）。

错误信息：run GGSCI command but the Alert window report "Application failded to initialize（0xc000026e）"。

GoldenGate在Windows平台上需要安装Microsoft Visual C ++ 2005 SP1 Redistributable Package。如果是Microsoft Itanium平台，需要安装vcredist_IA64.exe。

Windows 2008需以下额外操作：右击‘cmd’ （DOS），选择‘run as administrator’，然后在该命令行窗口中启动MGR和Extract才能够读取数据库日志。

将OGG安装为服务时（即运行“install ADDSERVICE”），需要使用管理员权限，这样启动服务后即能访问日志。

通过以下方法为运行MGR和Extract的用户添加读取日志文件的权限，右键单击文件->property->security->edit->add。


（2）Extract: Cannot load program./ggsci…

错误分析：请首先检查该OGG Build是否与操作系统和数据库相符；其次如果是Aix请检查xLC版本是否符合10.0以上。

另外，检查环境变量中动态库路径是否包含了数据库动态库目录，例如：

示例2：

export LD_LIBRARY_PATH=$ORACLE_HOME/lib

不同平台下的环境变量不同。

AIX  LIBPATH。

Solaris、Linux等  LD_LIBRARY_PATH。

HP-Unix  SHLIB_PATH。

重设环境变量需重启Mgr和Ext/Rep进程。


（3）Extract: Block size mismatch （8192/512）…

裸设备的偏移量各操作系统默认为0，但AIX默认为4096。当创建裸设备时使用了-TO选项时，Oracle不会跳过4096字节而是直接从0开始读写。 因此在AIX下使用裸设备时，出现此错误需要指定OGG从偏移量0开始读取。

示例3：

tranlogoptions rawdeviceoffset 0

该参数其在实际环境中使用几率非常高，在以前版本中如果缺少此参数Extract立即终止，但新版本Extract会持续进行尝试，并不自动终止，需检查报告文件。



（4）Extract: ORA-15000 ASM connection error

该错误为OCI错误，表示Extract是在连接数据库时出现问题，根据错误信息判断为权限问题。

首先在Extract参数中检查ASM相关参数tranlogoptions asmuser sys@+ASM1，asmpassword oracle，再检查tnsnames.ora和listener.ora验证ASM实例配置是否正确，确认ASM用户具有SYSDBA 权限；如果使用SYS，需要将ASM实例的init.ora中REMOTE_LOGIN_PASSWORDFILE参数设置为SHARED（多个数据库可以使用一个password文件，只有SYS用户可以远程登录）。

使用sqlplus验证：

示例4：

sqlplus sys/oracle@asm1 as sysdba；//可以登录

sqlplus sys/oracle@asm1；          //报告15000错误



（5）Extract: Encountered SCN That Is Not Greater Than The Highest SCN Already Processed…

原因分析：在Oracle RAC环境中，Extract会启动一个coordinator线程对各个节点上的操作进行根据SCN进行排序，它在交易提交后会等待THREADOPTIONS MAXCOMMITPROPAGATIONDELAY参数所定义时间来确认空闲节点没有交易，然后再收集交易数据；写入该交易后如果空闲节点后来又读到了一个SCN号要小的交易，则会报告该错误。

可能原因：

各节点之间没有配置时钟同步。

一个节点比另外一个节点慢（IO问题可能性较大）。

解决办法：

调整Extract参数：


示例5：

THREADOPTIONS MAXCOMMITPROPAGATIONDELAY <msec> IOLATENCY <msec>

MAXCOMMITPROPAGATIONDELAY有效范围是0-90000ms，默认为3s（即3000ms）。

GGS Vx多了一个IOLATENCY参数，可以与上面参数一起加大等待时间。IOLATENCY默认为1.5s，最大值为180000。

建议出现该错误后可以将此二参数设置为较大值，然后逐步降低获取最佳设置。

需要补充说明的是，出现此错误后，因后面的交易可能已被写入日志，重启Extract可成功启动，但是可能出现如下问题：Extract会重写当前队列覆盖前面的交易数据，后面的Data Pump进程可能会出现“abend with incompatible record errors”错误终止（旧版本可能出现）。

此问题的恢复步骤如下。

① 停止所有Data Pump和Replicat，针对所有的Extract记录其Write Checkpoint的队列Seqno。

② 对于每个Extract向下滚动一个队列：


示例6：

ALTER EXTRACT [name], ETROLLOVER

启动Extract查看是否滚动到了下一个队列，记录其新队列seqno，应当是旧队列号+1。

③ 修改Data Pump从新的队列开始传输：


示例7：

ALTER EXTRACT [pump_name], EXTSEQNO ##### EXTRBA 0

重启Data Pump查看是否能够重启成功并从新的队列传输。

④ 修改Replicat参数文件，加入或者打开HANDLECOLLISIONS，如果有GROUPTRANSOPS和MAXTRANSOPS请注释掉，启动Replicat，观察其是否能够读取新传输过来的队列如Replicat无法自动滚动到下一个队列，需要通过如下命令手工滚动：

示例8：

alter replicat [replicat_name], EXTSEQNO ##### EXTRBA 0

等待Replicat处理到结尾没有延迟时，可以关闭HANDLECOLLISIONS和恢复原来的GROUPTRANSOPS和MAXTRANSOPS参数。

⑤ 重新启动Replicat即可恢复正常复制。



1.4  网络故障

如果MGR进程参数文件里面设置了autorestart参数，GoldenGate可以自动重启，无需人工干预。

当网络不稳定或者发生中断时， GoldenGate负责产生远地队列的Pump进程会自动停止。 此时，MGR进程会定期根据mgr.prm里面autorestart设置自动启动Pump进程以试探网络是否恢复。在网络恢复后，负责产生远程队列的Pump进程会被重新启动，GoldenGate的检查点机制可以保证进程继续从上次中止复制的日志位置继续复制。

需要注意的是，因为源端的抽取进程（Capture）仍然在不断地抓取日志并写入本地队列文件，但是Pump进程不能及时把本地队列搬动到远地，所以本地队列文件无法被自动清除而堆积下来，需要保证足够容量的存储空间来存储堆积的队列文件。计算公式如下。

存储容量单位时间产生的队列大小×网络故障恢复时间

MGR定期启动抓取和复制进程参数配置参考：

示例9：

GGSCI > edit param mgr

port 7809

autorestart er *,waitminutes 3,retries 5,RESETMINUTES 60

每3分钟重试一次，5次重试失败以后等待60分钟，然后重新试三次。



1.5  Replicat进程常见异常

对于目标数据库，投递进程repXX如果变为abended，则可以通过在GGSCI中使用view report命令查看报告，可以通过搜索ERROR快速定位错误。

复制进程的错误通常为目标数据库错误，比如：

数据库临时停机。

目标表空间存储空间不够。

目标表出现不一致。

可以根据报告查看错误原因，排除后重新启动rep进程即可。

需要注意一点：往往容易忽略UNDO表空间。如果DML语句中包含了大量的UPDATE和DELETE操作，则目标端UNDO的生成速度会很快，有可能填满UNDO表空间。

典型错误（数据复制典型错误）如下：

示例10：

- SQL error 1403 mapping  2010-02-25 13:20:08  GGS WARNING     218  Oracle GoldenGate Delivery for Oracle, rep_stnd.prm:  SQL error 1403 mapping HR.MY_EMPLOYEE to HR.MY_EMPLOYEE.

可能原因包括以下几个方面。

两端结构不一致（异构环境，列和主键不同）。

两端有不一致记录。

附加日志不全。

可以到discard文件中查看具体错误信息，如果为UPDATE或者DELETE找不到对应记录，并且某几个字段为空，则可认定为缺少了附加日志。


oracle视频教程请关注:http://u.youku.com/user_video/id_UMzAzMjkxMjE2.html