GoldenGate 异常处理预案

Posted 2020-10-07 长城之上是千亿的星空，星空之上是不灭的守望。

异常处理一般步骤

如果GoldenGate复制出现异常，可以通过以下步骤尝试解决问题：

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

2)        通过ggsci>view ggsevt查看告警日志信息；

3)        检查两端数据库是否正常运行，网络是否连通；

4)        如不能确定错误原因，则可以寻求Oracle技术支持。在寻求技术支持时一般需要提供以下信息：

ü  错误描述

ü  进程报告，位于dirrpt下以大写进程名字开头，以.rpt结尾，如进程名叫extsz，则报告名字叫EXTSZ.rpt；

ü  GGS日志ggserr.log，位于GGS主目录下；

ü  丢失数据报告，在复制进程的参数disardfile中定义，一般结尾为.dsc；

ü  当前队列，位于dirdat下。

网络故障

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

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

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

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

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

GGSCI > edit param mgr

port 7839

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

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

RAC环境下单节点失败

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

1)        以oracle用户登录源系统（通过另一完好节点）；

2)        确认将GoldenGate安装所在文件系统装载到另一节点相同目录；

3)        确认GoldenGate安装目录属于oracle用户及其所在组；

4)        确认oracle用户及其所在组对GoldenGate安装目录拥有读写权限；

5)        进入goldengate安装目录；

6)        执行./ggsci进入命令行界面；

7)        执行start mgr启动mgr；

8)        执行start er *启动所有进程；

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

Extract进程常见异常

对于源数据库，抽取进程extxm如果变为abended，则可以通过在ggsci中使用view report命令察看报告，可以通过搜索ERROR快速定位错误。

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

ls –lt arch_X_XXXXX.arc

察看该日志是否存在，如不存在则可能的原因是：

1)        日志已经被压缩

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

2)        日志已经被删除

如果日志已经被删除，需要进行恢复才能继续复制，请联系本单位DBA执行恢复归档日志操作。

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

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

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

 

Replicat进程常见异常

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

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

1)        数据库临时停机；

2)        目标表空间存储空间不够；

3)        目标表出现不一致。

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

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

抽取生成的队列文件比归档文件多

1)        现象

在国网多个网省的业务系统中出现了某一时间段内，OGG的抓取进程所产生的数据队列远远大于Oracle数据库所产生的归档日志，导致OGG队列存放位置空间不够用。

2)        原因分析

OGG本身是解析数据库的归档日志并从中获取有效的数据变化，在一般情况下其所抽取出来的数据队列要小于归档日志产生量。

但是，也有特殊情况，例如Oracle数据库在修改BLOB/CLOB/Long等占用空间特别大的数据对象时，为了降低日志的产生量及其对数据库整体性能的影响，其在数据库日志中只记录一个标识说明该字段发生了变化，但并不将该字段的Before Image和After Image真正写入日志，然后直接将新数据写到数据库覆盖原来的旧值。

OGG在进行数据复制时，为了能够使目标数据与源端保持一致，必须要在Trail里面写入update以后该字段after image的实际值，由于这些信息在日志文件中是没有的，OGG就会根据日志中记录的信息到数据库中去查询该大字段的实际值，将这个从数据库中获取的值放到队列文件中，日志文件是没有这个实际值的。由于这些对象非常大，也就导致OGG的队列文件会比日志增加了很多倍。队列文件具体增大的倍数决定于特定时间段内的大对象更新频率和每个大对象的实际值，实际应用中较难精确计算，可以根据实际运行统计值对队列所需空间进行估算。

综上所述，队列文件较大完全是正常现象，数据全部能够正常入库也证实了我们的判断。

3)        解决方案

针对队列较大，可能引起空间不够的问题，以下为可选方案，可以根据各网省具体情况选择其中一个或者两个：

ü  缩短保留队列的时间

可以调节OGG自动删除队列间的参数，缩短保留队列的时间。例如，在MGR的参数里面：

PURGEOLDEXTRACTS /ggs/dirdat/ *, USECHECKPOINTS, MINKEEPHOURS 96

其中，MINKEEPHOURS表示要保留队列的最小时间。如果当前为96，表示至少会保留4天的队列；经过观察现有磁盘空间大约可以满足2天多的队列，则可以修改为48。

修改后需重启MGR使新参数生效。MGR进程会自动删除超过指定时间的队列。

本方法在源和目标均适用。

说明：USECHECKPOINTS 表示OGG删除队列时必须要保证该队列已经被使用过了，那些没有被应用过的队列即使超过规定时间也是不会被自动删除的。

ü  扩大磁盘空间

如果本地磁盘尚有空余，可以考虑为OGG增加磁盘空间。

本方法在源和目标均适用。

ü  对磁盘空间进行监控

可以通过监控工具或脚本定时监控OGG所在位置的磁盘使用率，一旦到达即报警，交由相应人员改变保存队列策略或人工处理。

OGG的Extract进程占用内存较大

1)        现象

源端的Extract进程有占用较大内存。

2)        原因分析

OGG的Extract占用的内存包括两部分：

一部分用来存储复制表的结构等相关数据字典信息。此部分跟表的数量有关，但总量一般在几十兆以内，无需特别关注；

另外一部分用来存储当前数据库中所有未提交的交易数据，当事务提交后OGG会将内存中的数据写入Trail，然后释放内存。这是某些时候OGG的Extract进程占用内存较多的主要原因。

为了防止所需内存总量超过实际物理内存，OGG提供了cachemgr参数，可以在内存不够时使用本地硬盘作为缓存。举例如下：

CACHEMGR CACHESIZE 500MB, CACHEDIRECTORY /ggs/temp, CACHEDIRECTORY /ggs2/temp

本例中，如果OGG的Extract进程所需内存超过了500M，则会将交易数据写到指定的两个位置下作为虚拟内存。一旦这些交易提交，则会将这些虚拟内存与内存同样清除。

注：不推荐设置该参数时，默认OGG会将允许使用的内存64位系统设置为8G，32位系统为2G。默认的虚拟内存空间为安装目录下的dirtmp。

3)        排查方法与解决方案

一旦出现Extract报告内存问题，各网省可根据以下步骤进行排查和选择解决方案：

ü  排查操作系统对于内存的限制

在主机上使用ulimit –a查看OGG运行用户（一般为oracle）用户在操作系统级的资源允许状况，例如：

time(seconds)        unlimited

file(blocks)         unlimited

data(kbytes)         unlimited

stack (kbytes)        unlimited

memory(kbytes)       unlimited

coredump(blocks)     4194303

nofiles(descriptors) 15000

这些限制的配置一般在/etc/security/limits文件里，建议将其中的data/stack/memory都设置为unlimited(-1)，至少要保证该配置可以让OGG使用cachemgr所允许的最大内存，可以联系系统管理员予以调整。

ü  调整cachemgr参数

如果物理内存有限，而本地磁盘尚有空余，可以减小OGG的cachemgr参数中的CACHESIZE，如原来允许使用2G，现在可以修改为1G，不够可以去使用硬盘作为虚拟内存。

注：由于IO方面硬盘和内存差距较大，使用硬盘作为虚拟内存会带来性能方面的下降。

ü  尝试重启Extract进程查看内存使用

OGG本身有自动调节资源占用的特性，即如果系统本身空闲，则其会自动申请更多资源加速数据复制；而如果系统资源紧张，则会释放部分资源给优先级更高的进程。

如果想尽快了解Extract进程内存占用是否正常，可以尝试重启进程，观察其内存占用是否正常。注意：重启Extract时检验其所需的归档日志是否存在，具体方法参照运维文档中停止OGG进程的步骤。

ü  添加物理内存

如果系统日常业务繁忙阶段现有物理内存占用率非常高，则建议对系统进行内存扩容。在资源紧张情况下运行OGG数据复制会对业务系统的性能带来不利影响。

ü  申请技术支持

如经过以上排查仍然无法排除内存相关问题，可以联系Oracle的支持工程师或在技术支持网站上填写SR，依据技术支持人员要求的步骤提供相关的信息，协助尽快完成问题界定和解决。

0GG的Replicat进程占用内存较大

1)        现象

目标端的Replicat进程有占用较大内存。

2)        原因分析

OGG的Replicat负责将队列文件中的数据读取出来然后投递到目标数据库，由于每个Replicat进程处理交易依次进行的，其占用的内存决定于队列中的交易大小。但是OGG的Replicat进程本身在申请到内存后，并不一定随着事务的commit立即释放，同Extract一样在系统资源较为充足时，其会试图保留一定时间，而发现系统资源紧张时又会释放掉部分资源。

默认情况下，OGG是严格按照源端产生的交易依次进行提交，本身不改变交易的边界，但是有时候为了避免大交易需要读取大量队列文件以及在目标端数据投递需要大量资源，OGG提供了MAXTRANSOPS参数用于将大交易拆分为较小的交易多次提交，除去性能的提升外还能让管理人员更为实时的看到数据投递的变化。例如：

MAXTRANSOPS 1000

表示如果单个交易中的实际数据变化量超过了1千，replicat会每1千条进行一次提交。由于OGG的队列中全部是提交了的交易，使用此参数后只是交易被拆分为了多个依次提交，并不改变数据变化的顺序，所以对一致性并不影响。

需要注意的是使用MAXTRANSOPS时，如果出现了系统异常如目标数据库宕机，有可能出现Replicat的检查点还处在交易开始点，但实际已经投递到大交易的中间某个点了，这样再次重启会报告一些数据错误。此时可以通过使用reperror default,discard将这些冲突数据写入discard文件，等待追上后再去验证这部分数据在两端是否一致，一般情况下不需要重新初始化，如有问题可以联系技术支持予以协助。

（说明：OGG的GROUPTRANSOPS参数会将小交易合并为大一些的交易进行提交，也会改变交易边界，但一般不对资源要求产生较大影响）

3)        排查方法与解决方案

一旦出现Replicat报告内存问题或出现异常，各网省可根据以下步骤进行排查和选择解决方案：

ü  排查操作系统对于内存的限制

在主机上使用ulimit –a查看OGG运行用户（一般为oracle）用户在操作系统级的资源允许状况，例如：

time(seconds)        unlimited

file(blocks)         unlimited

data(kbytes)         unlimited

stack (kbytes)        unlimited

memory(kbytes)       unlimited

coredump(blocks)     4194303

nofiles(descriptors) 15000

这些限制的配置一般在/etc/security/limits文件里，建议将其中的data/stack/memory都设置为unlimited(-1)，至少要保证该配置可以让OGG使用最大交易所允许的最大内存，可以联系系统管理员予以调整。

ü  对于大交易配置MAXTRANSOPS参数

当遇到较大交易时，OGG需要大量的时间读取所有交易数据信息，然后一次性投递到目标库。配置MAXTRANSOPS参数可以在遇到大交易时无需等待读完所有的交易数据再提交，能够提高性能的同时使监控人员在短时间内看到复制的进展。按照经验，一般MAXTRANSOPS配置为1000以下，如果处理的表列比较多或者列很长，可以设置为几百甚至几十。

MAXTRANSOPS 500

ü  尝试重启Replicat进程查看内存使用

OGG本身有自动调节资源占用的特性，即如果系统本身空闲，则其会自动申请更多资源加速数据复制；而如果系统资源紧张，则会释放部分资源给优先级更高的进程。

如果想尽快让Replicat进程内存释放，可以尝试重启进程，观察其内存占用是否正常。

ü  添加物理内存

如果系统日常业务繁忙阶段目标库现有物理内存占用率非常高，则建议对系统进行内存扩容满足复制的资源要求。

ü  申请技术支持

如经过以上排查仍然无法排除内存相关问题，可以联系Oracle的支持工程师或在技术支持网站上填写SR，依据技术支持人员要求的步骤提供相关的信息（有时需要打开进程的trace），协助尽快完成问题界定和解决。

关于handlecollisions的说明

1)        问题描述

前期国网部分网省使用了handlecollisions参数，希望能够了解该参数与数据一致性的关系。

2)        问题说明

在前期的文档和实施模板中，Oracle从未建议使用Handlecollisions参数。该参数的使用仅限于当所有表均有主键、且无法使用scn号进行一致的数据初始化时才可以使用，它可以根据主键对Extract抽取的时间点和备份之间点之间的数据重合进行自动的处理，例如忽略某些错误。所以，在正常复制过程中，如果打开了该参数，则会忽略error mapping数据错误，而且不会报告到discard文件，所以除非认定可以忽略这些数据不一致错误，否则绝对不建议使用handlecollisions参数！

Oracle始终建议第一选择是停机初始化，第二选择是使用rman或者带scn号的exp/imp做不停机的一致性初始化，这两种方法均不需要使用handlecollisions参数。

Discard掉的数据如何处理

1)        问题描述

对于某些replicat进程将不能正确复制的数据写入到了discard文件中，需要了解如何对这些discard掉的数据进行处理。

2)        问题说明

Oracle建议在replicat中设置错误处理为默认的出错即停的方式，即：

reperror default,abend

此种模式下，只要出错进程就会abend，然后监控人员可以根据报告文件和discard文件中的错误信息对错误进行定位，经修复后重启进程，如此可以保证两端数据的严格一致。

如果有的replicat将错误处理模式设置成了reperror default,discard模式，则会数据出错后只是将错误数据丢到discard文件里面，然后继续下面的处理。由于后继的数据复制还在继续，此时discard中丢失的数据已经无法被恢复，只能将discard文件中所有出错的表进行重新初始化，具体方法请参照《运维方案》第3.2节。

reperror default还有一个ignore模式，该模式是忽略所有错误继续运行，不会留下任何错误信息，一定不要使用！

 

生产端I/O性能问题

1)        问题描述

出现源系统I/O压力较大的情况，在此予以说明。

2)        问题说明

OGG对于源端的I/O压力主要体现在：

ü  主Extract进程对于数据库日志文件的轮询读；

ü  主Extract进程对于其检查点文件的定时写；

ü  主Extract对于本地队列的写；

ü  Data Pump对于本地队列的读；

根据调查和我们的经验， IO压力大的原因就在于配置了过多的主Extract进程，大量主Extract进程对于数据库日志文件的读造成系统IO压力过大。其解决方案包括：

3)        问题解决最佳方案

重新对OGG进行配置，减少extract的数量。一般主Extract的处理能力比较强，依据硬件平台不同每小时处理20-50G日志是没有问题的，所以一般只需配置1-3个主Extract.OGG数据复制的瓶颈主要在于目标端的replicat进程，可以在目标端对replicat进程进行拆分提高投递性能，但源端的Extract并不需要如此拆分。

4)        问题解决可选方案(效果可能有限)

可以通过对OGG的主Extract进程加大轮询日志间隔来降低IO占用:

EOFDELAY 5  //将轮询日志的时间设置为5秒，默认为1秒

CHECKPOINTSECS 20 //将写检查点的时间设置为20秒，默认为10秒

这两个参数对于data Pump同样有效。

注意调节这两个参数可能会使数据复制的延迟相应增大若干秒。

CSN取值问题

1)        问题描述

RMAN在线备份恢复方式进行数据库初始化，灾备端第一次启动rep进程的CSN采用归档文件最后的SCN号，但仍会有error mapping的报错？用导入导出的方式从新初始化某个表的话，该如何启动进程才能保证数据的一致性，停业务是不可能的？在map中修改某个表从某个csn开始抽取的话，如何去这个csn的值，是否是datafile_header中的？。

2)        说明

关于Rman初始化的步骤，可以参照我们的实施方案模板，里面有具体的操作步骤，包括如何去csn号，只要目标恢复到的scn号与replicat启动的scn号是一致的就不应该有数据冲突。但是需要排除以下可能导致数据修改的因素：

ü  数据库是否有内在的job在目标端运行；

ü  操作系统是否有定时任务在修改数据；

ü  目标数据库的trigger是否全部被禁用了；

ü  目标库的外键是否被全部禁用；

ü  建议锁定目标库的除OGG以外所有数据库用户，防止其修改数据。

等等，这些因素可能会导致目标本身数据发生变化，产生与源端数据变化的冲突。

两端数据不一致的排查与解决

现象

在执行数据对比过程中，部分网省的业务系统中发现有部分表在两端的记录是不一致的。

原因分析与排查

两端出现数据不一致的原因非常多，下面是对比结果有差异的一些可能性因素：

1)        数据复制本身的延时

由于源端数据可能一直在变化，而对比只能取当时时间的数据，两端取出来的数据有一定差异，所以有可能带来对比结果不一致。

此时并不一定是复制出现问题，可以针对这些不一致的记录做进一步的观察，过一段时间进行再确认。

2)        目标库数据库内部存在内部导致修改数据的对象和机制

可能包括数据库中的对象：如没有被禁止的trigger、自动运行的job等。

3)        操作系统上的job Scheduler

可能是存在操作系统上的job，可以检查其所有用户的crontab等自动任务管理器。

4)        OGG的错误处理模式设置

OGG的replicat里面的错误处理模式默认为是abend模式，即只要有数据问题进程就会出错结合监控告警：

REPERROR DEFAULT, ABEND

该参数的其它配置包括DISCARD和IGNORE模式。如果是discard模式，则出错会被写到discard文件里面，可以查找discardfile指定的该文件是否有出错记录；而如果是ignore模式则会忽略所有错误，而且不记日志。

请务必将Replicat错误处理机制设置为abend模式！仅仅在错误处理等特殊情况下配合技术支持使用DISCARD模式。

5)        修改OGG的检查点

人为修改OGG的检查点有可能带来数据不一致，包括使用alter命令修改主extract/data pump/replicat等。所有ggsci中对进程的操作记录都记录在ggserr.log里面，只要用户没有手工清除，可以通过对该文件进行分析观察是否修改过检查点。

6)        OGG配置的逻辑错误

主要包括以下配置复制关系时的错误：

ü  所有Extract表的复制范围必须是互补的，且互不交叉的，不能存在需要复制但不包含在任何一个主extract中的情况；

ü  Data Pump的复制范围必须和主Extract保持一致；

ü  Replicat的复制范围同样必须对应于主Extract和Data Pump的所有表，且负责相同队列的各Replicat之间互补和无交集；

7)        OGG配置参数的正确性

有时如果OGG的参数文件中语法问题也会造成数据不一致。例如：

ü  在Extract的table语法错误。正确语法：

table ggs1.tcustmer;

即table关键字+空格+schema.tablename+分号。

ü  Replicat的map语句出现错误。正确语法：

MAP ggs1.TCUSTMER, TARGET ggs2.TCUSTMER;

即map关键字 + 空格 + source_schema.source_tablename + 逗号 + 空格 + target关键字 + source_schema.source_tablename +分号。如果写错格式会导致OGG无法将正确数据投递到目标表。

ü  OGG的关键字前后、逗号前后建议加入空格（英文，一定不要用全拼），一行的开头不用。OGG有时会将中间没有空格的多个关键字连在一起视作一个字符串。

ü  不可使用word等格式化工具编辑OGG参数然后上传，可能会带来比如空格、换行等问题。

8)        其它可能导致数据不一致的因素

如人工误操作。为了减少类似可能出现的问题，建议在日常灾备运行状态下目标数据库disable除去OGG的用户之外的其它所有用户，等接管时再重新enable。

如果以上均没有问题，可以提供源库和目标库的以下资料，由技术支持进行分析：

ü  OGG的ggserr.log

ü  所有的报告文件

ü  丢失数据的大致操作时间

ü  丢失数据相关时段的归档日志

 

解决方案

根据不一致数据表的多少以及不一致数据的条数，可以采取以下方案：

1)        人工补足少量的数据

在确认只有部分表的若干条数据不一致后，可以使用手工方法对不一致的数据进行重新再同步，即从源端找出当前的值，覆盖目标表的相关记录。本方法只适用于不一致数据较少的情况，如从discard文件中可以找到有限的出错记录。

2)        执行部分表的初始化

当其中某些表不同步，而数据条数较多时，可以对该部分表执行重新初始化，具体步骤参见运维文档的第5.5节。

3)        全部重新初始化

当大部分表出现不一致的情况时，需要对全库执行重新初始化，可以按照安装实施文档的步骤执行，之前请务必保证安装实施文档中的步骤正确性，如有问题可以联系技术支持。

AIX  GGSCI无法运行

错误信息：

Cannot load ICU resource bundle ‘ggMessage‘, error code 2 - No such file or directory

Cannot load ICU resource bundle ‘ggMessage‘, error code 2 - No such file or directory

IOT/Abort trap (core dumped)

或者ggsci可以启动，但是运行任何命令都报上面的错误。

处理方法：通常使用已有的mount点安装GoldenGate，在mount时使用了并发CIO参数。新建文件系统，重新mount，作为GoldenGate安装目录。

错误信息：

$ ./ggsci

exec(): 0509-036 Cannot load program ggsci because of the following errors:

        0509-130 Symbol resolution failed for ggsci because:

        0509-136   Symbol _GetCatName__FiPCc (number 158) is not exported from dependent module /usr/lib/libC.a[ansi_64.o].

        0509-136   Symbol _Getnumpunct__FPCc (number 162) is not exported from dependent module /usr/lib/libC.a[ansi_64.o].

        0509-136   Symbol __ct__Q2_3std8_LocinfoFPCci (number 183) is not exported from dependent module /usr/lib/libC.a[ansi_64.o].

        0509-192 Examine .loader section symbols with the ‘dump -Tv‘ command.

原因是XLC是6.0版本，升级XLC版本到10.1以上，问题解决

HP-UX GGSCI无法运行

错误信息：core dumped

该问题只在HP-UX11.31上发现。

处理方法：环境变量设置问题，参见“1.1 操作系统环境变量”小节

错误信息：

aCC runtime: Use of "-mt" must be consistent during both compilation and linking.

IOT core dumped

该问题在HP-UX 11.23上发现，原因是没有C＋＋运行环境

On HP-UX 11.23 IA64, Oracle GoldenGate requires aCC: HP aC++/ANSI C B3910B

A.06.05 or newer aC++ libraries. PHSS_34041 or newer is required.

处理方法：安装补丁包

OGG-xxxxx错误代码

本节为ogg具体错误代码的问题处理方式

OGG-01296

错误信息：

WARNING OGG-01154  Oracle GoldenGate Delivery for Oracle, repyxb.prm:  SQL error 1403 mapping SGPM.P_SMS_SEND to SGPM.P_SMS_SEND.

WARNING OGG-01003  Oracle GoldenGate Delivery for Oracle, repyxb.prm:  Repositioning to rba 2509817 in seqno 1.

ERROR   OGG-01296  Oracle GoldenGate Delivery for Oracle, repyxb.prm:  Error mapping from SGPM.P_SMS_SEND to SGPM.P_SMS_SEND.

ERROR   OGG-01668  Oracle GoldenGate Delivery for Oracle, repyxb.prm:  PROCESS ABENDING.

原因分析：由于源端进行了表结构更改，没有通知目标端，导致此错误

处理方法：

1)        先确认两端表结构是否一致

2)        在源端查看附加日志是否enable

GGSCI>INFO TRANDATA schema.table_name

--返回应该是enable，如果不是，重新添加

GGSCI>ADD TRANDATA schema.table_name

3)        目标端数据库：触发器，约束，job等是否已经禁止

4)        查看discard文件（./dirrpt/xxx.dsc）中的相关描述

5)        使用logdump查看实际数据，分析原因

OGG-01154

错误信息：

2011-03-29 15:53:57  WARNING OGG-01154  Oracle GoldenGate Delivery for Oracle, repya.prm:  SQL error 14402 mapping EPMA.D_METER to E

PMA.D_METER OCI Error ORA-14402: updating partition key column would cause a partition change (status = 14402), SQL <UPDATE "EPMA"."D_METER" SET "PR_ORG" = :a1,"BELONG_DEPT" = :a2 WHERE "METER_ID" = :b0>.

处理方法：

SQLPLUS>alter table SCHEMA.TABLENAME enable row movement

OGG-01088

错误信息：

ERROR   OGG-01088  Oracle GoldenGate Delivery for Oracle, pms_rep1.prm:  malloc 2097152 bytes failed.

ERROR   OGG-01668  Oracle GoldenGate Delivery for Oracle, pms_rep1.prm:  PROCESS ABENDING.

处理方法：

1)        ulimit -a，验证操作系统对用户是否所有资源都是无限制，参见1.3小节。

2)        将进程进行拆分，拆分为多个进程。

3)        从support.oracle.com下载最新的补丁包，升级GoldenGate。

OGG-01224

错误信息：

ERROR OGG-01224 Oracle GoldenGate Manager for Oracle, mgr.prm: No buffer space available

ERROR OGG-01224  Oracle GoldenGate Capture for Oracle, dpema.prm:  TCP/IP error 9 (Bad fil e number).

处理方法：

修改mgr.prm，扩大动态端口范围，dynamicportlist 7840-7914

OGG-01031

错误信息：

ERROR   OGG-01031  There is a problem in network communication, a remote file problem, encryption keys for target and source do not match (if using ENCRYPT) or an unknown error. (Reply received is Expected 4 bytes, but got 0 bytes, in trail ./dirdat/t1000026, seqno 26, reading record trailer token at RBA 103637218).

2011-01-06 11:04:16  ERROR   OGG-01668  PROCESS ABENDING.

原因分析（1）：

可能是网络出现过故障，OGG源端的Data Pump进程与目标断了联系，目标端mgr为其启动的server进程一直还在运行，下次data pump重启时目标mgr会试图生成另外一个server进程，这样两个进程会争同一个队列文件。

处理方法：

是停掉源端的所有data pump，使用ps –ef|grep server（或OGG安装目录）看看是不是还有OGG的server进程在跑，如果有，杀死它（一定要确认源端data pump全停掉，并且杀的是server进程，不要杀其它extract/replicat/mgr等），重启源端data pump即可。

原因分析（2）：

可能是目标端的trail file出问题了，前滚重新生成一个新的队列文件

处理方法：

SEND EXTRACT xxx ROLLOVER

或者：

alter extract xxx etrollover

xxx为datapump的名称

OGG-01072

错误信息：

ERROR OGG-01072 LOBROW_get_next_chunk(LOBROW_row_t *, BOOL, BOOL, BOOL, LOBROW_chunk_header_t *, char *, size_t, BOOL, *) Buffer overflow, needed:132, alloc 2.

处理方法：

1)        如果版本为11.1.1.0.1 Build 078版本，升级到最新的补丁包

2)        使用ulimit –a查看资源使用限制，调整资源为unlimited

3)        extract: DBOPTIONS LOBBUFSIZE <bytes>

4)        replicat: DBOPTIONS LOBWRITESIZE 1MB

OGG-01476

错误信息：

ERROR   OGG-01476  The previous run abended due to an out of order transaction. Issue ALTER ETROLLOVER to advance the output trail sequence past the current trail sequence number, then restart. Then, use ALTER EXTSEQNO on the subsequent pump EXTRACT, or REPLICAT, process group to start reading from the new trail file created by ALTER ETROLLOVER; the downstream process will not automatically switch to the new trail file.

在初始化的时候，由于灾备端没有准备就绪，在生产端来回进行了很多次的操作，导致生产端抽取混乱，此时在进行RMAN之前，重新启动抽取，忽略调之前的混乱信息。

处理方法：

RAC环境，查看时钟是否同步

参数文件增加：

THREADOPTIONS MAXCOMMITPROPAGATIONDELAY 7000 IOLATENCY 7000

7000可以进行大小调整

如果还有问题：

alter extract xxx, etrollover

## 启动data pump进程后，datapump会报错，错误信息大致是进程当前的队列文件（假设是65）已经读完，但是找不到文件结尾标志，同时又发现新的队列文件（假设是66）已经生成。这个时候应该手工将datapump滚动到这个新的队列文件头（66）

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

stop [pump_name]

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

start [pump_name]

注：用实际的datapump进程名代替 [pump_name]，用新的队列文件号代替#####

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

##启动Replicat，观察其是否能够读取新传输过来的队列

##如Replicat无法自动滚动到下一个队列，需要通过命令手工滚动

stop [replicat_name]

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

start [replicat_name]

注：用实际的replicat进程名代替 [replicat_name]，用新的队列文件号代替#####

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

OGG-00850

错误信息：

ERROR   OGG-00850  Oracle GoldenGate Capture for DB2, extxa.prm:  Database instance XP1 has both USEREXIT and LOGRETAIN set to off.

ERROR   OGG-01668  Oracle GoldenGate Capture for DB2, extxa.prm:  PROCESS ABENDING.

处理方法：

如果是DB2 8.1/8.2，必须将USEREXIT和LOGRETAIN设置为ON。

如果是DB2 9.5，已经使用LOGARCHMETH1和LOGARCHMETH2代替以上两个参数，通常LOGARCHMETH1为DISK，LOGARCHMETH2为TSM，采用这两个参数开启归档模式。在DB2 9.5中，USEREXIT可以设置为OFF，但是LOGRETAIN仍需设置为ON。

因此LOGARCHMETH1需设置为LOGRETAIN，LOGARCHMETH2设置为OFF

经过现场测试：LOGARCHMETH1=TSM and LOGARCHMETH2=OFF 可以正常工作

OGG-01416

错误信息：

ERROR   OGG-01416  Oracle GoldenGate Capture for Oracle, dpeya.prm:  File ./dirdat/ya001542, with format RELEASE 9.0/9.5, does not match current format specification of RELEASE 10.4/11.1. Modify the parameter file to specify format RELEASE 9.0/9.5 or issue ETROLLOVER prior to restart.

2011-03-14 15:04:12  ERROR   OGG-01668  Oracle GoldenGate Capture for Oracle, dpeya.prm:  PROCESS ABENDING.

处理方法：

ALTER EXTRACT xxx etrollover

后续步骤参照OGG-01476进行处理。

## 启动data pump进程后，datapump会报错，错误信息大致是进程当前的队列文件（假设是65）已经读完，但是找不到文件结尾标志，同时又发现新的队列文件（假设是66）已经生成。这个时候应该手工将datapump滚动到这个新的队列文件头（66）

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

stop [pump_name]

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

start [pump_name]

注：用实际的datapump进程名代替 [pump_name]，用新的队列文件号代替#####

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

##启动Replicat，观察其是否能够读取新传输过来的队列

##如Replicat无法自动滚动到下一个队列，需要通过命令手工滚动

stop [replicat_name]

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

start [replicat_name]

 注：用实际的replicat进程名代替 [replicat_name]，用新的队列文件号代替#####

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

OGG-01028

错误信息：

"2011-03-15 16:18:21  ERROR   OGG-01028  Oracle GoldenGate Capture for Oracle, ext_rop1.prm:  failed to retrieve all chained row fragments for table ECMSADM.CMS_AMP_MOB_BELL_OC, record #19401, in transaction 34.165.3 (0x0022.0a5.00000003).  Position (24502, 39484028).2011-03-15 16:18:21 ERROR   OGG-01668  Oracle GoldenGate Capture for Oracle, ext_rop1.prm:  PROCESS ABENDING."Issue resembles Bug 9779752: EXTRACT ABEND WITH GGS ERROR 190  FAILED TO RETRIEVE ALL CHAINED ROW FRAGMENTS, which should have been fixed in version 10.

处理方法：

升级GoldenGate，Patch number 12418339

OGG-01027（长事务）

在extract中添加：

WARNLONGTRANS 2h,CHECKINTERVAL 3m

ggserr.log文件中会记录大事务警告

WARNING OGG-01027  Long Running Transaction: XID 82.4.242063, Items 0, Extract YX_EXT1, Redo Thread 1, SCN 2379.2132775890 (10219859973074), Redo Seq #5688, Redo RBA 195997712.

 

GGSCI> send extract xxx, showtrans [thread n] [count n]

thread n是可选的，表示只查看其中一个节点上的未提交交易；

count n也是可选的，表示只显示n条记录。

例如：查看xxx进程中节点1上最长的10个交易，可以通过下列命令：

GGSCI> send extract extsz , showtrans thread 1 count 10

记录XID，通过DBA查找具体的长交易执行的内容

GGSCI> SEND EXTRACT xxx, SKIPTRANS <82.4.242063> THREAD <2> //跳过交易

GGSCI>SEND EXTRACT xxx, FORCETRANS <82.4.242063> THREAD <1> //强制认为该交易已经提交

使用这些命令只会让GoldenGate进程跳过或者认为该交易已经提交，但并不改变数据库中的交易，他们依旧存在于数据库中。因此，强烈建议使用数据库中提交或者回滚交易而不是使用GoldenGate处理。

查找长事务对应的SQL语句：

XID由三部分组成：XIDUSN.XIDSLOT.XIDSQN

通过以下语句查找对应的SQL语句

select /*+ rule*/b.USERNAME,b.SCHEMANAME,b.OSUSER,b.MACHINE,c.SQL_TEXT

from v$transaction a, v$session b, v$sql c

where a.XIDUSN = 5

and a.XIDSLOT = 42

and a.XIDSQN = 1920

and a.ADDR = b.TADDR

and b.SQL_ADDRESS = c.ADDRESS

and b.SQL_HASH_VALUE = c.HASH_VALUE;

 

队列文件保存天数

在mgr.prm中，添加：

PURGEOLDEXTRACTS ./dirdat/*,usecheckpoints, minkeepdays 3

修改之后，必须重启manager即可看到队列文件占用的空间被按照上面指定的规则释放。

如果存储空间不够，可以将minkeepdays修改为MINKEEPHOURS

很多网省源端存储空间不足，这样修改为最小保留的小时数，缓解存储空间不足。

如果空间仍然紧张，仍要求立即释放空间，可修改为：MINKEEPFILES，将值设置为1，即只保留一个处理过的队列文件（不建议使用）。

如果存储空间充裕，建议最少保留3天的队列文件。

队列文件不自动清除

首先确认manager参数文件mgr.prm中是否添加了定期清除参数：

PURGEOLDEXTRACTS ./dirdat/*,usecheckpoints, minkeepdays 3

修改之后，必须重启manager即可看到队列文件占用的空间被按照上面指定的规则释放。

如果还是没有删除，通过：GGSCI>INFO XXX, SHOWCH，查看是否存在多个Write Checkpoint，一个为相对路径，一个为绝对路径

原因如下：

1)        源端：

在增加extract和datapump时，在GGSCI命令行指定的路径和参数文件中的不一致，如果在命令行使用绝对路径，在参数文件中必须使用绝对路径。如果使用了相对路径，则统一采用相对路径。

2)        目标端：

在GGSCI增加datapump时，RMTTRAIL如果使用了相对路径，在增加replicat时必须使用相对路径。

处理方法：

GGSCI>INFO XXX, SHOWCH

GGSCI>INFO XXX

记录相关信息，删除不正确路径的exttrail

通过alter命令设置为上面INFO信息记录的检查点

GGSCI>alter xxx extseqno INFO看到的序列号, extrba INFO看到的RBA号码, [thread n]

GGSCI>start xxx

3)        举例：

GGSCI > info exttrail *

 

       Extract Trail: /ggsfs/dirdat/cw

             Extract: DPECW

               Seqno: 0

                 RBA: 0

           File Size: 50M

       Extract Trail: ./dirdat/cw

             Extract: DPECW

               Seqno: 365

                 RBA: 8497768

           File Size: 10M

可以看到有两个路径，一个是相对路径./dirdat/cw，一个是绝对路径：/ggsfs/dirdat/cw

GGSCI > stop dpecw

Sending STOP request to EXTRACT DPECW ...

Request processed.

 

GGSCI > status dpecw

EXTRACT DPECW: STOPPED

 

GGSCI > info dpecw

EXTRACT    DPECW     Last Started 2011-03-23 11:03   Status STOPPED

Checkpoint Lag       00:00:00 (updated 00:00:09 ago)

Log Read Checkpoint  File /ggsfs/dirdat/cw000365

                     2011-04-07 14:10:01.000000  RBA 4558731

记录seqno：365和rba：4558731

GGSCI > stop extcw

Sending STOP request to EXTRACT EXTCW ...

Request processed.

GGSCI > info exttrail *

       Extract Trail: /ggsfs/dirdat/cw

             Extract: DPECW

               Seqno: 0

                 RBA: 0

           File Size: 50M

       Extract Trail: ./dirdat/cw

             Extract: DPECW

               Seqno: 365

                 RBA: 8497768

           File Size: 10M

 

       Extract Trail: /ggsfs/dirdat/cw

             Extract: EXTCW

               Seqno: 0

                 RBA: 0

           File Size: 50M

       Extract Trail: ./dirdat/cw

             Extract: EXTCW

               Seqno: 365

                 RBA: 4657905

           File Size: 10M

可以看到extcw和dpecw都存在问题

删除多余的exttrail

GGSCI > delete exttrail /ggsfs/dirdat/cw

Deleting extract trail /ggsfs/dirdat/cw for extract DPECW

Deleting extract trail /ggsfs/dirdat/cw for extract EXTCW

GGSCI > info exttrail *

       Extract Trail: ./dirdat/cw

             Extract: DPECW

               Seqno: 365

                 RBA: 8497768

           File Size: 10M

       Extract Trail: ./dirdat/cw

             Extract: EXTCW

               Seqno: 365

                 RBA: 4657905

           File Size: 10M

确认已经正常

GGSCI > info extcw

EXTRACT    EXTCW     Last Started 2011-04-07 14:16   Status RUNNING

Checkpoint Lag       00:00:58 (updated 00:00:07 ago)

Log Read Checkpoint  Oracle Redo Logs

                     2011-04-07 14:15:30  Seqno 10726, RBA 151756800

确认和之前info extcw时的信息一致，启动extcw

GGSCI (ora5502) 18> start extcw

Sending START request to MANAGER ...

EXTRACT EXTCW starting

GGSCI > info dpecw

 

EXTRACT    DPECW     Initialized   2011-03-23 11:03   Status STOPPED

Checkpoint Lag       00:00:00 (updated 00:02:19 ago)

Log Read Checkpoint  File /ggsfs/dirdat/cw000365

                     2011-04-07 14:10:01.000000  RBA 4558731

 

GGSCI > alter dpecw, exttrailsource ./dirdat/cw

EXTRACT altered.

 

GGSCI > info dpecw

 

EXTRACT    DPECW     Initialized   2011-04-07 14:17   Status STOPPED

Checkpoint Lag       00:00:00 (updated 00:00:03 ago)

Log Read Checkpoint  File ./dirdat/cw000000

                     First Record  RBA 0

 

GGSCI> alter dpecw, extseqno 365, extrba 4558731

EXTRACT altered.

 

GGSCI> info dpecw

EXTRACT    DPECW     Initialized   2011-04-07 14:17   Status STOPPED

Checkpoint Lag       00:00:00 (updated 00:00:03 ago)

Log Read Checkpoint  File ./dirdat/cw000365

                     First Record  RBA 4558731

 

GGSCI> start dpecw

Sending START request to MANAGER ...

EXTRACT DPECW starting

GGSCI (ora5502) 31> info dpecw

EXTRACT    DPECW     Last Started 2011-04-07 14:18   Status RUNNING

Checkpoint Lag       00:00:00 (updated 00:00:29 ago)

Log Read Checkpoint  File ./dirdat/cw000365

                     First Record  RBA 4558731

 

复制进程拆分及指定队列文件及RBA

拆分前通过INFO XXX获取队列文件信息及RBA号，返回样例如下：

GGSCI> INFO REPYXA

REPLICAT   REPYXA    Last Started 2011-01-08 19:48   Status RUNNING

Checkpoint Lag       00:00:00 (updated 00:01:42 ago)

Log Read Checkpoint  File ./dirdat/p1000556 First Record  RBA 59193235

在将replicat进程拆分后，指定从拆分前的队列文件及RBA号码开始复制。

ALTER REPLICAT xxx EXTSEQNO nnn, EXTRBA mmm

以上面的为例：

ALTER REPLICAT REPYXA 556, EXTRBA 59193235

 

BOUNDED RECOVERY

错误信息：

BOUNDED RECOVERY: reset to initial or altered checkpoint.

数据库问题，不能读取第2个节点的archivelog文件

 

排除不复制的表

在参数文件中增加：

TABLEEXCLUDE schema.table_name

 

从指定时间重新抓取

重新抓取数据前提：归档文件没有删除

ALTER EXTRACT xxx, TRANLOG, BEGIN 2010-12-31 08:00

时间格式：yyyy-mm-dd [hh:mi:[ss[.cccccc]]]

如果是新建：

ADD EXTRACT xxx, TRANLOG, BEGIN 2010-12-31 08:00

 

进程无法停止

通常情况是在处理大交易，尤其在营销系统中有很多超过2小时以上的大交易，建议等待进程处理完毕。

处理方法：如果必须停止进程，可以强制杀死进程：

send xxx forcestop

 

CLOB处理

如果包含CLOB字段，在extract 参数文件中必须添加：

TRANLOGOPTIONS CONVERTUCS2CLOBS

 

DB2不能使用checkpoint table

处理方法：在增加replicat进程时使用nodbcheckpoint参数：

add replicat xxx, exttrail /goldengate/dirdat/rb, nodbcheckpoint

 

 

Datapump进程每次只传一个文件

错误信息：

Datapump进程每次只传一个文件，然后就不工作了，状态是Running，重启之后，开始传下一个文件，需要不断重启才行

原因：AIX使用裸设备，没有添加参数。

处理方法：原来只是要求在extract中添加，在datapump中也需要添加

TRANLOGOPTIONS rawdeviceoffset 0

很多HP-UX出现不向目标端传输文件，是因为错误设置了上面的参数，将该参数从参数文件中删除即可。如果不是AIX使用裸设备，不要设置该参数。

Extract进程产生core文件

错误信息：extract运行一段时间，状态是running，但是不工作，在安装目录产生core文件，大约200M

原因：AIX没有使用裸设备，但是在参数文件中写了裸设备的参数

TRANLOGOPTIONS rawdeviceoffset 0

处理方法：将该参数删除

中文字节数问题

错误信息：

2011-01-19 22:58:30  WARNING OGG-00869  OCI Error ORA-12899: value too large for column "SAPR3"."ADRC"."MC_STREET" (actual: 86, maximum: 75) (status = 12899), SQL <INSERT INTO "SAPR3"."ADRC" ("CLIENT","ADDRNUMBER","DATE_FROM","NATION","DATE_TO","TITLE","NAME1","NA
ME2","NAME3","NAME4","NAME_TEXT","NAME_CO","CITY1","CITY2","CITY_CODE","CITYP_CODE","HOME_CITY","CIT>.

2011-01-19 22:58:30  WARNING OGG-01004  Aborted grouped transaction on ‘SAPR3.ADRC‘, Database error 12899 (ORA-12899: value too large for column "SAPR3"."ADRC"."MC_STREET" (actual: 86, maximum: 75)).

2011-01-19 22:58:30  WARNING OGG-01003  Repositioning to rba 15479755 in seqno 11.

2011-01-19 22:58:30  WARNING OGG-01154  SQL error 12899 mapping SAPR3.ADRC to SAPR3.ADRC OCI Error ORA-12899: value too large for column "SAPR3"."ADRC"."MC_STREET" (actual: 86, maximum: 75) (status = 12899), SQL <INSERT INTO "SAPR3"."ADRC" ("CLIENT","ADDRNUMBER","DATE_FROM","NATION","DATE_TO","TITLE","NAME1","NAME2","NAME3","NAME4","NAME_TEXT","NAME_CO","CITY1","CITY2","CITY_CODE","CITYP_CODE","HOME_CITY","CIT>.

2011-01-19 22:58:30  WARNING OGG-01003  Repositioning to rba 15479755 in seqno 11.

原因：中文字符问题，源端每个中文字符占2个字节，目标端每个占3个字节，

处理方法：SR 3-2456706611

首先确认参数文件中的NLS_LANG和数据库设置一致。

1)        确认两个数据库的字符语义相同

参考SQL:

SQL> show parameter nls

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

nls_language                         string      AMERICAN

nls_length_semantics                 string      BYTE

nls_territory                        string      AMERICA

2)        确认两端源和目标表的结构相同

参考SQL:

Select dbms_metadata.get_ddl(‘TABLE‘,‘#MyTable‘,‘My Owner‘) from dual;

3)        确认两端源和目标表的出错列的字符语义相同。

参考SQL：

select CHAR_USED,CHAR_LENGTH from dba_tab_columns where owner=‘WHETC‘ and table_name=‘CBS_RUNNINGNUMBER_NOBU‘ and column_name in (‘CPSBBZ‘, ‘XCFX‘);

4)        确认操作系统环境变量

确保两端操作系统级别，语言环境变量一致，包括：LANG，NLS_LANG等

 

中文表/中文字段处理

create table 测试表(

ID NUMBER,

姓名 VARCHAR2(30),

FLAG CHAR(1),

CONSTRAINT PK_TESTD PRIMARY KEY (ID) USING INDEX);

 

--源端创建MV LOG和MV：

drop materialized view log on "测试表";

create materialized view log on "测试表" with primary key;

drop materialized view mv_cn_table;

create materialized view mv_cn_table refresh fast on commit as select id,姓名 as en_name,flag from "测试表";

 

--目标端创建表及view

create or replace view v_cn_table as select id,姓名 as en_name,flag  from 测试表;

 

--这里NLS_LANG在GG中，抽取和复制必须设置为和目标字符集一致

SETENV (NLS_LANG = "AMERICAN_AMERICA.AL32UTF8")

 

--Extract

extract ODISC

SETENV (NLS_LANG = "AMERICAN_AMERICA.AL32UTF8")

userid custom_src, password custom_src

exttrail D:/goldengate/dirdat/ODISoc/oc

TABLE CUSTOM_SRC.MV_CN_TABLE;

--Datapump

extract ODIT1P

SETENV (NLS_LANG = "AMERICAN_AMERICA.AL32UTF8")

PASSTHRU

rmthost localhost, mgrport 7909

rmttrail D:/gg_stg/dirdat/ODIT1op/op

TABLE CUSTOM_SRC.MV_CN_TABLE;

 

--Replicat

replicat ODIT1A1

SETENV (NLS_LANG = "AMERICAN_AMERICA.AL32UTF8")

userid odi_staging,  password odi_staging

discardfile D:/gg_stg/dirrpt/ODIT1.dsc, purge

ASSUMETARGETDEFS

--这里必须指定此参数，否则update有问题

APPLYNOOPUPDATES

--这里必须指定KEYCOLS，否则删除和更新有问题

map CUSTOM_SRC.MV_CN_TABLE, TARGET ODI_STAGING.V_CN_TABLE, KEYCOLS (ID);