goldengate日常操作

2.4 OGG日常监控
2.4.1 OGG常用监控命令
.4.1.1 启动GoldenGate进程
1) 首先以启动GoldenGate进程的系统用户（一般为oracle）登录源系统。
2) 进入GoldenGate安装目录，执行./ggsci进入命令行模式。
3) 启动源端管理进程GGSCI > start mgr
4) 同样登陆到目标端GoldenGate安装目录，执行./ggsci，然后执行GGSCI > start mgr启动管理进程。
5) 在源端执行GGSCI > start er *启动所有进程
6) 同样登录到备份端执行GGSCI > start er *启动所有进程
7) 使用GGSCI > info er * 或者 GGSCI > info <进程名>察看进程状态是否为Running（表示已经启动）。注意有的进程需要几分钟起来，请重复命令观察其启动状态。
说明：无论源还是目标，启动各extract/replicat进程前需要启动mgr进程。
8) start 命令的一般用法是：
? start <进程名称>如：GGSCI> start extdm 启动一个名叫extdm的进程；
? 也可以使用通配符，如：GGSCI> start er * 启动所有的extract和replicat进程；GGSCI> start extract *d* 启动所有的包含字符‘d’extract进程；
? GGSCI> start replicat rep* 启动所有以“rep“开头的replicat进程
2.4.1.2 停止GoldenGate进程
依照以下步骤停止GoldenGate进程：
1) 以启动GoldenGate进程的系统用户（一般为oracle）登录源主机，进入GoldenGate安装目录执行./ggsci进入命令行管理界面
2) (**注：本步骤仅针对抽取日志的主extract进程， data pump进程和replicat进程不需要本步骤) 验证GoldenGate的抽取进程重起所需的日志存在，对各个主extXX进程，执行如下命令：
ggsci> info extXX, showch
…..
Read Checkpoint #1
….

Recovery Checkpoint (position of oldest unprocessed transaction in the data source):
Thread #: 1
Sequence #: 9671
RBA: 239077904
Timestamp: 2008-05-20 11:39:07.000000
SCN: 2195.1048654191
Redo File: Not available

Current Checkpoint (position of last record read in the data source):
Thread #: 1
Sequence #: 9671
RBA: 239377476
Timestamp: 2008-05-20 11:39:10.000000
SCN: 2195.1048654339
Redo File: Not Available

Read Checkpoint #2
…..

Recovery Checkpoint (position of oldest unprocessed transaction in the data source):
Thread #: 2
Sequence #: 5287
RBA: 131154160
Timestamp: 2008-05-20 11:37:42.000000
SCN: 2195.1048640151
Redo File: /dev/rredo07

Current Checkpoint (position of last record read in the data source):
Thread #: 2
Sequence #: 5287
RBA: 138594492
Timestamp: 2008-05-20 11:39:14.000000
SCN: 2195.1048654739
Redo File: /dev/rredo07

…..
首先察看Recovery Checkpoint所需要读取的最古老日志序列号，如举例中的实例1需要日志9671及其以后所有归档日志，实例2需要序列号为5287及以后所有归档日志，确认这些归档日志存在于归档日志目录后才可以执

行下一步重起。如果这些日志已经被删除，则下次重新启动需要先恢复归档日志。注意：对于OGG 11及以后版本新增了自动缓存长交易的功能，缺省每隔4小时自动对未提交交易缓存到本地硬盘，这样只需要最多8个小时归档日志即可。但是缓存长交易操作只在extract运行时有效，停止后不会再缓存，此时所需归档日志最少为8个小时加上停机时间，一般为了保险起见建议确保重启时要保留有12个小时加上停机时间的归档日志。
1) 执行GGSCI >stop er *停止所有源进程，或者分别对各个进程执行stop <进程名>单独停止。
2) 以oracle用户登录目标系统，进入安装目录/oraclelog1/goldengate，执行./ggsci进入命令行。
3) 在目标系统执行stop er *停止复制
4) 在两端进程都已停止的情况下,如需要可通过stop mgr停止各系统内的管理进程。
类似的，stop命令具有跟start命令一样的用法。这里不再赘述。
注意，如果是只修改抽取或者复制进程参数，则不需要停止MGR。不要轻易停止MGR进程，并且慎重使用通配符er *， 以免对其他复制进程造成不利影响。
2.4.1.4 查看参数设置
使用view params <进程名> 可以查看进程的参数设置。该命令同样支持通配符*。

2.4.1.5 查看进程状态
使用info <进程名称> 命令可以查看进程信息。可以查看到的信息包括进程状态、checkpoint信息、延时等。如：
还可以使用info <进程名称> detail 命令查看更详细的信息。包括所使用的trail文件，参数文件、报告文件、警告日志的位置等。如：
使用info <进程名称> showch 命令可以查看到详细的关于checkpoint的信息，用于查看GoldenGate进程处理过的事务记录。其中比较重要的是extract进程的recovery checkpoint，它表示源数据中最早的未被处理的事务；通过recovery checkpoint可以查看到该事务的redo log位于哪个日志文件以及该日志文件的序列号。所有序列号比它大的日志文件，均需要保留。

2.4.1.6 查看延时
GGSCI> lag <进程名称> 可以查看详细的延时信息。如：
2.4.1.7 查看统计信息
GGSCI> stats <进程名称>,<时间频度>,table <owner name>.<table name> 可以查看进程处理的记录数。该报告会详细的列出处理的类型和记录数。如：
GGSCI> stats edr, total列出自进程启动以来处理的所有记录数。
GGSCI> stats edr, daily, table gg.test列出当天以来处理的有关gg.test表的所有记录数。
2.4.1.8 查看运行报告
GGSCI> view report <进程名称> 可以查看运行报告。如：
也可以进入到 <GoldenGate安装目录>/dirrpt/目录下，
查看对应的报告文件。2.4.2 Logdump使用指引
1) 在GGSCI

中使用如下命令查看当前处理的队列文件和RBA号，例如：
GGSCI > info REPYXA
2) 在GoldenGate安装目录执行logdump
命令
3) 打开要查看的队列文件
Logdump >open ./dirdat/p1000556
Current LogTrail is ./dirdat/p1000556
Logdump >ghdr on
Logdump >detail on
Logdump >detail data
Logdump >usertoken on
Logdump >pos 59193235 上面INFO命令看到的RBA号码
Logdump >n
输入n显示当前处理的表及相关操作
再次输入n，显示下一条记录，如果要跳过当前记录，方法如下：
GGSCI>alter REPYXA extseqno 556, extrba 上面再次输入n看到的下一个RBA号，其中556为上面INFO看到的队列文件，0之后的数字
4) 打开下一个队列文件
Logdump >NEXTTRAIL
5) 使用logdump查看SCN号
Logdump >ggstoken detail
只有在事务开始的RBA号，才记录对应的SCN号和Transaction ID，示例如下：

上图显示SCN号：4024322，TRANID:6.38.1600
如果进程出现问题，可以找到在处理那个事务时出现问题，修改进程提前到该事务之前的时间点进行重新抽取，然后从找到的SCN号启动replicat进程，例如：
GGSCI> start rep_xxx ATCSN 4024332
6) 使用COUNT
统计队列文件中包含的记录条数
按时间点统计
Logdump> COUNT START 2006-01-11 12:00:00 , END 2006-01-12 12:00:00
统计ls开头的每个队列文件包含的条数
Logdump> COUNT LOG ls*
Logdump> COUNT DETAIL
Logdump>
7) 使用Filter
Logdump> FILTER INCLUDE FILENAME Schema.table_name
Logdump>COUNT
查看队列文件中，包含该表的记录条数
Logdump> FILTER INCLUDE TRANSIND <> 1
0 = start of transaction
1 = middle of transaction
2 = end of transaction
3 = only record in transaction
可以统计队列文件中的事务，可以利用该命令查找事务开始点，如果没有开始的事务，直接找上一个文件即可。


2.5 OGG日常运维任务
2.5.1 配置自动删除队列
1) 进入安装目录执行./ggsci；
2) 执行edit param mgr编辑管理进程参数，加入或修改以下行
purgeoldextracts /<goldengate安装目录>/dirdat/*, usecheckpoint, minkeepdays 7
其中，第一个参数为队列位置，*可匹配备份中心所有队列文件；
第二个参数表示是首先要保证满足检查点需要，不能删除未处理队列；
第三个参数表示最小保留多少天，后面的数字为天数。例如，如果希望只保留队列/ggs/dirdat/xm文件3天，可以配置如下：
purgeoldextracts /ggs/dirdat/xm, usecheckpoint, minkeepdays 3
3) 停止MGR进程，修改好参数后重启该进程
GGSCI > stop mgr
GGSCI > start mgr
注：临时停止mgr进程并不影响数据复制。

2.5.2 配置启动MGR时自动启动Extract和Replicat进程
1) 进入安装目录执行./ggsci；
2) 执行edit param mgr编辑管理进程参数，加入以下行
AUTOSTART ER

*
3) 停止MGR进程，修改好参数后重启该进程
GGSCI > stop mgr
GGSCI > start mgr
注意：一般建议不用自动启动，而是手工启动，便于观察状态验证启动是否成功，同时也便于手工修改参数。

2.5.3 配置MGR自
动重新启动Extract和Replicat进程
GoldenGate具有自动重起extract或者replicat进程的功能，能够自动恢复如网络中断、数据库临时挂起等引起的错误，在系统恢复后自动重起相关进程，无需人工介入。
1) 进入安装目录执行ggsci进入命令行界面；
2) 执行edit param mgr编辑管理进程参数，加入以下行
AUTORESTART ER *, RETRIES 3, WAITMINUTES 5, RESETMINUTES 60
以上参数表示每5分钟尝试重新启动所有进程，共尝试三次。以后每60分钟清零，再按照每5分钟尝试一次共试3次。
3) 停止MGR进程，修改好参数后重启该进程，使修改后的参数文件生效
GGSCI > stop mgr
GGSCI > start mgr

2.5.4 长事务管理
在停止抽取进程前需要通过命令检查是否存在长交易，以防止下次启动无法找到归档日志：
ggsci> info extXX, showch
2.5.4.1 查看长交易的方法
Ggsci> send extract <进程名> , showtrans [thread n] [count n]
其中，<进程名>为所要察看的进程名，如extsz/extxm/extjx等；
Thread n是可选的，表示只查看其中一个节点上的未提交交易；
Count n也是可选的，表示只显示n条记录。例如,查看extsz进程中节点1上最长的10个交易，可以通过下列命令：
Ggsci> send extract extsz , showtrans thread 1 count 10
输出结果是以时间降序排列的所有未提交交易列表，通过xid可以查找到对应的事务，请应用开发商和DBA帮助可以查找出未提交原因，通过数据库予以提交或者回滚后GoldenGate的checkpoint会自动向前滚动。
2.5.4.2 使用GoldenGate命令跳过或接受长交易的方法
在GoldenGate中强制提交或者回滚指定事务，可以通过以下命令（<>中的为参数）：
Ggsci> SEND EXTRACT <进程名>, SKIPTRANS <5.17.27634> THREAD <2> //跳过交易
Ggsci>SEND EXTRACT <进程名>, FORCETRANS <5.17.27634> THREAD <1> //强制认为该交易已经提交
说明：使用这些命令只会让GoldenGate进程跳过或者认为该交易已经提交，但并不改变数据库中的交易，他们依旧存在于数据库中。因此，强烈建议使用数据库中提交或者回滚交易而不是使用GoldenGate处理。
2.5.4.3 配置长交易告警
可以在extract进程中配置长交易告警，参数如下所示：
extract extsz
……
warnlongtrans 12h, checkintervals 10m
exttrail /backup/goldengate/dirdat/sz
….
以上表示GoldenGate会每隔10分钟检查一下长交易，如果有超过12个小时的长交易，GoldenGate会在根目录下的ggserr.log

里面加入一条告警信息。可以通过察看ggserr.log或者在ggsci中执行view ggsevt命令查看这些告警信息。以上配置可以有助于及时发现长交易并予以处理。
说明：在OGG 11g中，extract提供了BR参数可以设置每隔一段时间（默认4小时）将长交易缓存到本地硬盘（默认dirtmp目录下），因此extract只要不停止一般需要的
归档日志不超过8个小时（极限情况）。但是如果extract停掉后，便无法再自动缓存长交易，需要的归档日志就会依赖于停机时间变长。

2.5.9 Trace收集方法
1) GoldenGate在出现问题时，在Support网站创建SR之后，研发部门会要求收集相关的trace文件，并上传到https://www.360docs.net/doc/7e14801135.html,网站。trace收集方法如下：
2) 根据进程名称将下面的xml文件改名，命名格式为：gglog-XXX.xml，例如：gglog-EXTYB.xml
3) 将该文件拷贝到GoldenGate安装目录
4) 注释掉manager参数文件中的AUTOSTART和AUTORESTART
5) 启动出现错误的进程：GGSCI>strat XXX
6) 运行直至进程abend
7) 拷贝产生的log文件、dmp文件、ggserr.log、dirrpt目录并上传到https://www.360docs.net/doc/7e14801135.html,


4 OGG性能优化方法
从根本上讲，OGG复制性能和要复制的表是否存在主键和唯一索引有很大关系，所以从应用系统开发商对表结构的规范更为有效，请参见“2 国网应用系统开发规范”。
OGG调优通常采用拆分进行的方式，拆分方法如下所述。
4.1 Extract拆分方法
1) 停止extract进程
2) 停止datapump、进程
GGSCI> INFO datapump_name
EXTRACT DPEF Last Started 2011-01-28 12:34 Status RUNNING
Checkpoint Lag 00:00:00 (updated 00:00:05 ago)
Log Read Checkpoint File ./dirdat/ef000010
2011-01-28 12:47:45.000000 RBA 148645
直至RBA号不变化，才能停止
3) 停止replicat进程
GGSCI> INFO replicat_name
REPLICAT RPEF Last Started 2011-01-28 12:30 Status RUNNING
Checkpoint Lag 00:00:00 (updated 00:00:05 ago)
Log Read Checkpoint File ./dirdat/ef000006
2011-01-28 12:47:45.000000 RBA 149258
直至RBA号不变化，才能停止
4) 记录extract检查点
Extract检查点包括：Recovery Checkpoint和Current Checkpoint
GGSCI> INFO extract_name, SHOWCH
EXTRACT EXEE Last Started 2011-01-28 09:58 Status STOPPED
Checkpoint Lag 00:00:00 (updated 00:01:02 ago)
Log Read Checkpoint Oracle Redo Logs
2011-01-28 10:02:16 Seqno 26, RBA 7090688
Current Checkpoint Detail:

Read Checkpoint #1

Oracle Redo Log

Startup Checkpoint (starting position in the data source):
Sequence #: 26
RBA: 289296
Timestamp: 2011-01-28 09:27:31.000000
Redo File: C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02.LOG

Recovery Checkpoint (position of oldest unprocessed transaction in the data source):
Sequence #: 26
RBA: 7088144
Timestamp: 2011-01-28 10:02:16.000000
Redo File: C:\ORACLE\PRODUCT\10.2

.0\ORADATA\ORCL\REDO02.LOG

Current Checkpoint (position of last record read in the data source):
Sequence #: 26
RBA: 7090688
Timestamp: 2011-01-28 10:02:16.000000
Redo File: C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02.LOG

Write Checkpoint #1

GGS Log Trail

Current Checkpoint (current write position):
Sequence #: 11

RBA: 31609
Timestamp: 2011-01-28 10:02:19.072000
Extract Trail: ./dirdat/ee

Header:
Version = 2
Record Source = A
Type = 4
# Input Checkpoints = 1
# Output Checkpoints = 1

File Information:
Block Size = 2048
Max Blocks = 100
Record Length = 2048
Current Offset = 0

Configuration:
Data Source = 3
Transaction Integrity = 1
Task Type = 0

Status:
Start Time = 2011-01-28 09:58:34
Last Update Time = 2011-01-28 10:02:19
Stop Status = G
Last Result = 400

5) 修改原有相应的参数文件，将拆分出的表从参数文件中删除
6) 增加新的extract，datapump和replicat
--source--------------------------------------------------
GGSCI (win2k364) 15> add ext exef, tranlog, begin now

GGSCI (win2k364) 16> add exttrail ./dirdat/ef, ext exef, megabytes 50

GGSCI (win2k364) 17> add ext dpef, exttrailsource ./dirdat/ef

GGSCI (win2k364) 18> add rmttrail ./dirdat/ef, ext dpef, megabytes 50

--target--------------------------------------------------
GGSCI (win2k364) 21> add rep rpef, exttrail ./dirdat/ef

7) 修改新增extract进程的检查点
检查点为上面记录的两个检查点：
current read checkpoint and recovery checkpoint
--修改current read checkpoint
GGSCI (win2k364) 30> alter exef extseqno 26, extrba 7090688 [, thread n]
EXTRACT altered.
--修改recovery checkpoint


GGSCI (win2k364) 4> alter exef ioextseqno 26, ioextrba 7088144 [, thread n]

2011-01-28 10:46:18 INFO OGG-00989 WARNING: Unsupported operation. This might cause transactional inconsistency. Modifying iocheckpoint: ioseq = 26 iorba = 7088144.
Are you sure you want to continue? y
EXTRACT altered.

8) 确认所有参数文件正确，启动进程即可

4.2 Datapump和replicat拆分方法
下面以拆分replicat为例，datapump拆分方法相同。
1) 停止replicat进程
2) 查看检查点
GGSCI> INFO replicat_name, SHOWCH
3) 修改原有参数文件，将拆分出的表删除
4) 新增replicat，和拆分前的进程读取相同的队列文件
5) 修改检查点
6) GGSCI>alter replicat_new extseqno 6, extrba 149258
7) 确认所有参数文件无误，启动进程即可


5 OGG异常处理预案
5.1 异常处理一般步骤
如果GoldenGate复制出现异常，可以通过以下步骤尝试解决问题：
1) 通过ggsci>view report命令查找ERROR字样，确定错误原因并根据其信息进行排除；
2) 通过ggsci>view ggsevt查看告警日志信息；
3) 检查两端数据库是否正常运行，网络是否连通；
4) 如不能确定错误原因，则可以寻求O

racle技术支持。在寻求技术支持时一般需要提供以下信息：
? 错误描述
? 进程报告，位于dirrpt下以大写进程名字开头，以.rpt结尾，如进程名叫extsz，则报告名字叫EXTSZ.rpt；
? GGS日志ggserr.log，位于GGS主目录下；
? 丢失数据报告，在复制进程的参数disardfile中定义，一般结尾为.dsc；
? 当前
队列，位于dirdat下。
5.2 网络故障
如果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分钟，然后重新试三次。

5.3 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 *启动所有进程；
检查各进程是否正常启动，即可进入正常复制。以上过程可以通过集成到CRS或HACMP等集群软件实现自动的切换，具体步骤请参照国网测试文档。
5.4 Extract进程常见异常
对于源数据库，抽取进程extxm如果变为abended，则可以通过在ggsci中使用view report命令察看报告，可以通过搜索ERROR快速定位错误。
一般情况下，抽取异常的原因是因为其无法找到对应的归档日志，可以通过到归档日志目录命令行下执行

ls –lt arch_X_XXXXX.arc
察看该日志是否存在，如不存在则可能的原因是：
1) 日志已经被压缩
GoldenGate无法自动解压缩，需要人工解压缩后才能读取。
2) 日志已经被删除
如果日志已经被删除，需要进行恢复才能继续复制，请联系本单位DBA执行恢复归档日志操作。
一般需要定期备份归档日志，并清除旧的归档日志。需要保证归档日
志在归档目录中保留足够长时间之后，才能被备份和清除。即：定期备份清除若干小时之前的归档，而不是全部归档。保留时间计算如下：
某归档文件保留时间≥抽取进程处理完该文件中所有日志所需的时间
可以通过命令行或者GoldenGate Director Web界面，运行info exXX showch命令查看抓取进程exXX处理到哪条日志序列号。在此序列号之前的归档，都可以被安全的清除。如下图所示：


5.5 Replicat进程常见异常
对于目标数据库，投递进程repXX如果变为abended，则可以通过在ggsci中使用view report命令察看报告，可以通过搜索ERROR快速定位错误。
复制进程的错误通常为目标数据库错误，比如：
1) 数据库临时停机；
2) 目标表空间存储空间不够；
3) 目标表出现不一致。
可以根据报告查看错误原因，排除后重新启动rep进程即可。
需要注意一点：往往容易忽略UNDO表空间。如果DML语句中包含了大量的update和delete操作，则目标端undo的生成速度会很快，有可能填满UNDO表空间。因此需要经常检查UNDO表空间的大小。
5.6 抽取生成的队列文件比归档文件多
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所在位置的磁盘使用率，一旦到达即报警，交由相应人员改变保存队列策略或人工处理。
5.7 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，依据技术支持人员要求的步骤提供相关的信息，协助尽快完成问题界定和解决。
5.8 OGG的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），协助尽快完成问题界定和解决。
5.9 关于handlecollisions的说明
1) 问题描述
前期国网部分网省使用了handlecollisions参数，希望能够了解该参数与数据一致性的关系。
2) 问题说明
在前期的文档和实施模板中，Oracle从未建议使用Handlecollisions参数。该参数的使用仅限于当所有表均有主键、且无法使用scn号进行一致的数据初始化时才
可以使用，它可以根据主键对Extract抽取的时间点和备份之间点之间的数据重合进行自动的处理，例如忽略某些错误。所以，在正常复制过程中，如果打开了该参数，则会忽略error mapping数据错误，而且不会报告到discard文件，所以除非认定可以忽略这些数据不一致错误，否则绝对不建议使用handlecollisions参数！
Oracle始终建议第一选择是停机初始化，第二选择是使用rman或者带scn号的exp/imp做不停机的一致性初始化，这两种方法均不需要使用handlecollisions参数，具体方法请参照Oracle提供的模板文档《xx省Oracle数据复制实施方案》。
5.10 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模式，该模式是忽略所有错误继续运行，不会留下任何错误信息，一定不要使用！

5.11 生产端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同样有效，关于这两个参数的更多信息可以参考OGG的参考手册。
注意调节这两个参数可能会使数据复制的延迟相应增大若干秒。


5.12 CSN取值问题
1) 问题描述
RMAN在线备份恢复方式进行数据库初始化，容灾端第一次启动rep进程的CSN采用归档文件最后的SCN号，但仍会有error mapping的报错？用导入导出的方式从新初始化某个表的话，该如何启动进程才能保证数据的一致性，停业务是不可能的？在map中修改某个表从某个csn开始抽取的话，如何去这个csn的值，是否是datafile_header中的？。
2) 说明
关于Rman初始化的步骤，可以参照我们的实施方案模板，里面有具体的操作步骤，包括如何去csn号，只要目标恢复到的scn号与replicat启动的scn号是一致的就不应该有数据冲突。但是需要排除以下可能导致数据修改的因素：
? 数据库是否有内在的job在目标端运行；
? 操作系统是否有定时任务在修改数据；
? 目标数据库的trigger是否全部被禁用了；
? 目标库的外键是否被全部禁用；
? 建议锁定目标库的除OGG以外所有数据库用户，防止其修改数据。
等等，这些因素可能会导致目标本身数据发生变化，产生与源端数据变化的冲突。
5.13 两端数据不一致的排查与解决
5.13.1 现象
在执行数据对比过程中，部分网省的业务系统中发现有部分表在两端的记录是不一致的。
5.13.2 原因分析与排查
两端出现数据不一致的原因非常多，下面是对比结果有差异的一些可能性因素：
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
? 所有的报告文件
? 丢失数据的大致操作时间
? 丢失数据相关时段的归档日志

5.13.3 解决方案
根据不一致数据表的多少以及不一致数据的条数，可以采取以下方案：
1) 人工补足少量的数据
在确认只有部分表的若干条数据不一致后，可以使用手工方法对不一致的数据进行重新再同步，即从源端找出当前的值，覆盖目标表的相关记录。本方法只适用于不一致数据较少的情况，如从discard文件中可以找到有限的出错记录。
2) 执行部分表的初始化
当其中某些表不同步，而数据条数较多时，可以对该部分表执行重新初始化，具体步骤参见运维文档的第5.5节。
3) 全部重新初始化
当大部分表出现不一致的情况时，需要对全库执行重新初始化，可以按照安装实施文档的步骤执行，之前请务必保
证安装实施文档中的步骤正确性，如有问题可以联系技术支持。
5.14 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以上，问题解决
5.15 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.
处理方法：安装补丁包

5.16 OGG-xxxxx错误代码
本节为ogg具体错误代码的问题处理方式
5.16.1 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 Oracl

e, 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查看实际数据，分析原因
5.16.2 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
5.16.3 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) 从https://www.360docs.net/doc/7e14801135.html,下载最新的补丁包，升级GoldenGate。
5.16.4 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
5.16.5 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的名称
5.16.6 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
5.16.7 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即可恢复正常复制
5.16.8 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 可以正常工作
5.16.9 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即可恢复正常复制
5.16.10 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
5.16.11 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*/https://www.360docs.net/doc/7e14801135.html,ERNAM
E,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;


5.17 队列文件保存天数
在mgr.prm中，添加：
PURGEOLDEXTRACTS ./dirdat/*,usecheckpoints, minkeepdays 3
修改之后，必须重启manager即可看到队列文件占用的空间被按照上面指定的规则释放。
如果存储空间不够，可以将minkeepdays修改为MINKEEPHOURS
很多网省源端存储空间不足，这样修改为最小保留的小时数，缓解存储空间不足。
如果空间仍然紧张，仍要求立即释放空间，可修改为：MINKEEPFILES，将值设置为1，即只保留一个处理过的队列文件（不建议使用）。
如果存储空间充裕，建议最少保留3天的队列文件。
5.18 队列文件不自动清除
首先确认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 ST