ogg同步数据环境搭建（生产环境OGG常见故障错误处理总结）

概述

生产环境的ogg做两边数据库之间的同步还是不错的，但是进程容易abend，维护成本太高，下面总结下之前小编碰到ogg的的一些故障和处理的过程。

---

异常处理的一般步骤

首先确定是GoldenGate的哪类进程有故障（是抽取，投递还是复制进程有问题），解决故障的一般思路如下。

（1）通过GGSCI>view report命令查找ERROR字样，确定错误原因并根据其信息进行排除。

（2）通过GGSCI>view ggsevt查看告警日志信息。

（3）检查两端数据库是否正常运行，网络是否连通。

（4）通过logdump工具对队列文件进行分析。

ps: OGG的告警日志路径

ogg也有类似oracle的告警文件，该文件在 $OGG_HOME/ggserr.log

---

ogg日常运维的命令（排错必备）

通过ggsci进入

info all ----查看所有进程信息

info <进程名称> ----该命令可以查看指定进程信息

start mgr ----启动管理进程

start <进程名> ----启动相应进程

view params <进程名> ----查看该进程配置的参数

edit params <进程名> ----可配置该进程参数

info <进程名称> detail ----该命令查看更详细的信息。包括所使用的trail文件，参数文件、报告文件、警告日志的位置等

info <进程名称> showch ----该命令可以查看到详细的关于checkpoint的信息，用于查看GoldenGate进程处理过的事务记录。其中比较重要的是extract进程的recovery checkpoint，它表示源数据中最早的未被处理的事务；通过recovery checkpoint可以查看到该事务的redo log位于哪个日志文件以及该日志文件的序列号。所有序列号比它大的日志文件，均需要保留

view report 进程名 ----查看报错日志

基于日志捕获技术的实时增量数据集成

---

网络故障

如果MGR进程参数文件里面设置了autorestart参数，GoldenGate可以自动重启，无需人工干预。

autorestart参数

当网络发生故障时, 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分钟，然后重新试三次。

RAC环境下单节点失败

在RAC环境下，GoldenGate软件安装在共享目录下。可以通过任一个节点连接到共享目录，启动GoldenGate运行界面。如果其中一个节点失败，导致GoldenGate进程中止，可直接切换到另外一个节点继续运行。

下面介绍下一般操作的过程：

1) 以oracle用户登录源系统（通过另一完好节点）；

2) 确认将GoldenGate安装所在文件系统装载到另一节点相同目录；

3) 确认GoldenGate安装目录属于oracle用户及其所在组；

4) 确认oracle用户及其所在组对GoldenGate安装目录拥有读写权限；

5) 进入goldengate安装目录；

6) 执行./ggsci进入命令行界面；

7) 执行start mgr启动mgr；

8) 执行start er *启动所有进程；

检查各进程是否正常启动，即可进入正常复制。

Extract进程常见异常

对于源数据库，抽取进程extxm如果变为abended，则可以通过在ggsci中使用view report命令察看报告，可以通过搜索ERROR快速定位错误。

一般情况下，抽取异常的原因是因为其无法找到对应的归档日志，可以通过到归档日志目录命令行下执行

ls –lt arch_X_XXXXX.arc

检查该日志是否存在，如不存在则可能的原因是：

1) 日志已经被压缩 GoldenGate无法自动解压缩，需要人工解压缩后才能读取。 2) 日志已经被删除 如果日志已经被删除，需要进行恢复才能继续复制，请联系本单位DBA执行恢复归档日志操作。

一般需要定期备份归档日志，并清除旧的归档日志。需要保证归档日志在归档目录中保留足够长时间之后，才能被备份和清除。即：定期备份清除若干小时之前的归档，而不是全部归档。保留时间计算如下：

某归档文件保留时间≥抽取进程处理完该文件中所有日志所需的时间

可以通过命令行或者GoldenGate Director Web界面，运行info exXX showch命令查看抓取进程exXX处理到哪条日志序列号。在此序列号之前的归档，都可以被安全的清除。如下图所示：

Replicat进程常见异常

对于目标数据库，投递进程repXX如果变为abended，则可以通过在ggsci中使用view report命令察看报告，可以通过搜索ERROR快速定位错误。

复制进程的错误通常为目标数据库错误，比如：

1) 数据库临时停机； 2) 目标表空间存储空间不够； 3) 目标表出现不一致。

可以根据报告查看错误原因，排除后重新启动rep进程即可。

需要注意一点：往往容易忽略UNDO表空间。如果DML语句中包含了大量的update和delete操作，则目标端undo的生成速度会很快，有可能填满UNDO表空间。因此需要经常检查UNDO表空间的大小。

---

以上就是生产环境中ogg经常会碰到的一些问题，具体问题具体分析吧，有一些不一定是这里面的，大家还是要根据日志去做分析好一点。

后面会分享更多DBA方面内容，感兴趣的朋友可以关注下！！

,