GoldenGate日常维护操作要点.pdf

Oracle 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* 启动所有的包含字符dextract 进程； ? 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 . 可以查看进程处理 的记录数。该报告会详细的列出处理的类型和记录数。如： GGSCI stats edr, total 列出自进程启动以来处理的所有记录数。 GGSCI stats edr, daily, table gg.test 列出当天以来处理的有关gg.test表的所有记录数。 2.4.1.8 查看运行报告 GGSCI view report 可以查看运行报告。如： 也可以进入到/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，显示下一条记录，如果要跳过当前记录，方法如下： GGSCIalter 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 LogdumpCOUNT 查看队列文件中，包含该表的记录条数 Logdump FILTER INCLUDE TRANSIND 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 中强制提交或者回滚指定事务，可以通过以下命令（ SEND EXTRACT , SKIPTRANS THREAD /跳过交易 GgsciSEND EXTRACT , FORCETRANS THREAD /强制认为 该交易已经提交 说明：使用这些命令只会让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 文件，并上传到ftp.oracle.com 网站。 trace收集方法如下： 2) 根 据 进 程 名 称 将 下 面 的xml文 件 改 名 ， 命 名 格 式 为 ： gglog-XXX.xml， 例 如 ： gglog-EXTYB.xml 3) 将该文件拷贝到GoldenGate 安装目录 4) 注释掉 manager 参数文件中的AUTOSTART 和 AUTORESTART 5) 启动出现错误的进程：GGSCIstrat XXX 6) 运行直至进程abend 7) 拷贝产生的log 文件、 dmp 文件、 ggserr.log、dirrpt 目录并上传到ftp.oracle.com 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:ORACLEPRODUCT10.2.0ORADATAORCLREDO02.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:ORACLEPRODUCT10.2.0ORADATAORCLREDO02.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:ORACLEPRODUCT10.2.0ORADATAORCLREDO02.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) GGSCIalter replicat_new extseqno 6, extrba 149258 7) 确认所有参数文件无误，启动进程即可 5 OGG 异常处理预案 5.1 异常处理一般步骤 如果 GoldenGate 复制出现异常，可以通过以下步骤尝试解决问题： 1) 通过 ggsciview report 命令查找ERROR 字样，确定错误原因并根据其信息进行排除； 2) 通过 ggsciview ggsevt 查看告警日志信息； 3) 检查两端数据库是否正常运行，网络是否连通； 4) 如不能确定错误原因，则可以寻求Oracle 技术支持。在寻求技术支持时一般需要提供 以下信息： ? 错误描述 ? 进程报告，位于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