Oracle GoldenGate（OGG）诊断

这篇文档简要地列出了在使用 Oracle GoldenGate（OGG）时常见的问题以及诊断的步骤和工具。它描述了查找 OGG 组*失败原因的关键文件。理解 OGG 怎样捕获和传输数据有助于理解为何会发生问题以及如何避免这些问题。正确的安装和配置 OGG，再结合日志可以极大地帮助问题解决。

注：
*组 - 是抽取或复制的官方术语。 从现在开始,我们使用这个术语来描述抽取或复制。

下面列出的是使用 OGG 时可能发生的典型问题。请参考后面的文档部分获取这些问题的扩展及详细信息。

• 数据库报错及数据库问题
• 非数据库报错
• OGG 组挂起
• 性能问题
• OGG 组突然异常结束
• 硬件故障（磁盘、服务器）及损坏

下面列出的文件和信息将帮助研究 OGG 问题。建议熟悉这些文件和它们的位置。官方文档中的参考手册上描述了怎样定位和解释它们。例如，报告文档几乎总是需要的，且其内容大部分是自解释的。

• 报告文档 - 对 99% 的 OGG 问题都有用；因为在这里报错和警告大多是自解释的，我们应该经常查看这个文件。
• OGG 错误日志，ggserr.log，报错汇总，ggsci 命令日志，事件（例如进程停止和启动）的时间戳。
• 使用 logdump 的跟踪文件 - OGG 抽取进程所捕获记录的详细分析。
• Discard 文件，跟踪问题记录的文本显示。
• 数据库警告日志 - 对除了数据查询错误（如 ORA-1403、ORA-0001）之外的数据库相关问题有用。
• 系统警告日志 - 对于性能问题、资源问题有用。
• 数据库性能工具，健康检查，AWR 报告。

下面的列表提供了诊断/解决问题的工具。请您熟悉这些工具。许多诊断工具如 Logdump 通常是只读的，所以可以放心安装到一个生产环境中。

• 设置报告参数和正确的选项，例如 DDL REPORT，使用 REPORT，REPORTCOUNT 参数, 避免使用 REPORTROLLOVER。
• LOGDUMP
• 数据库工具 - logminer，数据库健康检查报告，10046 会话跟踪。
• Pstack

当一个问题发生时，第一步是找到最佳描述这个问题的文件/信息。例如，一个 OGG 组的异常结束（异常终止）总是会在报告文件中记录下来，其中可能包括多个警告和报错。 分类这些错误将帮助进一步获取相关数据。例如

• 报错是什么？
• 是哪个组？
• 报错信息显示在哪里？
• 哪个文件提供了这个错误的详细信息，例如报告文件？
• 这个报错是哪种类型？
• 这个报错是否被报错信息手册或知识库文档收录？

常见 OGG 问题

数据库报错和数据库问题

• 报告文件中的数据库报错，以及导致 OGG 异常终止的报错之前的任何警告信息。通常这是它失败的准确原因，例如 ORA-01403（No data found）。
• 与查询相关的数据库报错（ORA-1403，ORA-0001）通常意味着目标表不同步和/或约束有差异（主键、外键等），通常不可能去跟踪为什么会发生这种情况，因为它们在很久以前就已经发生了。重新同步和监控此表可作为一个潜在的解决方案。
• 目标数据库被除了 OGG 以外的操作更新吗？搜索早期的 trail 文件，找到可能丢失的 DML 操作，判断为什么它们没有被应用？
• 非查询相关错误，例如归档日志找不到、权限问题、替代位置不正确。 一个建议，尝试剪切和粘贴实际位置，并在 OS shell 中列出它们。
• 报告文件通常包含被 OGG 组件执行的实际 SQL。在 SQLPlus 下手工执行这个 SQL。
• 常见复制问题：ERROR OGG-01296 Error mapping from SCHEMA1.TABLE1 to SCHEMA1.TABLE1. 引起这个报错的潜在原因有错误的大小、错误的列映射、不被接受的字符、错误的数据类型、字符集不兼容等。

• 在知识库文档中查找显示在报告文件中的报错信息。
• 例如检查点文件报错、报告文件无法写入、常见的权限问题等。

• 判断它确实是在 hanging，而不是慢。OGG 组 hang 的证据有：多个 SEND 命令超时，trail 文件不增长等。
• 通常由表锁或等待一些资源所引起（下游的抽取在等待归档日志）。
• 您可以使用如下命令 kill 掉 ogg 组 
  ggsci > kill 
  或在 OS 命令行使用 
  kill -9 
  杀进程并尝试重启。这会清除掉锁之类的资源。
• 在 KILL 并且重启之后加入 TRACE 和 TRACE2 参数。检查这些 trace 文件中记录的最后执行的活动。

• 在 OGG 组出现延迟前是否有大型批处理任务执行过？
• 是否一个组做了太多工作？
• 是否有资源问题，内存、磁盘性能等？
• 如果复制遇到大的延迟，是这个复制本身还是 trails 文件产生得不够快。
• 使用像 REPORTCOUNT 这样的参数来记录性能指标。
• 是否使用了占用资源的参数，如 FETCH，inserting many tokens，大量过滤器，转换函数，SQLEXEC 调用？
• 是否 Extract 启动缓慢？
• 集成的抽取和集成的复制需要数据库性能分析。

• 在 OS 命令行中执行组，例如
  ./extract paramfile dirprm/myext.prm 
  最后一行会显示为什么 OS 终止了这个进程。
• 请参考 
  Document 1458985.1 Oracle GoldenGate - How To Use GDB To Generate Stack Trace For Troubleshooting Purpose 
  来收集 dmp 文件。

• 当服务器或磁盘等物理组件失败时，OGG 数据文件（dir*目录）或 OGG trails 文件可能出现损坏，导致 OGG 组无法启动。在这样的情况下，更多地是去恢复而非诊断。此方面有大量的知识库文档，可以通过查找 GoldenGate corruption 来找到它们。

向 Oracle 提出服务请求时，提供准确而确凿的信息将大大加快分析和解决的过程。 有时，在收集相关信息时，您将对这个问题有更多了解，并在 My Oracle Support 已有知识文档的辅助下能够自行解决这个问题。正如前面提到的，报告文件是非常重要的，所以总是应该在SR中提供它。下面列出的信息/文档在开一个 SR 时通常是一个好的起点。

• 准确的基本信息，OGG 版本，数据库/平台/OS 版本。
• 精确而简短的摘要，例如：抽取因 "Error..."而异常终止。
• 总是附上报告文件和参数文件。
• 导致这个报错的事件，例如：服务器当掉/修改参数以增加新的表等。
• 最近做了什么可能相关的修改。

知道去哪里找到信息对诊断来说至关重要。下面的参考文档是配置和维护一个 OGG 实例的起点。

• Oracle GoldenGate documentation library
• Oracle GoldenGate Product portal
• Database Synchronization with Oracle GoldenGate tutorials

Oracle GoldenGate（OGG）诊断

原文：http://blog.itpub.net/12798004/viewspace-1649661/