[原创]XX公司Goldengate故障排除_MySQL, Oracle及数据库讨论区_Weblogic技术|Tuxedo技术|中间件技术|Oracle论坛|JAVA论坛|Linux/Unix技术|hadoop论坛_联动北方技术论坛  
网站首页 | 关于我们 | 服务中心 | 经验交流 | 公司荣誉 | 成功案例 | 合作伙伴 | 联系我们 |
联动北方-国内领先的云技术服务提供商
»  游客             当前位置:  论坛首页 »  自由讨论区 »  MySQL, Oracle及数据库讨论区 »
总帖数
1
每页帖数
101/1页1
返回列表
0
发起投票  发起投票 发新帖子
查看: 3446 | 回复: 0   主题: [原创]XX公司Goldengate故障排除        下一篇 
jie.liang
注册用户
等级:少校
经验:1003
发帖:77
精华:0
注册:2013-10-11
状态:离线
发送短消息息给jie.liang 加好友    发送短消息息给jie.liang 发消息
发表于: IP:您无权察看 2014-3-28 17:16:29 | [全部帖] [楼主帖] 楼主

第一部分问题描述

[问题一 源端系统重启后,抽取进程不能自动重启]

     在源端系统重启后,抽取进程不能自动启动,需要人工干预。

[问题二 Data Pump无法投递trail文件至target端]

     在Goldengate运行过程中,发现Data Pump进程出现abend状态,无法继续正常投递trail文件至目标端,告警日志中出现相关报错信息。

[问题三 源端与目标端数据同步过程中存在数据丢失]

     在Goldengate进程运行的过程中,出现部分数据未能成功投递至目标端。

第二部分问题分析

[问题一 源端系统重启后,抽取进程不能自动重启]

由于源端机房(沙特)电源问题,导致源端系统有时会发生重启。在源端系统正常启动后,抽取进程不能自动启动,需要通过手动的方式启动该进程。根据目前掌握的信息,初步判断是由于Goldengate的抽取进程与数据库启动顺序不同有关,即在启动抽取进程的过程中,数据库并未完全启动。

由于是windows 2003操作系统,在系统重启过程中,操作系统会通过服务启动数据库以及Goldengate manager进程,两个服务启动顺序不分先后。通过查看生产环境中,沙特端manager进程的配置参数,发现在该进程中,客户配置了自动启动抽取进程以及Data Pump进程的参数,如下所示:

AUTOSTART ER *


配置AUTOSTART参数,意味着成功启动manager进程后,Manager进程会启动抽取以及Data Pump进程。成功启动抽取进程,在这需要一个前提条件,即Goldengate可以成功访问数据库。由于启动Goldengate独立于启动数据库,因此在系统重启过程中,Goldengate的manager进程可能先于数据库启动,在成功启动manager进程后,接着启动抽取进程时,由于数据库尚未成功启动,Goldengate发现抽取进程无法访问数据库,因此无法自动启动。

[问题二 Data Pump无法投递trail文件至target端]

在源端goldengate告警日志中发现如下报错:

2012-11-15 10:17:19  GGS ERROR       112  Oracle GoldenGate Capture for Oracle, 00455008.prm:  There is a problem in network communication, a remote file problem, encryption keys for target and source do not match (if using ENCRYPT) or an unknown error. (Remote file used is /home/oracle/ggs/dirdat/ps000001, reply received is Unable to lock file "/home/oracle/ggs/dirdat/ps000001" (error 13, Permission denied). Lock currently held by process id (PID) 19901).
2012-11-15 10:17:19  GGS ERROR       190  Oracle GoldenGate Capture for Oracle, 00455008.prm:  PROCESS ABENDING.


根据现场环境的确认,进程00455008为源端的Data Pump进程。通过查询metalink,发现此问题是由于网络不稳定引起的。

发生这个报错的原因如下:

由于源端至目标端网络不稳定,导致源端Data Pump进程在投递trail文件过程中出现错误,并无法继续发送数据包至目标端,在这个过程中,目标端的Server/Collector进程会锁定trail文件,继续等待之前的Data Pump进程,当Data Pump进程恢复重新连接该trail文件时,Server/Collector进程会认为该进程不是之前的Data Pump,为了防止由于多个进程对一个trail文件操作造成数据不一致,Server/Collector进程会锁定该trail文件,以致其他新的Data Pump无法去锁定该trail文件,导致新的Data Pump进程没有权限去修改,并在源端的告警日志中出现以上的错误信息。具体可以参考MOS ID 1112506.1。

[问题三 源端与目标端数据同步过程中存在数据丢失]

经客户反应,在数据同步的过程中,有时会出现数据丢失的情况。通过看出生产环境中的配置发现,在目标端的replicat进程中,客户使用了HANDLECOLLISIONS参数,该参数的作用主要是控制当在目标端应用SQL时,是否让复制进程去自动处理记录重复和记录丢失的错误。该参数一般只用于数据初始化的时候。另外,在replicat进程中,也未配置discard参数,这使得在出现问题的时候,goldengate不能及时把对应的信息记录下来,造成数据丢失。

第三部分解决方案

[问题一 源端系统重启后,抽取进程不能自动重启]

针对第一个问题,目前在生产环境中的源端manager进程中,配置delayminutes参数。这个参数只能用于windows系统,它能延迟manager进程启动时间。在windows系统重新后,系统通过GoldenGate服务启动manager进程时,通过该参数可以延时启动。等待系统完整启动,数据库服务成功启动后,再去启动GoldenGate相关进程。

BOOTDELAYMINUTES 5


目前已经完成该参数的配置,等到下一次出现系统重启后,需要观察抽取进程是否能成功启动。

[问题二 Data Pump无法投递trail文件至target端]

针对第二个问题,需要在源端的Data Pump进程中配置如下参数:

rmthost 10.30.13.49, MGRPORT 7809, COMPRESS, PARAMS "-w 30"


通过配置PARAMS "-w 30"参数,可以告诉目标端的Server/Collector进程,如果没有从源端接受任何checkpoint信息超过30秒,该Server/Collector进程,将自动关闭,并通过新的Server/Collector恢复数据的投递与接收。

由于支持该参数的GoldenGate版本是10.4.0.29以上,鉴于目前生产环境目标端的GoldenGate是10.4.0.19。与客户沟通后准备对目标端的GoldenGate软件进行升级。

升级大致步骤如下:

1.  检查操作系统以及数据库版本

目标端OS: Redhat4.7

目标端DB: 10.2.0.4

2.  下载升级所需的介质:p12776606_1040_Linux-x86-64.zip

3.  停止源端Data Pump进程以及目标端manager、replicat进程

4.  备份目标端GoldenGate安装目录

5.  为目标端GoldenGate安装目录下的文件添加写权限

6.  chmod +w *

7.  解压p12776606_1040_Linux-x86-64.zip至目标端GoldenGate安装目录

8.  启动相应进程并查看日志

在升级过程中,发现目标端replicat进程未成功添加checkpoint表,做如下修改:

编辑GLOBALS参数

GGSCI> edit params ./GLOBALS
GGSCHEMA ggs
CHECKPOINTTABLE ggs.checkpt


查看该进程seqno以及RBA号

GGSCI> info replicat p6srep


删除该replicat进程

GGSCI> dblogin userid ggs, password ggs
GGSCI> delete replicat p6srep


重新添加replicat进程,并指定启动位置

GGSCI> add replicat p6srep,exttrail /home/oracle/ggs/dirdat/ps, checkpointtable ggs.checkpt
GGSCI> ALTER REPLICAT P6SREP EXTSEQNO 3, EXTRBA 518


重新启动

GGSCI> start replicat p6srep


在全部完成以后操作后,GoldenGate启动运行正常。

[问题三 源端与目标端数据同步过程中存在数据丢失]

针对第三个问题,目前我们的解决方法是通过配置discard参数记录丢失数据。由于该问题无法模拟,需要通过配置该参数后,出现问题时,再具体分析。

Discard参数配置如下:

DISCARDFILE /home/oracle/ggs/dirrpt/REPORD.dsc, APPEND, MEGABYTES 100


第四部分建议

1.       对于刚完成升级的沙特至德国的GoldenGate环境进行监控,查看完成配置修改的进程是否仍然会报相同的错误。如果存在错误,请反馈相应的discard日志以及进程report、告警信息。

2.       对于数据要求一致性比较高的业务系统,建议取消目标端HANDLECOLLISIONS参数。




赞(0)    操作        顶端 
总帖数
1
每页帖数
101/1页1
返回列表
发新帖子
请输入验证码: 点击刷新验证码
您需要登录后才可以回帖 登录 | 注册
技术讨论