GoldenGate日常维护操作

《GoldenGate日常维护操作》由会员分享，可在线阅读，更多相关《GoldenGate日常维护操作（33页珍藏版）》请在装配图网上搜索。

1、- Oracle GoldenGate日常运维手册2.4OGG日常监控2.4.1OGG常用监控命令.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)使用GGS

2、CI info er * 或者 GGSCI info 观察进程状态是否为Running表示已经启动。注意有的进程需要几分钟起来，请重复命令观察其启动状态。说明：无论源还是目标，启动各e*tract/replicat进程前需要启动mgr进程。8)start 命令的一般用法是：start 如：GGSCI start e*tdm 启动一个名叫e*tdm的进程；也可以使用通配符，如：GGSCI start er * 启动所有的e*tract和replicat进程；GGSCI start e*tract *d* 启动所有的包含字符de*tract进程；GGSCI start replicat rep*

3、启动所有以“rep“开头的replicat进程2.4.1.2停顿GoldenGate进程依照以下步骤停顿GoldenGate进程：1)以启动GoldenGate进程的系统用户一般为oracle登录源主机，进入GoldenGate安装目录执行./ggsci进入命令行管理界面2)(*注：本步骤仅针对抽取日志的主e*tract进程， data pump进程和replicat进程不需要本步骤) 验证GoldenGate的抽取进程重起所需的日志存在，对各个主e*t*进程，执行如下命令：ggsci info e*t*, showch.Read Checkpoint *1.Recovery Checkpoi

4、nt (position of oldest unprocessed transaction in the data source): Thread *: 1 Sequence *: 9671 RBA: 239077904 Timestamp: 2008-05-20 11:39:07.000000 S: 2195.1048654191 Redo File: Not available Current Checkpoint (position of last record read in the data source): Thread *: 1 Sequence *: 9671 RBA: 23

5、9377476 Timestamp: 2008-05-20 11:39:10.000000 S: 2195.1048654339 Redo File: Not AvailableRead 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 S: 2195.1048640151 Redo

6、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 S: 2195.1048654739 Redo File: /dev/rredo07.首先观察Recovery Checkpoint所需要读取的最古老日志序列号，如举例中的实例1需要日志9671及其以后所有归档日志，实例2需要序列号为5287及以后所有归档日

7、志，确认这些归档日志存在于归档日志目录后才可以执行下一步重起。如果这些日志已经被删除，则下次重新启动需要先恢复归档日志。注意：对于OGG 11及以后版本新增了自动缓存长交易的功能，缺省每隔4小时自动对未提交交易缓存到本地硬盘，这样只需要最多8个小时归档日志即可。但是缓存长交易操作只在e*tract运行时有效，停顿后不会再缓存，此时所需归档日志最少为8个小时加上停机时间，一般为了保险起见建议确保重启时要保存有12个小时加上停机时间的归档日志。1)执行GGSCI stop er *停顿所有源进程，或者分别对各个进程执行stop 单独停顿。2)以oracle用户登录目标系统，进入安装目录/oracl

8、elog1/goldengate，执行./ggsci进入命令行。3)在目标系统执行stop er *停顿复制4)在两端进程都已停顿的情况下,如需要可通过stop mgr停顿各系统的管理进程。类似的，stop命令具有跟start命令一样的用法。这里不再赘述。注意，如果是只修改抽取或者复制进程参数，则不需要停顿MGR。不要轻易停顿MGR进程，并且慎重使用通配符er *， 以免对其他复制进程造成不利影响。2.4.1.4查看参数设置使用view params 可以查看进程的参数设置。该命令同样支持通配符*。2.4.1.5查看进程状态使用info 命令可以查看进程信息。可以查看到的信息包括进程状态、ch

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

10、 可以查看详细的延时信息。如： 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.2Logdump使用指引1)在GGSCI中使用如下命令查看当前处理的队列文件

11、和RBA号，例如：GGSCI info REPY*A2)在GoldenGate安装目录执行logdump命令3)翻开要查看的队列文件Logdump open ./dirdat/p1000556Current LogTrail is ./dirdat/p1000556Logdump ghdr onLogdump detail onLogdump detail dataLogdump usertoken onLogdump pos 59193235 上面INFO命令看到的RBALogdump n输入n显示当前处理的表及相关操作再次输入n，显示下一条记录，如果要跳过当前记录，方法如下：GGSCIal

12、ter REPY*A e*tseqno 556, e*trba 上面再次输入n看到的下一个RBA号，其中556为上面INFO看到的队列文件，0之后的数字4)翻开下一个队列文件Logdump NE*TTRAIL5)使用logdump查看S号Logdump ggstoken detail只有在事务开场的RBA号，才记录对应的S号和Transaction ID，例如如下：如果进程出现问题，可以找到在处理那个事务时出现问题，修改良程提前到该事务之前的时间点进展重新抽取，然后从找到的S号启动replicat进程，例如：GGSCI start rep_* ATCSN 40243326)使用COUNT统计队

13、列文件中包含的记录条数按时间点统计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 = mid

14、dle of transaction2 = end of transaction3 = only record in transaction可以统计队列文件中的事务，可以利用该命令查找事务开场点，如果没有开场的事务，直接找上一个文件即可。2.5OGG日常运维任务2.5.1配置自动删除队列1)进入安装目录执行./ggsci；2)执行edit param mgr编辑管理进程参数，参加或修改以下行purgeolde*tracts /dirdat/*, usecheckpoint, minkeepdays 7其中，第一个参数为队列位置，*可匹配备份中心所有队列文件；第二个参数表示是首先要保证满足检查点

15、需要，不能删除未处理队列；第三个参数表示最小保存多少天，后面的数字为天数。例如，如果希望只保存队列/ggs/dirdat/*m文件3天，可以配置如下：purgeolde*tracts /ggs/dirdat/*m, usecheckpoint, minkeepdays 33)停顿MGR进程，修改好参数后重启该进程GGSCI stop mgrGGSCI start mgr注：临时停顿mgr进程并不影响数据复制。2.5.2配置启动MGR时自动启动E*tract和Replicat进程1)进入安装目录执行./ggsci；2)执行edit param mgr编辑管理进程参数，参加以下行AUTOSTART

16、 ER *3)停顿MGR进程，修改好参数后重启该进程GGSCI stop mgrGGSCI start mgr注意：一般建议不用自动启动，而是手工启动，便于观察状态验证启动是否成功，同时也便于手工修改参数。2.5.3配置MGR自动重新启动E*tract和Replicat进程GoldenGate具有自动重起e*tract或者replicat进程的功能，能够自动恢复如网络中断、数据库临时挂起等引起的错误，在系统恢复后自动重起相关进程，无需人工介入。1)进入安装目录执行ggsci进入命令行界面；2)执行edit param mgr编辑管理进程参数，参加以下行AUTORESTART ER *, RET

17、RIES 3, WAITMINUTES 5, RESETMINUTES 60以上参数表示每5分钟尝试重新启动所有进程，共尝试三次。以后每60分钟清零，再按照每5分钟尝试一次共试3次。3)停顿MGR进程，修改好参数后重启该进程，使修改后的参数文件生效GGSCI stop mgrGGSCI start mgr2.5.4长事务管理在停顿抽取进程前需要通过命令检查是否存在长交易，以防止下次启动无法找到归档日志：ggsci info e*t*, showch2.5.4.1查看长交易的方法Ggsci send e*tract , showtrans thread n count n其中，为所要观察的进程名

18、，如e*tsz/e*t*m/e*tj*等；Thread n是可选的，表示只查看其中一个节点上的未提交交易；Count n也是可选的，表示只显示n条记录。例如,查看e*tsz进程中节点1上最长的10个交易，可以通过以下命令：Ggsci send e*tract e*tsz , showtrans thread 1 count 10输出结果是以时间降序排列的所有未提交交易列表，通过*id可以查找到对应的事务，请应用开发商和DBA帮助可以查找出未提交原因，通过数据库予以提交或者回滚后GoldenGate的checkpoint会自动向前滚动。2.5.4.2使用GoldenGate命令跳过或承受长交易的

19、方法在GoldenGate中强制提交或者回滚指定事务，可以通过以下命令中的为参数：Ggsci SEND E*TRACT , SKIPTRANS THREAD /跳过交易GgsciSEND E*TRACT , FORCETRANS THREAD /强制认为该交易已经提交说明：使用这些命令只会让GoldenGate进程跳过或者认为该交易已经提交，但并不改变数据库中的交易，他们依旧存在于数据库中。因此，强烈建议使用数据库中提交或者回滚交易而不是使用GoldenGate处理。2.5.4.3配置长交易告警可以在e*tract进程中配置长交易告警，参数如下所示：e*tract e*tszwarnlongt

20、rans 12h, checkintervals 10me*ttrail /backup/goldengate/dirdat/sz.以上表示GoldenGate会每隔10分钟检查一下长交易，如果有超过12个小时的长交易，GoldenGate会在根目录下的ggserr.log里面参加一条告警信息。可以通过观察ggserr.log或者在ggsci中执行view ggsevt命令查看这些告警信息。以上配置可以有助于及时发现长交易并予以处理。说明：在OGG 11g中，e*tract提供了BR参数可以设置每隔一段时间默认4小时将长交易缓存到本地硬盘默认dirtmp目录下，因此e*tract只要不停顿一般

21、需要的归档日志不超过8个小时极限情况。但是如果e*tract停掉后，便无法再自动缓存长交易，需要的归档日志就会依赖于停机时间变长。2.5.9Trace收集方法1)GoldenGate在出现问题时，在Support创立SR之后，研发部门会要求收集相关的trace文件，并上传到ftp.oracle.。trace收集方法如下：2)根据进程名称将下面的*ml文件改名，命名格式为：gglog-*.*ml，例如：gglog-E*TYB.*ml 3)将该文件拷贝到GoldenGate安装目录4)注释掉manager参数文件中的AUTOSTART和AUTORESTART5)启动出现错误的进程：GGSCIstr

22、at *6)运行直至进程abend7)拷贝产生的log文件、dmp文件、ggserr.log、dirrpt目录并上传到ftp.oracle.4OGG性能优化方法从根本上讲，OGG复制性能和要复制的表是否存在主键和唯一索引有很大关系，所以从应用系统开发商对表构造的规更为有效，请参见“2 国网应用系统开发规。OGG调优通常采用拆分进展的方式，拆分方法如下所述。4.1E*tract拆分方法1)停顿e*tract进程2)停顿datapump、进程GGSCI INFO datapump_nameE*TRACT DPEF Last Started 2011-01-28 12:34 Status RUNNI

23、NGCheckpoint 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_nameREPLICAT RPEF Last Started 2011-01-28 12:30 Status RUNNINGCheckpoint Lag 00:00:00 (updated 00:00:05 ago)Log Read Checkpo

24、int File ./dirdat/ef000006 2011-01-28 12:47:45.000000 RBA 149258直至RBA号不变化，才能停顿4)记录e*tract检查点E*tract检查点包括：Recovery Checkpoint和Current CheckpointGGSCI INFO e*tract_name, SHOWCHE*TRACT E*EE Last Started 2011-01-28 09:58 Status STOPPEDCheckpoint Lag 00:00:00 (updated 00:01:02 ago)Log Read Checkpoint Ora

25、cle Redo Logs 2011-01-28 10:02:16 Seqno 26, RBA 7090688Current 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 Recove

26、ry 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 Tim

27、estamp: 2011-01-28 10:02:16.000000 Redo File: C:ORACLEPRODUCT10.2.0ORADATAORCLREDO02.LOGWrite Checkpoint *1 GGS Log Trail Current Checkpoint (current write position): Sequence *: 11 RBA: 31609 Timestamp: 2011-01-28 10:02:19.072000 E*tract Trail: ./dirdat/eeHeader: Version = 2 Record Source = A Type

28、= 4 * Input Checkpoints = 1 * Output Checkpoints = 1File Information: Block Size = 2048 Ma* Blocks = 100 Record Length = 2048 Current Offset = 0Configuration: Data Source = 3 Transaction Integrity = 1 Task Type = 0Status: Start Time = 2011-01-28 09:58:34 Last Update Time = 2011-01-28 10:02:19 Stop S

29、tatus = G Last Result = 4005)修改原有相应的参数文件，将拆分出的表从参数文件中删除6)增加新的e*tract，datapump和replicat-source-GGSCI (win2k364) 15 add e*t e*ef, tranlog, begin nowGGSCI (win2k364) 16 add e*ttrail ./dirdat/ef, e*t e*ef, megabytes 50GGSCI (win2k364) 17 add e*t dpef, e*ttrailsource ./dirdat/efGGSCI (win2k364) 18 add rm

30、ttrail ./dirdat/ef, e*t dpef, megabytes 50-target-GGSCI (win2k364) 21 add rep rpef, e*ttrail ./dirdat/ef7)修改新增e*tract进程的检查点检查点为上面记录的两个检查点：current read checkpoint and recovery checkpoint-修改current read checkpointGGSCI (win2k364) 30 alter e*ef e*tseqno 26, e*trba 7090688 , thread nE*TRACT altered.-修改r

31、ecovery checkpointGGSCI (win2k364) 4 alter e*ef ioe*tseqno 26, ioe*trba 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 yE*TRACT alt

32、ered.8)确认所有参数文件正确，启动进程即可4.2Datapump和replicat拆分方法下面以拆分replicat为例，datapump拆分方法一样。1)停顿replicat进程2)查看检查点GGSCI INFO replicat_name, SHOWCH3)修改原有参数文件，将拆分出的表删除4)新增replicat，和拆分前的进程读取一样的队列文件5)修改检查点6)GGSCIalter replicat_new e*tseqno 6, e*trba 1492587)确认所有参数文件无误，启动进程即可5OGG异常处理预案5.1异常处理一般步骤如果GoldenGate复制出现异常，可以通

33、过以下步骤尝试解决问题：1)通过ggsciview report命令查找ERROR字样，确定错误原因并根据其信息进展排除；2)通过ggsciview ggsevt查看告警日志信息；3)检查两端数据库是否正常运行，网络是否连通；4)如不能确定错误原因，则可以寻求Oracle技术支持。在寻求技术支持时一般需要提供以下信息：错误描述进程报告，位于dirrpt下以大写进程名字开头，以.rpt结尾，如进程名叫e*tsz，则报告名字叫E*TSZ.rpt；GGS日志ggserr.log，位于GGS主目录下；丧失数据报告，在复制进程的参数disardfile中定义，一般结尾为.dsc；当前队列，位于dirda

34、t下。5.2网络故障如果MGR进程参数文件里面设置了autorestart参数，GoldenGate可以自动重启，无需人工干预。当网络发生故障时, GoldenGate负责产生远地队列的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.3RAC环境下单节点失败在RAC环境下，GoldenGate软件安装在共享目录下。可以通过任一个节点连接到共享目录，启动GoldenGate

36、运行界面。如果其中一个节点失败，导致GoldenGate进程中止，可直接切换到另外一个节点继续运行。建议在Oracle技术支持协助下进展以下操作：1)以oracle用户登录源系统通过另一完好节点；2)确认将GoldenGate安装所在文件系统装载到另一节点一样目录；3)确认GoldenGate安装目录属于oracle用户及其所在组；4)确认oracle用户及其所在组对GoldenGate安装目录拥有读写权限；5)进入goldengate安装目录；6)执行./ggsci进入命令行界面；7)执行start mgr启动mgr；8)执行start er *启动所有进程；检查各进程是否正常启动，即可进入

37、正常复制。以上过程可以通过集成到CRS或HACMP等集群软件实现自动的切换，具体步骤请参照国网测试文档。5.4E*tract进程常见异常对于源数据库，抽取进程e*t*m如果变为abended，则可以通过在ggsci中使用view report命令观察报告，可以通过搜索ERROR快速定位错误。一般情况下，抽取异常的原因是因为其无法找到对应的归档日志，可以通过到归档日志目录命令行下执行 ls lt arch_*_*.arc观察该日志是否存在，如不存在则可能的原因是：1)日志已经被压缩GoldenGate无法自动解压缩，需要人工解压缩后才能读取。2)日志已经被删除如果日志已经被删除，需要进展恢复才能

38、继续复制，请联系本单位DBA执行恢复归档日志操作。一般需要定期备份归档日志，并去除旧的归档日志。需要保证归档日志在归档目录中保存足够长时间之后，才能被备份和去除。即：定期备份去除假设干小时之前的归档，而不是全部归档。保存时间计算如下：*归档文件保存时间抽取进程处理完该文件中所有日志所需的时间可以通过命令行或者GoldenGate Director Web界面，运行info e* showch命令查看抓取进程e*处理到哪条日志序列号。在此序列号之前的归档，都可以被平安的去除。如以下图所示：5.5Replicat进程常见异常对于目标数据库，投递进程rep*如果变为abended，则可以通过在ggs

39、ci中使用view report命令观察报告，可以通过搜索ERROR快速定位错误。复制进程的错误通常为目标数据库错误，比方：1)数据库临时停机；2)目标表空间存储空间不够；3)目标表出现不一致。可以根据报告查看错误原因，排除后重新启动rep进程即可。需要注意一点：往往容易忽略UNDO表空间。如果DML语句中包含了大量的update和delete操作，则目标端undo的生成速度会很快，有可能填满UNDO表空间。因此需要经常检查UNDO表空间的大小。5.6抽取生成的队列文件比归档文件多1)现象在国网多个网省的业务系统中出现了*一时间段，OGG的抓取进程所产生的数据队列远远大于Oracle数据库所产

40、生的归档日志，导致OGG队列存放位置空间不够用。2)原因分析OGG本身是解析数据库的归档日志并从中获取有效的数据变化，在一般情况下其所抽取出来的数据队列要小于归档日志产生量。但是，也有特殊情况，例如Oracle数据库在修改BLOB/CLOB/Long等占用空间特别大的数据对象时，为了降低日志的产生量及其对数据库整体性能的影响，其在数据库日志中只记录一个标识说明该字段发生了变化，但并不将该字段的Before Image和After Image真正写入日志，然后直接将新数据写到数据库覆盖原来的旧值；OGG在进展数据复制时，为了能够使目标数据与源端保持一致，必须要在Trail里面写入update以后

41、该字段after image的实际值，由于这些信息在日志文件中是没有的，OGG就会根据日志中记录的信息到数据库中去查询该大字段的实际值，将这个从数据库中获取的值放到队列文件中，日志文件是没有这个实际值的。由于这些对象非常大，也就导致OGG的队列文件会比日志增加了很多倍。队列文件具体增大的倍数决定于特定时间段的大对象更新频率和每个大对象的实际值，实际应用中较难准确计算，可以根据实际运行统计值对队列所需空间进展估算。综上所述，队列文件较大完全是正常现象，数据全部能够正常入库也证实了我们的判断。3)解决方案针对队列较大，可能引起空间不够的问题，以下为可选方案，可以根据各网省具体情况选择其中一个或者两

42、个：缩短保存队列的时间可以调节OGG自动删除队列间的参数，缩短保存队列的时间。例如，在MGR的参数里面：PURGEOLDE*TRACTS /ggs/dirdat/ *, USECHECKPOINTS, MINKEEPHOURS 96其中，MINKEEPHOURS表示要保存队列的最小时间。如果当前为96，表示至少会保存4天的队列；经过观察现有磁盘空间大约可以满足2天多的队列，则可以修改为48。修改后需重启MGR使新参数生效。MGR进程会自动删除超过指定时间的队列。本方法在源和目标均适用。说明：USECHECKPOINTS 表示OGG删除队列时必须要保证该队列已经被使用过了，那些没有被应用过的队列

43、即使超过规定时间也是不会被自动删除的。扩大磁盘空间如果本地磁盘尚有空余，可以考虑为OGG增加磁盘空间。本方法在源和目标均适用。对磁盘空间进展监控可以通过监控工具或脚本定时监控OGG所在位置的磁盘使用率，一旦到达即报警，交由相应人员改变保存队列策略或人工处理。5.7OGG的E*tract进程占用存较大1)现象源端的E*tract进程有占用较大存。2)原因分析OGG的E*tract占用的存包括两局部：一局部用来存储复制表的构造等相关数据字典信息。此局部跟表的数量有关，但总量一般在几十兆以，无需特别关注；另外一局部用来存储当前数据库中所有未提交的交易数据，当事务提交后OGG会将存中的数据写入Trai

44、l，然后释放存。这是*些时候OGG的E*tract进程占用存较多的主要原因。为了防止所需存总量超过实际物理存，OGG提供了cachemgr参数，可以在存不够时使用本地硬盘作为缓存。举例如下：CACHEMGR CACHESIZE 500MB, CACHEDIRECTORY /ggs/temp, CACHEDIRECTORY /ggs2/temp本例中，如果OGG的E*tract进程所需存超过了500M，则会将交易数据写到指定的两个位置下作为虚拟存。一旦这些交易提交，则会将这些虚拟存与存同样去除。注：不推荐设置该参数时，默认OGG会将允许使用的存64位系统设置为8G，32位系统为2G。默认的虚拟存

45、空间为安装目录下的dirtmp。3)排查方法与解决方案一旦出现E*tract报告存问题，各网省可根据以下步骤进展排查和选择解决方案：排查操作系统对于存的限制在主机上使用ulimit a查看OGG运行用户一般为oracle用户在操作系统级的资源允许状况，例如：time(seconds) unlimitedfile(blocks) unlimiteddata(kbytes) unlimitedstack (kbytes) unlimitedmemory(kbytes) unlimitedcoredump(blocks) 4194303nofiles(descriptors) 15000这些限制的配

46、置一般在/etc/security/limits文件里，建议将其中的data/stack/memory都设置为unlimited(-1)，至少要保证该配置可以让OGG使用cachemgr所允许的最大存，可以联系系统管理员予以调整。调整cachemgr参数如果物理存有限，而本地磁盘尚有空余，可以减小OGG的cachemgr参数中的CACHESIZE，如原来允许使用2G，现在可以修改为1G，不够可以去使用硬盘作为虚拟存。注：由于IO方面硬盘和存差距较大，使用硬盘作为虚拟存会带来性能方面的下降。尝试重启E*tract进程查看存使用OGG本身有自动调节资源占用的特性，即如果系统本身空闲，则其会自动申请

47、更多资源加速数据复制；而如果系统资源紧，则会释放局部资源给优先级更高的进程。如果想尽快了解E*tract进程存占用是否正常，可以尝试重启进程，观察其存占用是否正常。注意：重启E*tract时检验其所需的归档日志是否存在，具体方法参照运维文档中停顿OGG进程的步骤。添加物理存如果系统日常业务繁忙阶段现有物理存占用率非常高，则建议对系统进展存扩容。在资源紧情况下运行OGG数据复制会对业务系统的性能带来不利影响。申请技术支持如经过以上排查仍然无法排除存相关问题，可以联系Oracle的支持工程师或在技术支持上填写SR，依据技术支持人员要求的步骤提供相关的信息，协助尽快完成问题界定和解决。5.8OGG的

48、Replicat进程占用存较大1)现象目标端的Replicat进程有占用较大存。2)原因分析OGG的Replicat负责将队列文件中的数据读取出来然后投递到目标数据库，由于每个Replicat进程处理交易依次进展的，其占用的存决定于队列中的交易大小。但是OGG的Replicat进程本身在申请到存后，并不一定随着事务的mit立即释放，同E*tract一样在系统资源较为充足时，其会试图保存一定时间，而发现系统资源紧时又会释放掉局部资源。默认情况下，OGG是严格按照源端产生的交易依次进展提交，本身不改变交易的边界，但是有时候为了防止大交易需要读取大量队列文件以及在目标端数据投递需要大量资源，OGG提

49、供了MA*TRANSOPS参数用于将大交易拆分为较小的交易屡次提交，除去性能的提升外还能让管理人员更为实时的看到数据投递的变化。例如：MA*TRANSOPS 1000表示如果单个交易中的实际数据变化量超过了1千，replicat会每1千条进展一次提交。由于OGG的队列中全部是提交了的交易，使用此参数后只是交易被拆分为了多个依次提交，并不改变数据变化的顺序，所以对一致性并不影响。需要注意的是使用MA*TRANSOPS时，如果出现了系统异常如目标数据库宕机，有可能出现Replicat的检查点还处在交易开场点，但实际已经投递到大交易的中间*个点了，这样再次重启会报告一些数据错误。此时可以通过使用re

50、perror default,discard将这些冲突数据写入discard文件，等待追上后再去验证这局部数据在两端是否一致，一般情况下不需要重新初始化，如有问题可以联系技术支持予以协助。说明：OGG的GROUPTRANSOPS参数会将小交易合并为大一些的交易进展提交，也会改变交易边界，但一般不对资源要求产生较大影响3)排查方法与解决方案一旦出现Replicat报告存问题或出现异常，各网省可根据以下步骤进展排查和选择解决方案：排查操作系统对于存的限制在主机上使用ulimit a查看OGG运行用户一般为oracle用户在操作系统级的资源允许状况，例如：time(seconds) unlimite

51、dfile(blocks) unlimiteddata(kbytes) unlimitedstack (kbytes) unlimitedmemory(kbytes) unlimitedcoredump(blocks) 4194303nofiles(descriptors) 15000这些限制的配置一般在/etc/security/limits文件里，建议将其中的data/stack/memory都设置为unlimited(-1)，至少要保证该配置可以让OGG使用最大交易所允许的最大存，可以联系系统管理员予以调整。对于大交易配置MA*TRANSOPS参数当遇到较大交易时，OGG需要大量的时间读

52、取所有交易数据信息，然后一次性投递到目标库。配置MA*TRANSOPS参数可以在遇到大交易时无需等待读完所有的交易数据再提交，能够提高性能的同时使监控人员在短时间看到复制的进展。按照经历，一般MA*TRANSOPS配置为1000以下，如果处理的表列比拟多或者列很长，可以设置为几百甚至几十。MA*TRANSOPS 500尝试重启Replicat进程查看存使用OGG本身有自动调节资源占用的特性，即如果系统本身空闲，则其会自动申请更多资源加速数据复制；而如果系统资源紧，则会释放局部资源给优先级更高的进程。如果想尽快让Replicat进程存释放，可以尝试重启进程，观察其存占用是否正常。添加物理存如果系

53、统日常业务繁忙阶段目标库现有物理存占用率非常高，则建议对系统进展存扩容满足复制的资源要求。申请技术支持如经过以上排查仍然无法排除存相关问题，可以联系Oracle的支持工程师或在技术支持上填写SR，依据技术支持人员要求的步骤提供相关的信息有时需要翻开进程的trace，协助尽快完成问题界定和解决。5.9关于handlecollisions的说明1)问题描述前期国网局部网省使用了handlecollisions参数，希望能够了解该参数与数据一致性的关系。2)问题说明在前期的文档和实施模板中，Oracle从未建议使用Handlecollisions参数。该参数的使用仅限于当所有表均有主键、且无法使用s

54、号进展一致的数据初始化时才可以使用，它可以根据主键对E*tract抽取的时间点和备份之间点之间的数据重合进展自动的处理，例如忽略*些错误。所以，在正常复制过程中，如果翻开了该参数，则会忽略error mapping数据错误，而且不会报告到discard文件，所以除非认定可以忽略这些数据不一致错误，否则绝对不建议使用handlecollisions参数！Oracle始终建议第一选择是停机初始化，第二选择是使用rman或者带s号的e*p/imp做不停机的一致性初始化，这两种方法均不需要使用handlecollisions参数，具体方法请参照Oracle提供的模板文档*省Oracle数据复制实施方案

55、。5.10Discard掉的数据如何处理1)问题描述对于*些replicat进程将不能正确复制的数据写入到了discard文件中，需要了解如何对这些discard掉的数据进展处理。2)问题说明Oracle建议在replicat中设置错误处理为默认的出错即停的方式，即：reperror default,abend此种模式下，只要出错进程就会abend，然后监控人员可以根据报告文件和discard文件中的错误信息对错误进展定位，经修复后重启进程，如此可以保证两端数据的严格一致。如果有的replicat将错误处理模式设置成了reperror default,discard模式，则会数据出错后只是将错

56、误数据丢到discard文件里面，然后继续下面的处理。由于后继的数据复制还在继续，此时discard中丧失的数据已经无法被恢复，只能将discard文件中所有出错的表进展重新初始化，具体方法请参照运维方案第3.2节。reperror default还有一个ignore模式，该模式是忽略所有错误继续运行，不会留下任何错误信息，一定不要使用！5.11生产端I/O性能问题1)问题描述等地出现了源系统I/O压力较大的情况，在此予以说明。2)问题说明OGG对于源端的I/O压力主要表达在：主E*tract进程对于数据库日志文件的轮询读；主E*tract进程对于其检查点文件的定时写；主E*tract对于本地

57、队列的写；Data Pump对于本地队列的读；根据调查和我们的经历， IO压力大的原因就在于配置了过多的主E*tract进程，大量主E*tract进程对于数据库日志文件的读造成系统IO压力过大。其解决方案包括：3)问题解决最正确方案重新对OGG进展配置，减少e*tract的数量。一般主E*tract的处理能力比拟强，依据硬件平台不同每小时处理20-50G日志是没有问题的，所以一般只需配置1-3个主E*tract.OGG数据复制的瓶颈主要在于目标端的replicat进程，可以在目标端对replicat进程进展拆分提高投递性能，但源端的E*tract并不需要如此拆分。4)问题解决可选方案(效果可能

58、有限)可以通过对OGG的主E*tract进程加大轮询日志间隔来降低IO占用:EOFDELAY 5 /将轮询日志的时间设置为5秒，默认为1秒CHECKPOINTSECS 20 /将写检查点的时间设置为20秒，默认为10秒这两个参数对于data Pump同样有效，关于这两个参数的更多信息可以参考OGG的参考手册。注意调节这两个参数可能会使数据复制的延迟相应增大假设干秒。5.12CSN取值问题1)问题描述RMAN在线备份恢复方式进展数据库初始化，容灾端第一次启动rep进程的CSN采用归档文件最后的S号，但仍会有error mapping的报错？用导入导出的方式从新初始化*个表的话，该如何启动进程才能

59、保证数据的一致性，停业务是不可能的？在map中修改*个表从*个csn开场抽取的话，如何去这个csn的值，是否是datafile_header中的？。2)说明关于Rman初始化的步骤，可以参照我们的实施方案模板，里面有具体的操作步骤，包括如何去csn号，只要目标恢复到的s号与replicat启动的s号是一致的就不应该有数据冲突。但是需要排除以下可能导致数据修改的因素：数据库是否有在的job在目标端运行；操作系统是否有定时任务在修改数据；目标数据库的trigger是否全部被禁用了；目标库的外键是否被全部禁用；建议锁定目标库的除OGG以外所有数据库用户，防止其修改数据。等等，这些因素可能会导致目标本

60、身数据发生变化，产生与源端数据变化的冲突。5.13两端数据不一致的排查与解决5.13.1现象在执行数据比照过程中，局部网省的业务系统中发现有局部表在两端的记录是不一致的。5.13.2原因分析与排查两端出现数据不一致的原因非常多，下面是比照结果有差异的一些可能性因素：1)数据复制本身的延时由于源端数据可能一直在变化，而比照只能取当时时间的数据，两端取出来的数据有一定差异，所以有可能带来比照结果不一致。此时并不一定是复制出现问题，可以针对这些不一致的记录做进一步的观察，过一段时间进展再确认。2)目标库数据库部存在部导致修改数据的对象和机制可能包括数据库中的对象：如没有被制止的trigger、自动运行的job等。3)操作系统上的job Sch