ogg运维文档.doc

Oracle GoldenGate日常运维手册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) 同样登录到备份端执行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进程 停止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 #: 1Sequence #: 9671RBA: 239077904Timestamp: 2008-05-20 11:39:07.000000SCN: 2195.1048654191Redo File: Not availableCurrent Checkpoint (position of last record read in the data source):Thread #: 1Sequence #: 9671RBA: 239377476Timestamp: 2008-05-20 11:39:10.000000SCN: 2195.1048654339Redo File: Not AvailableRead Checkpoint #2.Recovery Checkpoint (position of oldest unprocessed transaction in the data source): Thread #: 2Sequence #: 5287RBA: 131154160Timestamp: 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所需要读取的最古老日志序列号，如举例中的实例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 *， 以免对其他复制进程造成不利影响。 查看参数设置使用view params 可以查看进程的参数设置。该命令同样支持通配符*。 查看进程状态使用info 命令可以查看进程信息。可以查看到的信息包括进程状态、checkpoint信息、延时等。如：还可以使用info detail 命令查看更详细的信息。包括所使用的trail文件，参数文件、报告文件、警告日志的位置等。如：使用info showch 命令可以查看到详细的关于checkpoint的信息，用于查看GoldenGate进程处理过的事务记录。其中比较重要的是extract进程的recovery checkpoint，它表示源数据中最早的未被处理的事务；通过recovery checkpoint可以查看到该事务的redo log位于哪个日志文件以及该日志文件的序列号。所有序列号比它大的日志文件，均需要保留。 查看延时GGSCI lag 可以查看详细的延时信息。如： 查看统计信息GGSCI stats ,table . 可以查看进程处理的记录数。该报告会详细的列出处理的类型和记录数。如：GGSCI stats edr, total列出自进程启动以来处理的所有记录数。GGSCI stats edr, daily, table gg.test列出当天以来处理的有关gg.test表的所有记录数。 查看运行报告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 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 detail只有在事务开始的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统计ls开头的每个队列文件包含的条数Logdump COUNT LOG ls*Logdump COUNT DETAILLogdump7) 使用FilterLogdump FILTER INCLUDE FILENAME Schema.table_nameLogdumpCOUNT查看队列文件中，包含该表的记录条数Logdump FILTER INCLUDE TRANSIND 10 = start of transaction1 = middle of transaction2 = end of transaction3 = only record in transaction可以统计队列文件中的事务，可以利用该命令查找事务开始点，如果没有开始的事务，直接找上一个文件即可。2.5 OGG日常运维任务2.5.1 配置自动删除队列1) 进入安装目录执行./ggsci；2) 执行edit param mgr编辑管理进程参数，加入或修改以下行purgeoldextracts /dirdat/*, usecheckpoint, minkeepdays 7其中，第一个参数为队列位置，*可匹配备份中心所有队列文件；第二个参数表示是首先要保证满足检查点需要，不能删除未处理队列；第三个参数表示最小保留多少天，后面的数字为天数。例如，如果希望只保留队列/ggs/dirdat/xm文件3天，可以配置如下：purgeoldextracts /ggs/dirdat/xm, usecheckpoint, minkeepdays 33) 停止MGR进程，修改好参数后重启该进程GGSCI stop mgrGGSCI start mgr注：临时停止mgr进程并不影响数据复制。2.5.2 配置启动MGR时自动启动Extract和Replicat进程1) 进入安装目录执行./ggsci；2) 执行edit param mgr编辑管理进程参数，加入以下行AUTOSTART ER *3) 停止MGR进程，修改好参数后重启该进程GGSCI stop mgrGGSCI 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 mgrGGSCI start mgr2.5.4 长事务管理在停止抽取进程前需要通过命令检查是否存在长交易，以防止下次启动无法找到归档日志： ggsci info extXX, showch 查看长交易的方法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会自动向前滚动。 使用GoldenGate命令跳过或接受长交易的方法在GoldenGate中强制提交或者回滚指定事务，可以通过以下命令（中的为参数）： Ggsci SEND EXTRACT , SKIPTRANS THREAD /跳过交易 GgsciSEND EXTRACT , FORCETRANS THREAD /强制认为该交易已经提交说明：使用这些命令只会让GoldenGate进程跳过或者认为该交易已经提交，但并不改变数据库中的交易，他们依旧存在于数据库中。因此，强烈建议使用数据库中提交或者回滚交易而不是使用GoldenGate处理。 配置长交易告警可以在extract进程中配置长交易告警，参数如下所示：extract extszwarnlongtrans 12h, checkintervals 10mexttrail /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文件，并上传到网站。trace收集方法如下：2) 根据进程名称将下面的xml文件改名，命名格式为：gglog-XXX.xml，例如：gglog-EXTYB.xml3) 将该文件拷贝到GoldenGate安装目录4) 注释掉manager参数文件中的AUTOSTART和AUTORESTART5) 启动出现错误的进程：GGSCIstrat XXX6) 运行直至进程abend7) 拷贝产生的log文件、dmp文件、ggserr.log、dirrpt目录并上传到4 OGG性能优化方法从根本上讲，OGG复制性能和要复制的表是否存在主键和唯一索引有很大关系，所以从应用系统开发商对表结构的规范更为有效，请参见“2 国网应用系统开发规范”。 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号不变化，才能停止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和Current CheckpointGGSCI INFO extract_name, SHOWCHEXTRACT 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 Logs2011-01-28 10:02:16 Seqno 26, RBA 7090688 Current Checkpoint Detail:Read Checkpoint #1Oracle Redo LogStartup Checkpoint (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:02: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 (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 = 0Configuration: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 (win2k364) 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 checkpoint and recovery checkpoint-修改current read checkpointGGSCI (win2k364) 30 alter exef extseqno 26, extrba 7090688 , thread n EXTRACT altered.-修改recovery checkpointGGSCI (win2k364) 4 alter exef ioextseqno 26, ioextrba 7088144 , thread n2011-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? yEXTRACT altered.8) 确认所有参数文件正确，启动进程即可4.2 Datapump和replicat拆分方法下面以拆分replicat为例，datapump拆分方法相同。1) 停止replicat进程2) 查看检查点GGSCI INFO replicat_name, SHOWCH3) 修改原有参数文件，将拆分出的表删除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) 如不能确定错误原因，则可以寻求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 mgrport 7839autorestart 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) unlimitedfile(blocks) unlimiteddata(kbytes) unlimitedstack (kbytes) unlimitedmemory(kbytes) unlimitedcoredump(blocks) 4194303nofiles(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) unlimitedfile(blocks) unlimiteddata(kbytes) unlimitedstack (kbytes) unlimitedmemory(kbytes) unlimitedcoredump(blocks) 4194303nofiles(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文件中的错误信息对错误进行定位，经修复后重启进