1、 Oracle GoldenGate 日常运维手册2.4 OGG 日常监控2.4.1 OGG 常用监控命令.4.1.1 启动 GoldenGate 进程1) 首先以启动 GoldenGate 进程的系统用户（一般为 oracle）登录源系统。2) 进入 GoldenGate 安装目录，执行./ggsci 进入命令行模式。3) 启动源端管理进程 GGSCI start mgr4) 同样登陆到目标端 GoldenGate 安装目录，执行./ggsci，然后执行 GGSCI start mgr 启动管理进程。5) 在源端执行 GGSCI start er *启动所有进程6) 同样登录到备份端执行 G
2、GSCI 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 *
3、d* 启动所有的包含字符dextract 进程；? GGSCI start replicat rep* 启动所有以“rep“开头的 replicat 进程2.4.1.2 停止 GoldenGate 进程依照以下步骤停止 GoldenGate 进程：1) 以启动 GoldenGate 进程的系统用户（一般为 oracle）登录源主机，进入 GoldenGate 安装目录执行./ggsci 进入命令行管理界面2) (*注：本步骤仅针对抽取日志的主 extract 进程， data pump 进程和 replicat 进程不需要本步骤) 验证 GoldenGate 的抽取进程重起所需的日志存在，对各
4、个主 extXX 进程，执行如下命令：ggsci info extXX, showchRead Checkpoint #1.Recovery Checkpoint (position of oldest unprocessed transaction in the data source):Thread #: 1Sequence #: 9671RBA: 239077904Timestamp: 2008-05-20 11:39:07.000000SCN: 2195.1048654191Redo File: Not availableCurrent Checkpoint (position of
5、last record read in the data source):Thread #: 1Sequence #: 9671RBA: 239377476Timestamp: 2008-05-20 11:39:10.000000SCN: 2195.1048654339Redo File: Not AvailableRead Checkpoint #2Recovery Checkpoint (position of oldest unprocessed transaction in the data source):Thread #: 2Sequence #: 5287RBA: 1311541
6、60Timestamp: 2008-05-20 11:37:42.000000SCN: 2195.1048640151Redo File: /dev/rredo07Current Checkpoint (position of last record read in the data source):Thread #: 2Sequence #: 5287RBA: 138594492Timestamp: 2008-05-20 11:39:14.000000SCN: 2195.1048654739Redo File: /dev/rredo07首先察看 Recovery Checkpoint 所需要
7、读取的最古老日志序列号，如举例中的实例 1 需要日志 9671 及其以后所有归档日志，实例 2 需要序列号为 5287 及以后所有归档日志，确认这些归档日志存在于归档日志目录后才可以执行下一步重起。如果这些日志已经被删除，则下次重新启动需要先恢复归档日志。注意：对于 OGG 11 及以后版本新增了自动缓存长交易的功能，缺省每隔 4 小时自动对未提交交易缓存到本地硬盘，这样只需要最多 8 个小时归档日志即可。但是缓存长交易操作只在 extract 运行时有效，停止后不会再缓存，此时所需归档日志最少为 8 个小时加上停机时间，一般为了保险起见建议确保重启时要保留有 12个小时加上停机时间的归档日志
8、。1) 执行 GGSCI stop er *停止所有源进程，或者分别对各个进程执行 stop 单独停止。2) 以 oracle 用户登录目标系统，进入安装目录/oraclelog1/goldengate，执行./ggsci 进入命令行。3) 在目标系统执行 stop er *停止复制4) 在两端进程都已停止的情况下,如需要可通过 stop mgr 停止各系统内的管理进程。类似的，stop 命令具有跟 start 命令一样的用法。这里不再赘述。注意，如果是只修改抽取或者复制进程参数，则不需要停止 MGR。不要轻易停止 MGR 进程，并且慎重使用通配符 er *， 以免对其他复制进程造成不利影响。
9、2.4.1.4 查看参数设置使用 view params 可以查看进程的参数设置。该命令同样支持通配符*。2.4.1.5 查看进程状态使用 info 命令可以查看进程信息。可以查看到的信息包括进程状态、checkpoint 信息、延时等。如： 还可以使用 info detail 命令查看更详细的信息。包括所使用的 trail 文件，参数文件、报告文件、警告日志的位置等。如：使用 info showch 命令可以查看到详细的关于 checkpoint 的信息，用于查看GoldenGate 进程处理过的事务记录。其中比较重要的是 extract 进程的 recovery checkpoint，它表
10、示源数据中最早的未被处理的事务；通过 recovery checkpoint 可以查看到该事务的 redo log 位于哪个日志文件以及该日志文件的序列号。所有序列号比它大的日志文件，均需要保留。2.4.1.6 查看延时GGSCI lag 可以查看详细的延时信息。如： 2.4.1.7 查看统计信息GGSCI stats ,table . 可以查看进程处理的记录数。该报告会详细的列出处理的类型和记录数。如：GGSCI stats edr, total 列出自进程启动以来处理的所有记录数。GGSCI stats edr, daily, table gg.test 列出当天以来处理的有关 gg.te
11、st 表的所有记录数。2.4.1.8 查看运行报告GGSCI view report 可以查看运行报告。如：也可以进入到 /dirrpt/目录下，查看对应的报告文件。2.4.2 Logdump 使用指引1) 在 GGSCI 中使用如下命令查看当前处理的队列文件和 RBA 号，例如：GGSCI info REPYXA2) 在 GoldenGate 安装目录执行 logdump 命令3) 打开要查看的队列文件Logdump open ./dirdat/p1000556Current LogTrail is ./dirdat/p1000556Logdump ghdr onLogdump detail
12、 onLogdump detail dataLogdump usertoken onLogdump pos 59193235 上面 INFO 命令看到的 RBA 号码Logdump n输入 n 显示当前处理的表及相关操作再次输入 n，显示下一条记录，如果要跳过当前记录，方法如下：GGSCIalter REPYXA extseqno 556, extrba 上面再次输入 n 看到的下一个 RBA 号，其中556 为上面 INFO 看到的队列文件，0 之后的数字4) 打开下一个队列文件Logdump NEXTTRAIL5) 使用 logdump 查看 SCN 号Logdump ggstoken d
13、etail只有在事务开始的 RBA 号，才记录对应的 SCN 号和 Transaction ID，示例如下：上图显示 SCN 号：4024322，TRANID:6.38.1600如果进程出现问题，可以找到在处理那个事务时出现问题，修改进程提前到该事务之前的时间点进行重新抽取，然后从找到的 SCN 号启动 replicat 进程，例如：GGSCI start rep_xxx ATCSN 40243326) 使用 COUNT统计队列文件中包含的记录条数按时间点统计Logdump COUNT START 2006-01-11 12:00:00 , END 2006-01-12 12:00:00统计
14、ls 开头的每个队列文件包含的条数Logdump COUNT LOG ls*Logdump COUNT DETAILLogdump7) 使用 FilterLogdump FILTER INCLUDE FILENAME Schema.table_nameLogdumpCOUNT查看队列文件中，包含该表的记录条数Logdump FILTER INCLUDE TRANSIND stop mgrGGSCI start mgr注：临时停止 mgr 进程并不影响数据复制。2.5.2 配置启动 MGR 时自动启动 Extract 和 Replicat 进程1) 进入安装目录执行./ggsci；2) 执行 e
15、dit param mgr 编辑管理进程参数，加入以下行AUTOSTART ER *3) 停止 MGR 进程，修改好参数后重启该进程GGSCI stop mgrGGSCI start mgr注意：一般建议不用自动启动，而是手工启动，便于观察状态验证启动是否成功，同时也便于手工修改参数。2.5.3 配置 MGR 自动重新启动 Extract 和 Replicat 进程GoldenGate 具有自动重起 extract 或者 replicat 进程的功能，能够自动恢复如网络中断、数据库临时挂起等引起的错误，在系统恢复后自动重起相关进程，无需人工介入。1) 进入安装目录执行 ggsci 进入命令行界
16、面；2) 执行 edit param mgr 编辑管理进程参数，加入以下行AUTORESTART ER *, RETRIES 3, WAITMINUTES 5, RESETMINUTES 60以上参数表示每 5 分钟尝试重新启动所有进程，共尝试三次。以后每 60 分钟清零，再按照每 5 分钟尝试一次共试 3 次。3) 停止 MGR 进程，修改好参数后重启该进程，使修改后的参数文件生效GGSCI stop mgrGGSCI start mgr2.5.4 长事务管理在停止抽取进程前需要通过命令检查是否存在长交易，以防止下次启动无法找到归档日志：ggsci info extXX, showch2.5
17、.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 可以查找到对应的事务，请应用开发商和 D
18、BA 帮助可以查找出未提交原因，通过数据库予以提交或者回滚后GoldenGate 的 checkpoint 会自动向前滚动。2.5.4.2 使用 GoldenGate 命令跳过或接受长交易的方法在 GoldenGate 中强制提交或者回滚指定事务，可以通过以下命令（ SEND EXTRACT , SKIPTRANS THREAD /跳过交易GgsciSEND EXTRACT , FORCETRANS THREAD /强制认为该交易已经提交说明：使用这些命令只会让 GoldenGate 进程跳过或者认为该交易已经提交，但并不改变数据库中的交易，他们依旧存在于数据库中。因此，强烈建议使用数据库中提
19、交或者回滚交易而不是使用 GoldenGate 处理。2.5.4.3 配置长交易告警可以在 extract 进程中配置长交易告警，参数如下所示：extract extszwarnlongtrans 12h, checkintervals 10mexttrail /backup/goldengate/dirdat/sz.以上表示 GoldenGate 会每隔 10 分钟检查一下长交易，如果有超过 12 个小时的长交易，GoldenGate 会在根目录下的 ggserr.log 里面加入一条告警信息。可以通过察看 ggserr.log 或者在 ggsci 中执行 view ggsevt 命令查看这
20、些告警信息。以上配置可以有助于及时发现长交易并予以处理。说明：在 OGG 11g 中，extract 提供了 BR 参数可以设置每隔一段时间（默认 4 小时）将长交易缓存到本地硬盘（默认 dirtmp 目录下） ，因此 extract 只要不停止一般需要的归档日志不超过 8 个小时（极限情况） 。但是如果 extract 停掉后，便无法再自动缓存长交易，需要的归档日志就会依赖于停机时间变长。2.5.9 Trace 收集方法1) GoldenGate 在出现问题时，在 Support 网站创建 SR 之后，研发部门会要求收集相关的trace 文件，并上传到 网站。trace 收集方法如下：2)
21、 根据进程名称将下面的 xml 文件改名，命名格式为： gglog-XXX.xml，例如：gglog-EXTYB.xml 3) 将该文件拷贝到 GoldenGate 安装目录4) 注释掉 manager 参数文件中的 AUTOSTART 和 AUTORESTART5) 启动出现错误的进程：GGSCIstrat XXX6) 运行直至进程 abend7) 拷贝产生的 log 文件、dmp 文件、ggserr.log、dirrpt 目录并上传到 4 OGG 性能优化方法从根本上讲，OGG 复制性能和要复制的表是否存在主键和唯一索引有很大关系，所以从应用系统开发商对表结构的规范更为有效，请参见“2 国
22、网应用系统开发规范” 。OGG 调优通常采用拆分进行的方式，拆分方法如下所述。4.1 Extract 拆分方法1) 停止 extract 进程2) 停止 datapump、进程GGSCI INFO datapump_nameEXTRACT DPEF Last Started 2011-01-28 12:34 Status RUNNINGCheckpoint Lag 00:00:00 (updated 00:00:05 ago)Log Read Checkpoint File ./dirdat/ef0000102011-01-28 12:47:45.000000 RBA 148645直至 RBA
23、 号不变化，才能停止3) 停止 replicat 进程GGSCI INFO replicat_nameREPLICAT RPEF Last Started 2011-01-28 12:30 Status RUNNINGCheckpoint Lag 00:00:00 (updated 00:00:05 ago)Log Read Checkpoint File ./dirdat/ef0000062011-01-28 12:47:45.000000 RBA 149258直至 RBA 号不变化，才能停止4) 记录 extract 检查点Extract 检查点包括：Recovery Checkpoint
24、 和 Current CheckpointGGSCI INFO extract_name, SHOWCHEXTRACT EXEE Last Started 2011-01-28 09:58 Status STOPPEDCheckpoint Lag 00:00:00 (updated 00:01:02 ago)Log Read Checkpoint Oracle Redo Logs2011-01-28 10:02:16 Seqno 26, RBA 7090688Current Checkpoint Detail:Read Checkpoint #1Oracle Redo LogStartup C
25、heckpoint (starting position in the data source):Sequence #: 26RBA: 289296Timestamp: 2011-01-28 09:27:31.000000Redo File: C:ORACLEPRODUCT10.2.0ORADATAORCLREDO02.LOGRecovery Checkpoint (position of oldest unprocessed transaction in the data source):Sequence #: 26RBA: 7088144Timestamp: 2011-01-28 10:0
26、2:16.000000Redo File: C:ORACLEPRODUCT10.2.0ORADATAORCLREDO02.LOGCurrent Checkpoint (position of last record read in the data source):Sequence #: 26RBA: 7090688Timestamp: 2011-01-28 10:02:16.000000Redo File: C:ORACLEPRODUCT10.2.0ORADATAORCLREDO02.LOGWrite Checkpoint #1GGS Log TrailCurrent Checkpoint
27、(current write position):Sequence #: 11RBA: 31609Timestamp: 2011-01-28 10:02:19.072000Extract Trail: ./dirdat/eeHeader:Version = 2Record Source = AType = 4# Input Checkpoints = 1# Output Checkpoints = 1File Information:Block Size = 2048Max Blocks = 100Record Length = 2048Current Offset = 0Configurat
28、ion:Data Source = 3Transaction Integrity = 1Task Type = 0Status:Start Time = 2011-01-28 09:58:34Last Update Time = 2011-01-28 10:02:19Stop Status = GLast Result = 4005) 修改原有相应的参数文件，将拆分出的表从参数文件中删除6) 增加新的 extract，datapump 和 replicat-source-GGSCI (win2k364) 15 add ext exef, tranlog, begin nowGGSCI (win
29、2k364) 16 add exttrail ./dirdat/ef, ext exef, megabytes 50GGSCI (win2k364) 17 add ext dpef, exttrailsource ./dirdat/efGGSCI (win2k364) 18 add rmttrail ./dirdat/ef, ext dpef, megabytes 50-target-GGSCI (win2k364) 21 add rep rpef, exttrail ./dirdat/ef7) 修改新增 extract 进程的检查点检查点为上面记录的两个检查点：current read ch
30、eckpoint and recovery checkpoint-修改 current read checkpointGGSCI (win2k364) 30 alter exef extseqno 26, extrba 7090688 , thread nEXTRACT altered.-修改 recovery checkpointGGSCI (win2k364) 4 alter exef ioextseqno 26, ioextrba 7088144 , thread n2011-01-28 10:46:18 INFO OGG-00989 WARNING: Unsupported opera
31、tion. This might cause transactional inconsistency. Modifying iocheckpoint: ioseq = 26 iorba = 7088144.Are you sure you want to continue? yEXTRACT altered.8) 确认所有参数文件正确，启动进程即可4.2 Datapump 和 replicat 拆分方法下面以拆分 replicat 为例，datapump 拆分方法相同。1) 停止 replicat 进程2) 查看检查点GGSCI INFO replicat_name, SHOWCH3) 修改原
32、有参数文件，将拆分出的表删除4) 新增 replicat，和拆分前的进程读取相同的队列文件5) 修改检查点6) GGSCIalter replicat_new extseqno 6, extrba 1492587) 确认所有参数文件无误，启动进程即可5 OGG 异常处理预案5.1 异常处理一般步骤如果 GoldenGate 复制出现异常，可以通过以下步骤尝试解决问题：1) 通过 ggsciview report 命令查找 ERROR 字样，确定错误原因并根据其信息进行排除；2) 通过 ggsciview ggsevt 查看告警日志信息；3) 检查两端数据库是否正常运行，网络是否连通；4) 如不
33、能确定错误原因，则可以寻求 Oracle 技术支持。在寻求技术支持时一般需要提供以下信息：? 错误描述? 进程报告，位于 dirrpt 下以大写进程名字开头，以.rpt 结尾，如进程名叫 extsz，则报告名字叫 EXTSZ.rpt；? GGS 日志 ggserr.log，位于 GGS 主目录下；? 丢失数据报告，在复制进程的参数 disardfile 中定义，一般结尾为 .dsc；? 当前队列，位于 dirdat 下。5.2 网络故障如果 MGR 进程参数文件里面设置了 autorestart 参数，GoldenGate 可以自动重启，无需人工干预。当网络发生故障时, GoldenGate
34、负责产生远地队列的 Datapump 进程会自动停止. 此时, MGR 进程会定期根据 mgr.prm 里面 autorestart 设置自动启动 Datapump 进程以试探网络是否恢复。在网络恢复后, 负责产生远程队列的 Datapump 进程会被重新启动，GoldenGate 的检查点机制可以保证进程继续从上次中止复制的日志位置继续复制。需要注意的是，因为源端的抽取进程（Capture）仍然在不断的抓取日志并写入本地队列文件，但是 Datapump 进程不能及时把本地队列搬动到远地，所以本地队列文件无法被自动清除而堆积下来。需要保证足够容量的存储空间来存储堆积的队列文件。计算公式如下：存
35、储容量单位时间产生的队列大小网络故障恢复时间MGR 定期启动抓取和复制进程参数配置参考：GGSCI edit param mgrport 7839autorestart er *,waitminutes 3,retries 5,RESETMINUTES 60每 3 分钟重试一次，5 次重试失败以后等待 60 分钟，然后重新试三次。5.3 RAC 环境下单节点失败在 RAC 环境下，GoldenGate 软件安装在共享目录下。可以通过任一个节点连接到共享目录，启动 GoldenGate 运行界面。如果其中一个节点失败，导致 GoldenGate 进程中止，可直接切换到另外一个节点继续运行。建议在
36、 Oracle 技术支持协助下进行以下操作：1) 以 oracle 用户登录源系统（通过另一完好节点） ；2) 确认将 GoldenGate 安装所在文件系统装载到另一节点相同目录；3) 确认 GoldenGate 安装目录属于 oracle 用户及其所在组；4) 确认 oracle 用户及其所在组对 GoldenGate 安装目录拥有读写权限；5) 进入 goldengate 安装目录；6) 执行./ggsci 进入命令行界面；7) 执行 start mgr 启动 mgr；8) 执行 start er *启动所有进程；检查各进程是否正常启动，即可进入正常复制。以上过程可以通过集成到 CRS
37、或 HACMP等集群软件实现自动的切换，具体步骤请参照国网测试文档。5.4 Extract 进程常见异常对于源数据库，抽取进程 extxm 如果变为 abended，则可以通过在 ggsci 中使用 view report命令察看报告，可以通过搜索 ERROR 快速定位错误。一般情况下，抽取异常的原因是因为其无法找到对应的归档日志，可以通过到归档日志目录命令行下执行 ls lt arch_X_XXXXX.arc察看该日志是否存在，如不存在则可能的原因是：1) 日志已经被压缩GoldenGate 无法自动解压缩，需要人工解压缩后才能读取。2) 日志已经被删除如果日志已经被删除，需要进行恢复才能继
38、续复制，请联系本单位 DBA 执行恢复归档日志操作。一般需要定期备份归档日志，并清除旧的归档日志。需要保证归档日志在归档目录中保留足够长时间之后，才能被备份和清除。即：定期备份清除若干小时之前的归档，而不是全部归档。保留时间计算如下：某归档文件保留时间抽取进程处理完该文件中所有日志所需的时间可以通过命令行或者 GoldenGate Director Web 界面，运行 info exXX showch 命令查看抓取进程 exXX 处理到哪条日志序列号。在此序列号之前的归档，都可以被安全的清除。如下图所示：5.5 Replicat 进程常见异常对于目标数据库，投递进程 repXX 如果变为 ab
39、ended，则可以通过在 ggsci 中使用 view report 命令察看报告，可以通过搜索 ERROR 快速定位错误。复制进程的错误通常为目标数据库错误，比如：1) 数据库临时停机；2) 目标表空间存储空间不够；3) 目标表出现不一致。可以根据报告查看错误原因，排除后重新启动 rep 进程即可。需要注意一点：往往容易忽略 UNDO 表空间。如果 DML 语句中包含了大量的 update 和delete 操作，则目标端 undo 的生成速度会很快，有可能填满 UNDO 表空间。因此需要经常检查 UNDO 表空间的大小。5.6 抽取生成的队列文件比归档文件多1) 现象在国网多个网省的业务系统
40、中出现了某一时间段内，OGG 的抓取进程所产生的数据队列远远大于 Oracle 数据库所产生的归档日志，导致 OGG 队列存放位置空间不够用。2) 原因分析OGG 本身是解析数据库的归档日志并从中获取有效的数据变化，在一般情况下其所抽取出来的数据队列要小于归档日志产生量。但是，也有特殊情况，例如 Oracle 数据库在修改 BLOB/CLOB/Long 等占用空间特别大的数据对象时，为了降低日志的产生量及其对数据库整体性能的影响，其在数据库日志中只记录一个标识说明该字段发生了变化，但并不将该字段的 Before Image 和 After Image 真正写入日志，然后直接将新数据写到数据库覆
41、盖原来的旧值；OGG 在进行数据复制时，为了能够使目标数据与源端保持一致，必须要在 Trail 里面写入update 以后该字段 after image 的实际值，由于这些信息在日志文件中是没有的，OGG 就会根据日志中记录的信息到数据库中去查询该大字段的实际值，将这个从数据库中获取的值放到队列文件中，日志文件是没有这个实际值的。由于这些对象非常大，也就导致 OGG的队列文件会比日志增加了很多倍。队列文件具体增大的倍数决定于特定时间段内的大对象更新频率和每个大对象的实际值，实际应用中较难精确计算，可以根据实际运行统计值对队列所需空间进行估算。综上所述，队列文件较大完全是正常现象，数据全部能够正
42、常入库也证实了我们的判断。3) 解决方案针对队列较大，可能引起空间不够的问题，以下为可选方案，可以根据各网省具体情况选择其中一个或者两个：? 缩短保留队列的时间可以调节 OGG 自动删除队列间的参数，缩短保留队列的时间。例如，在 MGR 的参数里面：PURGEOLDEXTRACTS /ggs/dirdat/ *, USECHECKPOINTS, MINKEEPHOURS 96其中，MINKEEPHOURS 表示要保留队列的最小时间。如果当前为 96，表示至少会保留 4天的队列；经过观察现有磁盘空间大约可以满足 2 天多的队列，则可以修改为 48。修改后需重启 MGR 使新参数生效。MGR 进程
43、会自动删除超过指定时间的队列。本方法在源和目标均适用。说明：USECHECKPOINTS 表示 OGG 删除队列时必须要保证该队列已经被使用过了，那些没有被应用过的队列即使超过规定时间也是不会被自动删除的。? 扩大磁盘空间如果本地磁盘尚有空余，可以考虑为 OGG 增加磁盘空间。本方法在源和目标均适用。? 对磁盘空间进行监控可以通过监控工具或脚本定时监控 OGG 所在位置的磁盘使用率，一旦到达即报警，交由相应人员改变保存队列策略或人工处理。5.7 OGG 的 Extract 进程占用内存较大1) 现象源端的 Extract 进程有占用较大内存。2) 原因分析OGG 的 Extract 占用的内存
44、包括两部分：一部分用来存储复制表的结构等相关数据字典信息。此部分跟表的数量有关，但总量一般在几十兆以内，无需特别关注；另外一部分用来存储当前数据库中所有未提交的交易数据，当事务提交后 OGG 会将内存中的数据写入 Trail，然后释放内存。这是某些时候 OGG 的 Extract 进程占用内存较多的主要原因。为了防止所需内存总量超过实际物理内存，OGG 提供了 cachemgr 参数，可以在内存不够时使用本地硬盘作为缓存。举例如下：CACHEMGR CACHESIZE 500MB, CACHEDIRECTORY /ggs/temp, CACHEDIRECTORY /ggs2/temp本例中，如
45、果 OGG 的 Extract 进程所需内存超过了 500M，则会将交易数据写到指定的两个位置下作为虚拟内存。一旦这些交易提交，则会将这些虚拟内存与内存同样清除。注：不推荐设置该参数时，默认 OGG 会将允许使用的内存 64 位系统设置为 8G，32 位系统为 2G。默认的虚拟内存空间为安装目录下的 dirtmp。3) 排查方法与解决方案一旦出现 Extract 报告内存问题，各网省可根据以下步骤进行排查和选择解决方案：? 排查操作系统对于内存的限制在主机上使用 ulimit a 查看 OGG 运行用户（一般为 oracle）用户在操作系统级的资源允许状况，例如：time(seconds) u
46、nlimitedfile(blocks) unlimiteddata(kbytes) unlimitedstack (kbytes) unlimitedmemory(kbytes) unlimitedcoredump(blocks) 4194303nofiles(descriptors) 15000这些限制的配置一般在/etc/security/limits 文件里，建议将其中的 data/stack/memory 都设置为 unlimited(-1)，至少要保证该配置可以让 OGG 使用 cachemgr 所允许的最大内存，可以联系系统管理员予以调整。? 调整 cachemgr 参数如果物理
47、内存有限，而本地磁盘尚有空余，可以减小 OGG 的 cachemgr 参数中的CACHESIZE，如原来允许使用 2G，现在可以修改为 1G，不够可以去使用硬盘作为虚拟内存。注：由于 IO 方面硬盘和内存差距较大，使用硬盘作为虚拟内存会带来性能方面的下降。? 尝试重启 Extract 进程查看内存使用OGG 本身有自动调节资源占用的特性，即如果系统本身空闲，则其会自动申请更多资源加速数据复制；而如果系统资源紧张，则会释放部分资源给优先级更高的进程。如果想尽快了解 Extract 进程内存占用是否正常，可以尝试重启进程，观察其内存占用是否正常。注意：重启 Extract 时检验其所需的归档日志是
48、否存在，具体方法参照运维文档中停止 OGG 进程的步骤。? 添加物理内存如果系统日常业务繁忙阶段现有物理内存占用率非常高，则建议对系统进行内存扩容。在资源紧张情况下运行 OGG 数据复制会对业务系统的性能带来不利影响。? 申请技术支持如经过以上排查仍然无法排除内存相关问题，可以联系 Oracle 的支持工程师或在技术支持网站上填写 SR，依据技术支持人员要求的步骤提供相关的信息，协助尽快完成问题界定和解决。5.8 OGG 的 Replicat 进程占用内存较大1) 现象目标端的 Replicat 进程有占用较大内存。2) 原因分析OGG 的 Replicat 负责将队列文件中的数据读取出来然后
49、投递到目标数据库，由于每个Replicat 进程处理交易依次进行的，其占用的内存决定于队列中的交易大小。但是 OGG 的Replicat 进程本身在申请到内存后，并不一定随着事务的 commit 立即释放，同 Extract 一样在系统资源较为充足时，其会试图保留一定时间，而发现系统资源紧张时又会释放掉部分资源。默认情况下，OGG 是严格按照源端产生的交易依次进行提交，本身不改变交易的边界，但是有时候为了避免大交易需要读取大量队列文件以及在目标端数据投递需要大量资源，OGG 提供了 MAXTRANSOPS 参数用于将大交易拆分为较小的交易多次提交，除去性能的提升外还能让管理人员更为实时的看到数据投递的变化。例如：MAXTRANSOPS 1000表示如果单个交易中的实际数据变化量超过了 1 千，replicat 会每 1 千条进行一次提交。由于
