GoldenGate日常维护操作

OracleGoldenGate日常运维手册2.4 OGG日常监控 OGG常用监控命令 启动GoldenGate进程1) 首先以启动GoldenGate进程的系统用户〔一般为oracle〕登录源系统。2) 进入GoldenGate安装目录，执行./ggsci进入命令行模式。3) 启动源端管理进程GGSCI>startmgr4) 同样登陆到目标端GoldenGate安装目录，执行./ggsci，然后执行GGSCI>startmgr启动管理进程。5) 在源端执行GGSCI>starter*启动所有进程6) 同样登录到备份端执行GGSCI>starter*启动所有进程7) 使用GGSCI>infoer*或者GGSCI>info<进程名>观察进程状态是否为Running〔表示已经启动〕。注意有的进程需要几分钟起来，请重复命令观察其启动状态。说明：无论源还是目标，启动各extract/replicat进程前需要启动mgr进程。8) start命令的一般用法是：? start<进程名称>如：GGSCI>startextdm启动一个名叫extdm的进程；? 也可以使用通配符，如：GGSCI>starter*启动所有的extract和replicat进程；GGSCI>startextract*d*启动所有的包含字符‘d’extract进程；? GGSCI>startreplicatrep*启动所有以“rep“开头的replicat进程 停止GoldenGate进程依照以下步骤停止GoldenGate进程：1) 以启动GoldenGate进程的系统用户〔一般为oracle〕登录源主机，进入GoldenGate安装目录执行./ggsci进入命令行管理界面2) (**注：本步骤仅针对抽取日志的主extract进程，datapump进程和replicat进程不需要本步骤)验证GoldenGate的抽取进程重起所需的日志存在，对各个主extXX进程，执行如下命令：ggsci>infoextXX,showch…..ReadCheckpoint#1….RecoveryCheckpoint(positionofoldestunprocessedtransactioninthedatasource):Thread#:1Sequence#:9671RBA:239077904Timestamp:2023-05-2011:39:07.000000SCN:2195.1048654191RedoFile:NotavailableCurrentCheckpoint(positionoflastrecordreadinthedatasource):Thread#:1Sequence#:9671RBA:239377476Timestamp:2023-05-2011:39:10.000000SCN:2195.1048654339RedoFile:NotAvailableReadCheckpoint#2…..RecoveryCheckpoint(positionofoldestunprocessedtransactioninthedatasource):Thread#:2Sequence#:5287RBA:131154160Timestamp:2023-05-2011:37:42.000000SCN:2195.1048640151RedoFile:/dev/rredo07CurrentCheckpoint(positionoflastrecordreadinthedatasource):Thread#:2Sequence#:5287RBA:138594492Timestamp:2023-05-2011:39:14.000000SCN:2195.1048654739RedoFile:/dev/rredo07…..首先观察RecoveryCheckpoint所需要读取的最古老日志序列号，如举例中的实例1需要日志9671及其以后所有归档日志，实例2需要序列号为5287及以后所有归档日志，确认这些归档日志存在于归档日志目录后才可以执行下一步重起。如果这些日志已经被删除，那么下次重新启动需要先恢复归档日志。注意：对于OGG11及以后版本新增了自动缓存长交易的功能，缺省每隔4小时自动对未提交交易缓存到本地硬盘，这样只需要最多8个小时归档日志即可。但是缓存长交易操作只在extract运行时有效，停止后不会再缓存，此时所需归档日志最少为8个小时加上停机时间，一般为了保险起见建议确保重启时要保存有12个小时加上停机时间的归档日志。1) 执行GGSCI>stoper*停止所有源进程，或者分别对各个进程执行stop<进程名>单独停止。2) 以oracle用户登录目标系统，进入安装目录/oraclelog1/goldengate，执行./ggsci进入命令行。3) 在目标系统执行stoper*停止复制4) 在两端进程都已停止的情况下,如需要可通过stopmgr停止各系统内的管理进程。类似的，stop命令具有跟start命令一样的用法。这里不再赘述。注意，如果是只修改抽取或者复制进程参数，那么不需要停止MGR。不要轻易停止MGR进程，并且慎重使用通配符er*，以免对其他复制进程造成不利影响。 查看参数设置使用viewparams<进程名>可以查看进程的参数设置。该命令同样支持通配符*。 查看进程状态使用info<进程名称>命令可以查看进程信息。可以查看到的信息包括进程状态、checkpoint信息、延时等。如：还可以使用info<进程名称>detail命令查看更详细的信息。包括所使用的trail文件，参数文件、报告文件、警告日志的位置等。如：使用info<进程名称>showch命令可以查看到详细的关于checkpoint的信息，用于查看GoldenGate进程处理过的事务记录。其中比拟重要的是extract进程的recoverycheckpoint，它表示源数据中最早的未被处理的事务；通过recoverycheckpoint可以查看到该事务的redolog位于哪个日志文件以及该日志文件的序列号。所有序列号比它大的日志文件，均需要保存。 查看延时GGSCI>lag<进程名称>可以查看详细的延时信息。如： 查看统计信息GGSCI>stats<进程名称>,<时间频度>,table<ownername>.<tablename>可以查看进程处理的记录数。该报告会详细的列出处理的类型和记录数。如：GGSCI>statsedr,total列出自进程启动以来处理的所有记录数。GGSCI>statsedr,daily,tablegg.test列出当天以来处理的有关gg.test表的所有记录数。 查看运行报告GGSCI>viewreport<进程名称>可以查看运行报告。如：也可以进入到<GoldenGate安装目录>/dirrpt/目录下， Logdump使用指引1) 在GGSCI中使用如下命令查看当前处理的队列文件和RBA号，例如：GGSCI>infoREPYXA2) 在GoldenGate安装目录执行logdump命令3) 翻开要查看的队列文件Logdump>open./dirdat/p1000556CurrentLogTrailis./dirdat/p1000556Logdump>ghdronLogdump>detailonLogdump>detaildataLogdump>usertokenonLogdump>pos59193235上面INFO命令看到的RBA号码Logdump>n输入n显示当前处理的表及相关操作再次输入n，显示下一条记录，如果要跳过当前记录，方法如下：GGSCI>alterREPYXAextseqno556,extrba上面再次输入n看到的下一个RBA号，其中556为上面INFO看到的队列文件，0之后的数字4) 翻开下一个队列文件Logdump>NEXTTRAIL5) 使用logdump查看SCN号Logdump>ggstokendetail只有在事务开始的RBA号，才记录对应的SCN号和TransactionID，例如如下：如果进程出现问题，可以找到在处理那个事务时出现问题，修改良程提前到该事务之前的时间点进行重新抽取，然后从找到的SCN号启动replicat进程，例如：GGSCI>startrep_xxxATCSN40243326) 使用COUNT统计队列文件中包含的记录条数按时间点统计Logdump>COUNTSTART2006-01-1112:00:00,END2006-01-1212:00:00统计ls开头的每个队列文件包含的条数Logdump>COUNTLOGls*Logdump>COUNTDETAILLogdump>7) 使用FilterLogdump>FILTERINCLUDEFILENAMESchema.table_nameLogdump>COUNT查看队列文件中，包含该表的记录条数Logdump>FILTERINCLUDETRANSIND<>10=startoftransaction1=middleoftransaction2=endoftransaction3=onlyrecordintransaction可以统计队列文件中的事务，可以利用该命令查找事务开始点，如果没有开始的事务，直接找上一个文件即可。2.5 OGG日常运维任务 配置自动删除队列1) 进入安装目录执行./ggsci；2) 执行editparammgr编辑管理进程参数，参加或修改以下行purgeoldextracts/<goldengate安装目录>/dirdat/*,usecheckpoint,minkeepdays7其中，第一个参数为队列位置，*可匹配备份中心所有队列文件；第二个参数表示是首先要保证满足检查点需要，不能删除未处理队列；第三个参数表示最小保存多少天，后面的数字为天数。例如，如果希望只保存队列/ggs/dirdat/xm文件3天，可以配置如下：purgeoldextracts/ggs/dirdat/xm,usecheckpoint,minkeepdays33) 停止MGR进程，修改好参数后重启该进程GGSCI>stopmgrGGSCI>startmgr注：临时停止mgr进程并不影响数据复制。 配置启动MGR时自动启动Extract和Replicat进程1) 进入安装目录执行./ggsci；2) 执行editparammgr编辑管理进程参数，参加以下行AUTOSTARTER*3) 停止MGR进程，修改好参数后重启该进程GGSCI>stopmgrGGSCI>startmgr注意：一般建议不用自动启动，而是手工启动，便于观察状态验证启动是否成功，同时也便于手工修改参数。 配置MGR自动重新启动Extract和Replicat进程GoldenGate具有自动重起extract或者replicat进程的功能，能够自动恢复如网络中断、数据库临时挂起等引起的错误，在系统恢复后自动重起相关进程，无需人工介入。1) 进入安装目录执行ggsci进入命令行界面；2) 执行editparammgr编辑管理进程参数，参加以下行AUTORESTARTER*,RETRIES3,WAITMINUTES5,RESETMINUTES60以上参数表示每5分钟尝试重新启动所有进程，共尝试三次。以后每60分钟清零，再按照每5分钟尝试一次共试3次。3) 停止MGR进程，修改好参数后重启该进程，使修改后的参数文件生效GGSCI>stopmgrGGSCI>startmgr 长事务管理在停止抽取进程前需要通过命令检查是否存在长交易，以防止下次启动无法找到归档日志：ggsci>infoextXX,showch 查看长交易的方法Ggsci>sendextract<进程名>,showtrans[threadn][countn]其中，<进程名>为所要观察的进程名，如extsz/extxm/extjx等；Threadn是可选的，表示只查看其中一个节点上的未提交交易；Countn也是可选的，表示只显示n条记录。例如,查看extsz进程中节点1上最长的10个交易，可以通过以下命令：Ggsci>sendextractextsz,showtransthread1count10输出结果是以时间降序排列的所有未提交交易列表，通过xid可以查找到对应的事务，请应用开发商和DBA帮助可以查找出未提交原因，通过数据库予以提交或者回滚后GoldenGate的checkpoint会自动向前滚动。 使用GoldenGate命令跳过或接受长交易的方法在GoldenGate中强制提交或者回滚指定事务，可以通过以下命令〔<>中的为参数〕：Ggsci>SENDEXTRACT<进程名>,SKIPTRANS<5.17.27634>THREAD<2>//跳过交易Ggsci>SENDEXTRACT<进程名>,FORCETRANS<5.17.27634>THREAD<1>//强制认为该交易已经提交说明：使用这些命令只会让GoldenGate进程跳过或者认为该交易已经提交，但并不改变数据库中的交易，他们依旧存在于数据库中。因此，强烈建议使用数据库中提交或者回滚交易而不是使用GoldenGate处理。 配置长交易告警可以在extract进程中配置长交易告警，参数如下所示：extractextsz……warnlongtrans12h,checkintervals10mexttrail/backup/goldengate/dirdat/sz….以上表示GoldenGate会每隔10分钟检查一下长交易，如果有超过12个小时的长交易，GoldenGate会在根目录下的ggserr.log里面参加一条告警信息。可以通过观察ggserr.log或者在ggsci中执行viewggsevt命令查看这些告警信息。以上配置可以有助于及时发现长交易并予以处理。说明：在OGG11g中，extract提供了BR参数可以设置每隔一段时间〔默认4小时〕将长交易缓存到本地硬盘〔默认dirtmp目录下〕，因此extract只要不停止一般需要的归档日志不超过8个小时〔极限情况〕。但是如果extract停掉后，便无法再自动缓存长交易，需要的归档日志就会依赖于停机时间变长。 Trace收集方法1) GoldenGate在出现问题时，在Support网站创立SR之后，研发部门会要求收集相关的trace文件，并上传到ftp.oracle网站。trace收集方法如下：2) 根据进程名称将下面的xml文件改名，命名格式为：gglog-XXX.xml，例如：gglog-EXTYB.xml3) 将该文件拷贝到GoldenGate安装目录4) 注释掉manager参数文件中的AUTOSTART和AUTORESTART5) 启动出现错误的进程：GGSCI>stratXXX6) 运行直至进程abend7) 4 OGG性能优化方法从根本上讲，OGG复制性能和要复制的表是否存在主键和唯一索引有很大关系，所以从应用系统开发商对表结构的标准更为有效，请参见“2国网应用系统开发标准〞。OGG调优通常采用拆分进行的方式，拆分方法如下所述。4.1 Extract拆分方法1) 停止extract进程2) 停止datapump、进程GGSCI>INFOdatapump_nameEXTRACTDPEFLastStarted2023-01-2812:34StatusRUNNINGCheckpointLag00:00:00(updated00:00:05ago)LogReadCheckpointFile./dirdat/ef0000102023-01-2812:47:45.000000RBA148645直至RBA号不变化，才能停止3) 停止replicat进程GGSCI>INFOreplicat_nameREPLICATRPEFLastStarted2023-01-2812:30StatusRUNNINGCheckpointLag00:00:00(updated00:00:05ago)LogReadCheckpointFile./dirdat/ef0000062023-01-2812:47:45.000000RBA149258直至RBA号不变化，才能停止4) 记录extract检查点Extract检查点包括：RecoveryCheckpoint和CurrentCheckpointGGSCI>INFOextract_name,SHOWCHEXTRACTEXEELastStarted2023-01-2809:58StatusSTOPPEDCheckpointLag00:00:00(updated00:01:02ago)LogReadCheckpointOracleRedoLogs2023-01-2810:02:16Seqno26,RBA7090688CurrentCheckpointDetail:ReadCheckpoint#1OracleRedoLogStartupCheckpoint(startingpositioninthedatasource):Sequence#:26RBA:289296Timestamp:2023-01-2809:27:31.000000RedoFile:C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02.LOGRecoveryCheckpoint(positionofoldestunprocessedtransactioninthedatasource):Sequence#:26RBA:7088144Timestamp:2023-01-2810:02:16.000000RedoFile:C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02.LOGCurrentCheckpoint(positionoflastrecordreadinthedatasource):Sequence#:26RBA:7090688Timestamp:2023-01-2810:02:16.000000RedoFile:C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02.LOGWriteCheckpoint#1GGSLogTrailCurrentCheckpoint(currentwriteposition):Sequence#:11RBA:31609Timestamp:2023-01-2810:02:19.072000ExtractTrail:./dirdat/eeHeader:Version=2RecordSource=AType=4#InputCheckpoints=1#OutputCheckpoints=1FileInformation:BlockSize=2048MaxBlocks=100RecordLength=2048CurrentOffset=0Configuration:DataSource=3TransactionIntegrity=1TaskType=0Status:StartTime=2023-01-2809:58:34LastUpdateTime=2023-01-2810:02:19StopStatus=GLastResult=4005) 修改原有相应的参数文件，将拆分出的表从参数文件中删除6) 增加新的extract，datapump和replicat--source--------------------------------------------------GGSCI(win2k364)15>addextexef,tranlog,beginnowGGSCI(win2k364)16>addexttrail./dirdat/ef,extexef,megabytes50GGSCI(win2k364)17>addextdpef,exttrailsource./dirdat/efGGSCI(win2k364)18>addrmttrail./dirdat/ef,extdpef,megabytes50--target--------------------------------------------------GGSCI(win2k364)21>addreprpef,exttrail./dirdat/ef7) 修改新增extract进程的检查点检查点为上面记录的两个检查点：currentreadcheckpointandrecoverycheckpoint--修改currentreadcheckpointGGSCI(win2k364)30>alterexefextseqno26,extrba7090688[,threadn]EXTRACTaltered.--修改recoverycheckpointGGSCI(win2k364)4>alterexefioextseqno26,ioextrba7088144[,threadn]2023-01-2810:46:18INFOOGG-00989WARNING:Unsupportedoperation.Thismightcausetransactionalinconsistency.Modifyingiocheckpoint:ioseq=26iorba=7088144.Areyousureyouwanttocontinue?yEXTRACTaltered.8) 确认所有参数文件正确，启动进程即可4.2 Datapump和replicat拆分方法下面以拆分replicat为例，datapump拆分方法相同。1) 停止replicat进程2) 查看检查点GGSCI>INFOreplicat_name,SHOWCH3) 修改原有参数文件，将拆分出的表删除4) 新增replicat，和拆分前的进程读取相同的队列文件5) 修改检查点6) GGSCI>alterreplicat_newextseqno6,extrba1492587) 确认所有参数文件无误，启动进程即可5 OGG异常处理预案5.1 异常处理一般步骤如果GoldenGate复制出现异常，可以通过以下步骤尝试解决问题：1) 通过ggsci>viewreport命令查找ERROR字样，确定错误原因并根据其信息进行排除；2) 通过ggsci>viewggsevt查看告警日志信息；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>editparammgrport7839autorestarter*,waitminutes3,retries5,RESETMINUTES60每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) 执行startmgr启动mgr；8) 执行starter*启动所有进程；检查各进程是否正常启动，即可进入正常复制。以上过程可以通过集成到CRS或HACMP等集群软件实现自动的切换，具体步骤请参照国网测试文档。5.4 Extract进程常见异常对于源数据库，抽取进程extxm如果变为abended，那么可以通过在ggsci中使用viewreport命令观察报告，可以通过搜索ERROR快速定位错误。一般情况下，抽取异常的原因是因为其无法找到对应的归档日志，可以通过到归档日志目录命令行下执行ls–ltarch_X_XXXXX.arc观察该日志是否存在，如不存在那么可能的原因是：1) 日志已经被压缩GoldenGate无法自动解压缩，需要人工解压缩后才能读取。2) 日志已经被删除如果日志已经被删除，需要进行恢复才能继续复制，请联系本单位DBA执行恢复归档日志操作。一般需要定期备份归档日志，并去除旧的归档日志。需要保证归档日志在归档目录中保存足够长时间之后，才能被备份和去除。即：定期备份去除假设干小时之前的归档，而不是全部归档。保存时间计算如下：某归档文件保存时间≥抽取进程处理完该文件中所有日志所需的时间可以通过命令行或者GoldenGateDirectorWeb界面，运行infoexXXshowch命令查看抓取进程exXX处理到哪条日志序列号。在此序列号之前的归档，都可以被平安的去除。如以下图所示：5.5 Replicat进程常见异常对于目标数据库，投递进程repXX如果变为abended，那么可以通过在ggsci中使用viewreport命令观察报告，可以通过搜索ERROR快速定位错误。复制进程的错误通常为目标数据库错误，比方：1) 数据库临时停机；2) 目标表空间存储空间不够；3) 目标表出现不一致。可以根据报告查看错误原因，排除后重新启动rep进程即可。需要注意一点：往往容易忽略UNDO表空间。如果DML语句中包含了大量的update和delete操作，那么目标端undo的生成速度会很快，有可能填满UNDO表空间。因此需要经常检查UNDO表空间的大小。5.6 抽取生成的队列文件比归档文件多1) 现象在国网多个网省的业务系统中出现了某一时间段内，OGG的抓取进程所产生的数据队列远远大于Oracle数据库所产生的归档日志，导致OGG队列存放位置空间不够用。2) 原因分析OGG本身是解析数据库的归档日志并从中获取有效的数据变化，在一般情况下其所抽取出来的数据队列要小于归档日志产生量。但是，也有特殊情况，例如Oracle数据库在修改BLOB/CLOB/Long等占用空间特别大的数据对象时，为了降低日志的产生量及其对数据库整体性能的影响，其在数据库日志中只记录一个标识说明该字段发生了变化，但并不将该字段的BeforeImage和AfterImage真正写入日志，然后直接将新数据写到数据库覆盖原来的旧值；OGG在进行数据复制时，为了能够使目标数据与源端保持一致，必须要在Trail里面写入update以后该字段afterimage的实际值，由于这些信息在日志文件中是没有的，OGG就会根据日志中记录的信息到数据库中去查询该大字段的实际值，将这个从数据库中获取的值放到队列文件中，日志文件是没有这个实际值的。由于这些对象非常大，也就导致OGG的队列文件会比日志增加了很多倍。队列文件具体增大的倍数决定于特定时间段内的大对象更新频率和每个大对象的实际值，实际应用中较难精确计算，可以根据实际运行统计值对队列所需空间进行估算。综上所述，队列文件较大完全是正常现象，数据全部能够正常入库也证实了我们的判断。3) 解决方案针对队列较大，可能引起空间不够的问题，以下为可选方案，可以根据各网省具体情况选择其中一个或者两个：? 缩短保存队列的时间可以调节OGG自动删除队列间的参数，缩短保存队列的时间。例如，在MGR的参数里面：PURGEOLDEXTRACTS/ggs/dirdat/*,USECHECKPOINTS,MINKEEPHOURS96其中，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参数，可以在内存不够时使用本地硬盘作为缓存。举例如下：CACHEMGRCACHESIZE500MB,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参数用于将大交易拆分为较小的交易屡次提交，除去性能的提升外还能让管理人员更为实时的看到数据投递的变化。例如：MAXTRANSOPS1000表示如果单个交易中的实际数据变化量超过了1千，replicat会每1千条进行一次提交。由于OGG的队列中全部是提交了的交易，使用此参数后只是交易被拆分为了多个依次提交，并不改变数据变化的顺序，所以对一致性并不影响。需要注意的是使用MAXTRANSOPS时，如果出现了系统异常如目标数据库宕机，有可能出现Replicat的检查点还处在交易开始点，但实际已经投递到大交易的中间某个点了，这样再次重启会报告一些数据错误。此时可以通过使用reperrordefault,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以下，如果处理的表列比拟多或者列很长，可以设置为几百甚至几十。MAXTRANSOPS500? 尝试重启Replicat进程查看内存使用OGG本身有自动调节资源占用的特性，即如果系统本身空闲，那么其会自动申请更多资源加速数据复制；而如果系统资源紧张，那么会释放局部资源给优先级更高的进程。如果想尽快让Replicat进程内存释放，可以尝试重启进程，观察其内存占用是否正常。? 添加物理内存如果系统日常业务繁忙阶段目标库现有物理内存占用率非常高，那么建议对系统进行内存扩容满足复制的资源要求。? 申请技术支持如经过以上排查仍然无法排除内存相关问题，可以联系Oracle的支持工程师或在技术支持网站上填写SR，依据技术支持人员要求的步骤提供相关的信息〔有时需要翻开进程的trace〕，协助尽快完成问题界定和解决。5.9 关于handlecollisions的说明1) 问题描述前期国网局部网省使用了handlecollisions参数，希望能够了解该参数与数据一致性的关系。2) 问题说明在前期的文档和实施模板中，Oracle从未建议使用Handlecollisions参数。该参数的使用仅限于当所有表均有主键、且无法使用scn号进行一致的数据初始化时才可以使用，它可以根据主键对Extract抽取的时间点和备份之间点之间的数据重合进行自动的处理，例如忽略某些错误。所以，在正常复制过程中，如果翻开了该参数，那么会忽略errormapping数据错误，而且不会报告到discard文件，所以除非认定可以忽略这些数据不一致错误，否那么绝对不建议使用handlecollisions参数！Oracle始终建议第一选择是停机初始化，第二选择是使用rman或者带scn号的exp/imp做不停机的一致性初始化，这两种方法均不需要使用handlecollisions参数，具体方法请参照Oracle提供的模板文档《xx省Oracle数据复制实施方案》。5.10 Discard掉的数据如何处理1) 问题描述对于某些replicat进程将不能正确复制的数据写入到了discard文件中，需要了解如何对这些discard掉的数据进行处理。2) 问题说明Oracle建议在replicat中设置错误处理为默认的出错即停的方式，即：reperrordefault,abend此种模式下，只要出错进程就会abend，然后监控人员可以根据报告文件和discard文件中的错误信息对错误进行定位，经修复后重启进程，如此可以保证两端数据的严格一致。如果有的replicat将错误处理模式设置成了reperrordefault,discard模式，那么会数据出错后只是将错误数据丢到discard文件里面，然后继续下面的处理。由于后继的数据复制还在继续，此时discard中丧失的数据已经无法被恢复，只能将discard文件中所有出错的表进行重新初始化，具体方法请参照《运维方案》第3.2节。reperrordefault还有一个ignore模式，该模式是忽略所有错误继续运行，不会留下任何错误信息，一定不要使用！5.11 生产端I/O性能问题1) 问题描述山东等地出现了源系统I/O压力较大的情况，在此予以说明。2) 问题说明OGG对于源端的I/O压力主要表达在：? 主Extract进程对于数据库日志文件的轮询读；? 主Extract进程对于其检查点文件的定时写；? 主Extract对于本地队列的写；? DataPump对于本地队列的读；根据调查和我们的经验，IO压力大的原因就在于配置了过多的主Extract进程，大量主Extract进程对于数据库日志文件的读造成系统IO压力过大。其解决方案包括：3) 问题解决最正确方案重新对OGG进行配置，减少extract的数量。一般主Extract的处理能力比拟强，依据硬件平台不同每小时处理20-50G日志是没有问题的，所以一般只需配置1-3个主Extract.OGG数据复制的瓶颈主要在于目标端的replicat进程，可以在目标端对replicat进程进行拆分提高投递性能，但源端的Extract并不需要如此拆分。4) 问题解决可选方案(效果可能有限)可以通过对OGG的主Extract进程加大轮询日志间隔来降低IO占用:EOFDELAY5//将轮询日志的时间设置为5秒，默认为1秒CHECKPOINTSECS20//将写检查点的时间设置为20秒，默认为10秒这两个参数对于dataPump同样有效，关于这两个参数的更多信息可以参考OGG的参考手册。注意调节这两个参数可能会使数据复制的延迟相应增大假设干秒。5.12 CSN取值问题1) 问题描述RMAN在线备份恢复方式进行数据库初始化，容灾端第一次启动rep进程的CSN采用归档文件最后的SCN号，但仍会有errormapping的报错？用导入导出的方式从新初始化某个表的话，该如何启动进程才能保证数据的一致性，停业务是不可能的？在map中修改某个表从某个csn开始抽取的话，如何去这个csn的值，是否是datafile_header中的？。2) 说明关于Rman初始化的步骤，可以参照我们的实施方案模板，里面有具体的操作步骤，包括如何去csn号，只要目标恢复到的scn号与replicat启动的scn号是一致的就不应该有数据冲突。但是需要排除以下可能导致数据修改的因素：? 数据库是否有内在的job在目标端运行；? 操作系统是否有定时任务在修改数据；? 目标数据库的trigger是否全部被禁用了；? 目标库的外键是否被全部禁用；? 建议锁定目标库的除OGG以外所有数据库用户，防止其修改数据。等等，这些因素可能会导致目标本身数据发生变化，产生与源端数据变化的冲突。5.13 两端数据不一致的排查与解决 现象在执行数据比照过程中，局部网省的业务系统中发现有局部表在两端的记录是不一致的。 原因分析与排查两端出现数据不一致的原因非常多，下面是比照结果有差异的一些可能性因素：1) 数据复制本身的延时由于源端数据可能一直在变化，而比照只能取当时时间的数据，两端取出来的数据有一定差异，所以有可能带来比照结果不一致。此时并不一定是复制出现问题，可以针对这些不一致的记录做进一步的观察，过一段时间进行再确认。2) 目标库数据库内部存在内部导致修改数据的对象和机制可能包括数据库中的对象：如没有被禁止的trigger、自动运行的job等。3) 操作系统上的jobScheduler可能是存在操作系统上的job，可以检查其所有用户的crontab等自动任务管理器。4) OGG的错误处理模式设置OGG的replicat里面的错误处理模式默认为是abend模式，即只要有数据问题进程就会出错结合监控告警：REPERRORDEFAULT,ABEND该参数的其它配置包括DISCARD和IGNORE模式。如果是discard模式，那么出错会被写到discard文件里面，可以查找discardfile指定的该文件是否有出错记录；而如果是ignore模式那么会忽略所有错误，而且不记日志。请务必将Replicat错误处理机制设置为abend模式！仅仅在错误处理等特殊情况下配合技术支持使用DISCARD模式。5) 修改OGG的检查点人为修改OGG的检查点有可能带来数据不一致，包括使用alter命令修改主extract/datapump/replicat等。所有ggsci中对进程的操作记录都记录在ggserr.log里面，只要用户没有手工去除，可以通过对该文件进行分析观察是否修改正检查点。6) OGG配置的逻辑错误主要包括以下配置复制关系时的错误：? 所有Extract表的复制范围必须是互补的，且互不交叉的，不能存在需要复制但不包含在任何一个主extract中的情况；? DataPump的复制范围必须和主Extract保持一致；? Replicat的复制范围同样必须对应于主Extract和DataPump的所有表，且负责相同队列的各Replicat之间互补和无交集；7) OGG配置参数的正确性有时如果OGG的参数文件中语法问题也会造成数据不一致。例如：? 在Extract的table语法错误。正确语法：tableggs1.tcustmer;即table关键字+空格+schema.tablename+分号。? Replicat的map语句出现错误。正确语法：MAPggs1.TCUSTMER,TARGETggs2.TCUSTMER;即map关键字+空格+source_schema.source_tablename+逗号+空格+target关键字+source_schema.source_tablename+分号。如果写错格式会导致OGG无法将正确数据投递到目标表。? OGG的关键字前后、逗号前后建议参加空格〔英文，一定不要用全拼〕，一行的开头不用。OGG有时会将中间没有空格的多个关键字连在一起视作一个字符串。? 不可使用word等格式化工具编辑OGG参数然后上传，可能会带来比方空格、换行等问题。8) 其它可能导致数据不一致的因素如人工误操作。为了减少类似可能出现的问题，建议在日常灾备运行状态下目标数据库disable除去OGG的用户之外的其它所有用户，等接管时再重新enable。如果以上均没有问题，可以提供源库和目标库的以下资料，由技术支持进行分析：? OGG的ggserr.log? 所有的报告文件? 丧失数据的大致操作时间? 丧失数据相关时段的归档日志 解决方案根据不一致数据表的多少以及不一致数据的条数，可以采取以下方案：1) 人工补足少量的数据在确认只有局部表的假设干条数据不一致后，可以使用手工方法对不一致的数据进行重新再同步，即从源端找出当前的值，覆盖目标表的相关记录。本方法只适用于不一致数据较少的情况，如从discard文件中可以找到有限的出错记录。2) 执行局部表的初始化当其中某些表不同步，而数据条数较多时，可以对该局部表执行重新初始化，具体步骤参见运维文档的第5.5节。3) 全部重新初始化当大局部表出现不一致的情况时，需要对全库执行重新初始化，可以按照安装实施文档的步骤执行，之前请务必保证安装实施文档中的步骤正确性，如有问题可以联系技术支持。5.14 AIXGGSCI无法运行错误信息：CannotloadICUresourcebundle'ggMessage',errorcode2-NosuchfileordirectoryCannotloadICUresourcebundle'ggMessage',errorcode2-NosuchfileordirectoryIOT/Aborttrap(coredumped)或者ggsci可以启动，但是运行任何命令都报上面的错误。处理方法：通常使用已有的mount点安装GoldenGate，在mount时使用了并发CIO参数。新建文件系统，重新mount，作为GoldenGate安装目录。错误信息：$./ggsciexec():0509-036Cannotloadprogramggscibecauseofthefollowingerrors:0509-130Symbolresolutionfailedforggscibecause:0509-136Symbol_GetCatName__FiPCc(number158)isnotexportedfromdependentmodule/usr/lib/libC.a[ansi_64.o].0509-136Symbol_Getnumpunct__FPCc(number162)isnotexportedfromdependentmodule/usr/lib/libC.a[ansi_64.o].0509-136Symbol__ct__Q2_3std8_LocinfoFPCci(number183)isnotexportedfromdependentmodule/usr/lib/libC.a[ansi_64.o].0509-192Examine.loadersectionsymbolswiththe'dump-Tv'command.原因是XLC是6.0版本，升级XLC版本到10.1以上，问题解决5.15 HP-UXGGSCI无法运行错误信息：coredumped该问题只在HP-UX11.31上发现。处理方法：环境变量设置问题，参见“1.1操作系统环境变量〞小节错误信息：aCCruntime:Useof"-mt"mustbeconsistentduringbothcompilationandlinking.IOTcoredumped该问题在HP-UX11.23上发现，原因是没有C＋＋运行环境OnHP-UX11.23IA64,OracleGoldenGaterequiresaCC:HPaC++/ANSICB3910BA.06.05orneweraC++libraries.PHSS_34041ornewerisrequired.处理方法：安装补丁包5.16 OGG-xxxxx错误代码本节为ogg具体错误代码的问题处理方式 OGG-01296错误信息：WARNINGOGG-01154OracleGoldenGateDeliveryforOracle,repyxb.prm:SQLerror1403mappingSGPM.P_SMS_SENDtoSGPM.P_SMS_SEND.WARNINGOGG-01003OracleGoldenGateDeliveryforOracle,repyxb.prm:Repositioningtorba2509817inseqno1.ERROROGG-01296OracleGoldenGateDeliveryforOracle,repyxb.prm:ErrormappingfromSGPM.P_SMS_SENDtoSGPM.P_SMS_SEND.ERROROGG-01668OracleGoldenGateDeliveryforOracle,repyxb.prm:PROCESSABENDING.原因分析：由于源端进行了表结构更改，没有通知目标端，导致此错误处理方法：1) 先确认两端表结构是否一致2) 在源端查看附加日志是否enableGGSCI>INFOTRANDATAschema.table_name--返回应该是enable，如果不是，重新添加GGSCI>ADDTRANDATAschema.table_name3) 目标端数据库：触发器，约束，job等是否已经禁止4) 查看discard文件〔./dirrpt/xxx.dsc〕中的相关描述5) 使用logdump查看实际数据，分析原因 OGG-01154错误信息：2023-03-2915:53:57WARNINGOGG-01154OracleGoldenGateDeliveryforOracle,repya.prm:SQLerror14402mappingEPMA.D_METERtoEPMA.D_METEROCIErrorORA-14402:updatingpartitionkeycolumnwouldcauseapartitionchange(status=14402),SQL<UPDATE"EPMA"."D_METER"SET"PR_ORG"=:a1,"BELONG_DEPT"=:a2WHERE"METER_ID"=:b0>.处理方法：SQLPLUS>altertableSCHEMA.TABLENAMEenablerowmovement OGG-01088错误信息：ERROROGG-01088OracleGoldenGateDeliveryforOracle,pms_rep1.prm:malloc2097152bytesfailed.ERROROGG-01668OracleGoldenGateDeliveryforOracle,pms_rep1.prm:PROCESSABENDING.处理方法：1) ulimit-a，验证操作系统对用户是否所有资源都是无限制，参见1.3小节。2) 将进程进行拆分，拆分为多个进程。3) 从support.oracle下载最新的补丁包，升级GoldenGate。 OGG-01224错误信息：ERROROGG-01224OracleGoldenGateManagerforOracle,mgr.prm:NobufferspaceavailableERROROGG-01224OracleGoldenGateCaptureforOracle,dpema.prm:TCP/IPerror9(Badfilenumber).处理方法：修改mgr.prm，扩大动态端口范围，dynamicportlist7840-7914 OGG-01031错误信息：ERROROGG-01031Thereisaprobleminnetworkcommunication,aremotefileproblem,encryptionkeysfortargetandsourcedonotmatch(ifusingENCRYPT)oranunknownerror.(ReplyreceivedisExpected4bytes,butgot0bytes,intrail./dirdat/t1000026,seqno26,readingrecordtrailertokenatRBA103637218).2023-01-0611:04:16ERROROGG-01668PROCESSABENDING.原因分析〔1〕：可能是网络出现过故障，OGG源端的DataPump进程与目标断了联系，目标端mgr为其启动的server进程一直还在运行，下次datapump重启时目标mgr会试图生成另外一个server进程，这样两个进程会争同一个队列文件。处理方法：是停掉源端的所有datapump，使用ps–ef|grepserver〔或OGG安装目录〕看看是不是还有OGG的server进程在跑，如果有，杀死它〔一定要确认源端datapump全停掉，并且杀的是server进程，不要杀其它extract/replicat/mgr等〕，重启源端datapump即可。原因分析〔2〕：可能是目标端的trailfile出问题了，前滚重新生成一个新的队列文件处理方法：SENDEXTRACTxxxROLLOVER或者：alterextractxxxetrolloverxxx为datapump的名称 OGG-01072错误信息：ERROROGG-01072LOBROW_get_next_chunk(LOBROW_row_t*,BOOL,BOOL,BOOL,LOBROW_chunk_header_t*,char*,size_t,BOOL,*)Bufferoverflow,needed:132,alloc2.处理方法：1) 如果版本为.1Build078版本，升级到最新的补丁包2) 使用ulimit–a查看资源使用限制，调整资源为unlimited3) extract:DBOPTIONSLOBBUFSIZE<bytes>4) replicat:DBOPTIONSLOBWRITESIZE1MB OGG-01476错误信息：ERROROGG-01476Thepreviousrunabendedduetoanoutofordertransaction.IssueALTERETROLLOVERtoadvancetheoutputtrailsequencepastthecurrenttrailsequencenumber,thenrestart.Then,useALTEREXTSEQNOonthesubsequentpumpEXTRACT,orREPLICAT,processgrouptostartreadingfromthenewtrailfilecreatedbyALTERETROLLOVER;thedownstreamprocesswillnotautomaticallyswitchtothenewtrailfile.在初始化的时候，由于容灾端没有准备就绪，在生产端来回进行了很屡次的操作，导致生产端抽取混乱，此时在进行RMAN之前，重新启动抽取，忽略调之前的混乱信息。处理方法：RAC环境，查看时钟是否同步参数文件增加：THREADOPTIONSMAXCOMMITPROPAGATIONDELAY7000IOLATENCY70007000可以进行大小调整如果还有问题：alterextractxxx,etrollover##启动datapump进程后，datapump会报错，错误信息大致是进程当前的队列文件〔假设是65〕已经读完，但是找不到文件结尾标志，同时又发现新的队列文件〔假设是66〕已经生成。这个时候应该手工将datapump滚动到这个新的队列文件头〔66〕##修改DataPump从新的队列开始传输stop[pump_name]ALTEREXTRACT[pump_name],EXTSEQNO#####EXTRBA0start[pump_name]注：用实际的datapump进程名代替[pump_name]，用新的队列文件号代替#######重启DataPump查看是否能够重启成功并从新的队列传输##启动Replicat，观察其是否能够读取新传输过来的队列##如Replicat无法自动滚动到下一个队列，需要通过命令手工滚动stop[replicat_name]alterreplicat[replicat_name],EXTSEQNO#####EXTRBA0start[replicat_name]注：用实际的replicat进程名代替[replicat_name]，用新的队列文件号代替#######重新启动Replicat即可恢复正常复制 OGG-00850错误信息：ERROROGG-00850OracleGoldenGateCaptureforDB2,extxa.prm:DatabaseinstanceXP1hasbothUSEREXITandLOGRETAINsettooff.ERROROGG-01668OracleGoldenGateCaptureforDB2,extxa.prm:PROCESSABENDING.处理方法：如果是DB28.1/8.2，必须将USEREXIT和LOGRETAIN设置为ON。如果是DB29.5，已经使用LOGARCHMETH1和LOGARCHMETH2代替以上两个参数，通常LOGARCHMETH1为DISK，LOGARCHMETH2为TSM，采用这两个参数开启归档模式。在DB29.5中，USEREXIT可以设置为OFF，但是LOGRETAIN仍需设置为ON。因此LOGARCHMETH1需设置为LOGRETAIN，LOGARCHMETH2设置为OFF经过现场测试：LOGARCHMETH1=TSMandLOGARCHMETH2=OFF可以正常工作 OGG-01416错误信息：ERROROGG-01416OracleGoldenGateCaptureforOracle,dpeya.prm:File./dirdat/ya001542,withformatRELEASE9.0/9.5,doesnotmatchcurrentformatspecificationofRELEASE10.4/11.1.ModifytheparameterfiletospecifyformatRELEASE9.0/9.5orissueETROLLOVERpriortorestart.2023-03-1415:04:12ERROROGG-01668OracleGoldenGateCaptureforOracle,dpeya.prm:PROCESSABENDING.处理方法：ALTEREXTRACTxxxetrollover后续步骤参照OGG-01476进行处理。##启动datapump进程后，datapump会报错，错误信息大致是进程当前的队列文件〔假设是65〕已经读完，但是找不到文件结尾