OGG|Oracle GoldenGate 基础

作者 | JiekeXu

来源 |公众号 JiekeXu DBA之路（ID: JiekeXu_IT）

大家好，我是 JiekeXu,很高兴又和大家见面了,今天和大家一起来学习利用 OGG 19c 迁移 Oracle11g 到 19c，欢迎点击上方蓝字关注我，标星或置顶，更多干货第一时间到达！

最近在学习 Oracle 数据库的迁移与升级，用到了 OGG 这块知识，故和大家在来学习一下。之前有过两篇相关文章，感兴趣的可点下方链接查看。

一、OGG 简单说明：

Oracle GoldenGate 捕获过程称为Extract. Extract 进程的每个实例都称为 group，其中包括进程本身和支持它的相关文件。

data pump 建议在源系统上使用一个额外的 Extract 进程，称为 trail. 数据泵不会捕获数据，而是读取本地路径并将数据通过网络传播到目标。

Oracle GoldenGate 申请流程称为Replicat. Replicat 进程的每个实例都称为group，其中包括进程本身和支持它的相关文件。Replicat 读取发送到本地存储的数据 trail，并将其应用到目标数据库。

在 Oracle GoldenGate 的基本配置中，主要 Extract 从源数据库捕获，然后将数据写入本地路径，由 pump 数据泵读取。数据泵将数据发送到目标上的远程路径。Replicat 读取此跟踪并将数据应用到目标数据库。

一般常用的进程包括在源端配置 MGR 进程、Extract（抽取）进程、Pump 进程，在目标端配置 MGR 管理进程、Replicat(复制)进程。

Manager 进程是 GoldenGate 的控制进程，源端和目标端都有这个进程，主要是负责启动、监控、重启 GoldenGate 的其他进程，报告错误及事件，分配数据存储空间，发布阈值报告等。每个源端或者目标端有且只能存在一个 Manager 进程，要么 RUNNING（正在运行）和 STOPPED（已经停止）两种状态。

Extract 进程负责从源端数据表或者日志中捕获数据。在其内部利用checkpoint 机制，周期性的检查并记录其读写的位置，通常是写入到本地的一个 trail 文件。这种机制为了保证如果 Extract 进程终止或者操作系统宕机，重新启动 Extract 进程后，GoldenGate 能够恢复到以前的状态，从上一个断点处集训往下运行，而不会有任何数据损失。Extract 进程状态包括 RUNNING（正在运行）和 STOPPED（已经停止）、STARTING（正在启动）、ABENDED（Abnomal End 的缩写，表示依次结束）。

以下各个图片介绍引自《叱咤风云 GoldenGate 企业级运维实战》，如需要电子版的添加我个人微信获取。

GGSCI是GoldenGate Software Command Interface 的缩写，它提供了十分丰富的命令来对Goldengate 进行各种操作，如创建、修改、监控GoldenGate进程等等。

1.1 决定使用哪种捕获方法

对于 Oracle 源数据库，您可以在集成捕获 或经典捕获模式下运行 Extract 。

虽然您可以使用经典捕获模式，但建议您使用集成捕获模式，因为经典捕获已被弃用，并且不会在任何未来版本中增强。它将在未来的版本中停止支持，任何经典的 Extract 配置都需要迁移到集成的 Extract。

您使用的方法决定了您如何配置 Oracle GoldenGate 进程并取决于以下因素：

u 涉及的数据类型

u 数据库配置

u Oracle数据库的版本

1.1.1 关于集成捕获

在集成捕获模式下，Oracle GoldenGate Extract 进程直接与数据库日志挖掘服务器交互，以逻辑更改记录 (LCR) 的形式接收数据更改。下图说明了 Extract 在集成捕获模式下的配置。

集成捕获是主要 Extract 进程与数据库日志挖掘服务器交互以接收逻辑更改记录形式的数据更改的地方。集成采集相比经典采集支持更多的数据和存储类型，支持更加透明。有关更多信息请参阅官方文档“1.1支持 Oracle 数据类型和对象的详细信息”。

以下是集成捕获的一些额外好处：

l 由于集成捕获与数据库完全集成，因此无需额外设置即可使用 Oracle RAC、ASM 和 TDE。

l 集成捕获使用数据库日志挖掘服务器访问 Oracle 重做流，好处是能够在存档日志的不同副本或在线日志的不同镜像版本之间自动切换。因此，集成捕获可以透明地处理由于磁盘损坏、硬件故障或操作员错误导致的日志文件缺失，假设存档和在线日志的附加副本可用.

l 集成捕获可以更快地过滤表格。

l 集成捕获更有效地处理时间点恢复和 RAC 集成。

l 集成捕获功能集成日志管理。Oracle 恢复管理器 (RMAN) 会自动保留 Extract 所需的存档日志。

l 集成捕获是唯一支持从多租户容器数据库捕获的模式。一个 Extract 可以在多租户容器数据库中挖掘多个可插拔数据库。

l 对于版本 11.2.0.4 及更高版本的源数据库（源兼容性设置为 11.2.0.4 或更高版本），DDL 的捕获由日志挖掘服务器异步执行，不需要安装特殊的触发器、表或其他数据库对象。无需停止用户应用程序即可执行 Oracle GoldenGate 升级。当 Extract 与早于版本 11.2.0.4的 Oracle 11 g 源数据库处于集成模式时，需要使用 DDL 触发器和支持对象。

l 由于集成捕获和集成应用都是数据库对象，因此对象的命名遵循与其他 Oracle 数据库对象相同的规则，请参阅管理 Oracle GoldenGate 中的在 Oracle GoldenGate 输入中指定对象名称

附：关于兼容性查看：

SQL>
show parameter compatible

NAME                                 TYPE        VALUE
------------------------------------
----------- ------------------------------
compatible                           string      11.2.0.4.0
SQL>
col name for a20
SQL>
col compatibility for a15
SQL>
set line 120
SQL>
select name,compatibility,database_compatibility from  v$asm_diskgroup;

NAME                 COMPATIBILITY   DATABASE_COMPATIBILITY
--------------------
--------------- ------------------------------------------------------------
ACFSDG               10.1.0.0.0      10.1.0.0.0
DATA                 11.2.0.0.0      10.1.0.0.0
FRA                  11.2.0.0.0      10.1.0.0.0
OCR                  11.2.0.0.0      10.1.0.0.0

1.1.2 关于经典捕获

在经典捕获模式下，Oracle GoldenGate Extract 进程从源系统上的 Oracle 重做或存档日志文件或从备用系统上的传送存档日志中捕获数据更改。下图说明了经典捕获模式下的 Extract 配置。Oracle GoldenGate 18c (18.1.0) 和更高版本已弃用经典捕获。

(经典捕获是主要 Extract 直接读取 Oracle 重做日志以捕获事务数据更改的地方。)

经典捕获完全支持大多数 Oracle 数据类型，但对复杂数据类型的支持有限。经典捕获是原始的 Oracle GoldenGate 捕获方法。您可以对 Oracle GoldenGate 支持的任何源 Oracle RDBMS 使用经典捕获，但多租户容器数据库除外。

1.2 决定使用哪种应用方法

Replicat 进程负责将复制的数据应用到 Oracle 目标数据库。对于 Oracle 目标数据库，您可以并行、非集成或集成模式运行 Replicat。Oracle 建议您使用并行 Replicat，除非特定功能需要不同类型的 Replicat。

1.2.1 关于并行复制

Parallel Replicat 是 Replicat 的一个新变体，它并行应用事务以提高性能。

它考虑了事务之间的依赖关系，类似于 Integrated Replicat。依赖计算、映射和应用的并行性在数据库外部执行，因此可以卸载到另一台服务器。在此过程中维护事务完整性。此外，Parallel Replicat 通过将大事务拆分为多个块并并行应用它们来支持大事务的并行应用。Parallel Replicat 支持所有使用非集成选项的数据库。

1.2.2 关于非集成副本

在非集成模式下，Replicat 进程使用标准 SQL 将数据直接应用于目标表。在这种模式下，Replicat 操作如下：

l 读取 Oracle GoldenGate trail 文件。

l 执行数据过滤、映射和转换。

l 构造表示源数据库 DML 或 DDL 事务（按提交顺序）的 SQL 语句。

l 通过 Oracle 调用接口 (OCI) 将  SQL  应用到目标。

下图说明了 Replicat 在非集成模式下的配置。

说明：在非集成模式下，Replicat 进程从存储在 trail 中的数据构造 SQL 操作，然后按照事务在源上发生的顺序通过 Oracle 调用接口将它们应用到目标数据库。如果要大量使用集成 Replicat 模式不支持的功能，请使用非集成 Replicat。

1.2.3 关于集成复制模式

在集成模式下，Replicat 进程利用 Oracle 数据库中可用的应用处理功能。在这种模式下，Replicat 操作如下：

l 读取 Oracle GoldenGate trail 文件。

l 执行数据过滤、映射和转换。

l 构造表示源数据库 DML 事务（按提交顺序）的逻辑更改记录 (LCR)。DDL 由 Replicat 直接应用。

l 通过轻量级流接口附加到目标数据库中的后台进程，称为数据库入站服务器。

l 将 LCR 传输到入站服务器，后者将数据应用到目标数据库。

下图说明了Replicat 在集成模式下的配置。

说明：在集成模式下，Replicat 进程从存储在跟踪中的数据构建逻辑更改记录，然后使用轻量级流 API 将逻辑更改记录传递到目标 Oracle 数据库系统中的入站服务器。入站服务器管理事务依赖以保留原始事务原子性。

在单个 Replicat 配置中，称为应用服务器的多个入站服务器子进程并行应用事务，同时保留原始事务原子性。您可以在配置 Replicat 进程时或根据需要动态增加此并行度，只要您的目标系统支持。下图说明了配置有两个并行应用服务器的集成 Replicat。

说明：在数据库入站服务器中，Reader 进程和 Coordinator 进程将更改数据发送到并行应用服务器进程。每个应用服务器处理一个复制的源事务。入站服务器管理事务依赖以保持原子性。

Integrated Replicat 异步应用事务。没有相互依赖关系的事务可以安全地执行和无序提交，以实现快速吞吐量。具有依赖关系的事务保证以与源相同的顺序应用。

入站服务器中的读取器进程根据目标数据库中定义的约束（主键、唯一键、外键）计算工作负载中事务之间的依赖关系。Barrier 事务和 DDL 操作也是自动管理的。协调器进程协调多个事务并维护应用服务器之间的顺序。

如果入站服务器不支持配置的功能或列类型，Replicat 会与入站服务器脱离，等待入站服务器完成其队列中的事务，然后通过 OCI 以直接应用模式将事务应用于数据库。在应用直接事务后，Replicat 以集成模式恢复处理。

Replicat 在直接模式下应用以下功能：

l DDL操作

l 序列操作

l SQLEXECTABLE或MAP参数内的参数

l EVENTACTIONS 加工

l UDT 注意，如果提取用于 USENATIVEOBJSUPPORT 捕获 UDT，则集成的 Replicat 会将其应用到入站服务器，否则将直接由 Replicat 处理。

由于事务是在直接应用模式下串行应用的，大量使用此类操作可能会降低集成 Replicat 模式的性能。最好的时候大部分的应用处理集成 Replicat 执行可在集成模式来执行，参见监视和控制处理的实例化之后 在使用的 Oracle GoldenGate 用于 Oracle 数据库。

集成复制的好处

1.3 同时使用不同的捕获和应用模式

您可以在同一个源 Oracle GoldenGate 实例中同时使用集成捕获和经典捕获，您可以在同一个目标 Oracle GoldenGate 实例中同时使用集成 Replicat 和非集成 Replicat。此配置需要在适当的进程组中仔细放置对象，因为在经典和集成捕获模式之间以及非集成和集成复制模式之间没有 DDL 或 DML 的协调。

每个提取组必须根据表数据类型和属性处理适合处理模式的对象。一个 Extract 中的任何对象都不能对另一个 Extract 中的对象具有 DML 或 DDL 依赖关系。必须对 Replicat 配置应用相同类型的隔离。

您可以同时使用以下捕获和应用模式：

l 经典捕获（Oracle 或非 Oracle 源）和非集成 Replicat

l 经典捕获（Oracle 或非 Oracle 源）和集成的 Replicat

l 集成捕获和非集成复制

l 集成捕获和集成复制

如果 Oracle 版本支持，推荐的Oracle GoldenGate 配置是在 Oracle 源上使用一个集成捕获，在 Oracle 目标上为每个源数据库使用一个集成复制。集成捕获比经典捕获更完整地支持某些数据类型。一种集成的 Replicat 配置通过入站服务器或在必要时切换到直接应用来支持所有 Oracle 数据类型，并且它保留了源事务的完整性。您可以根据需要将并行度设置调整为所需的应用性能级别。

如果目标数据库是不支持集成 Replicat 的 Oracle 版本，或者是非 Oracle 数据库，可以使用协调的 Replicat 配置。

二、OGG 原理介绍：

利用捕捉进程(Capture Process)在源系统端读取Online Redo Log或Archive Log，然后进行解析，只提取其中数据的变化如增、删、改操作，并将相关信息转换为GoldenGate自定义的中间格式存放在队列文件（trail）中。再利用传送进程将队列文件通过 TCP/IP 传送到目标系统。捕捉进程在每次读完 log 中的数据变化并在数据传送到目标系统后，会写检查点（checkpoint），记录当前完成捕捉的 log 位置，检查点的存在可以使捕捉进程在中止并恢复后可从检查点位置继续复制。

目标系统接受数据变化并缓存到GoldenGate队列当中，队列为一系列临时存储数据变化的文件，等待投递进程读取数据；GoldenGate投递进程从队列中读取数据变化并创建对应的SQL语句，通过数据库的本地接口执行，提交到数据库成功后更新自己的检查点，记录已经完成复制的位置，数据的复制过程最终完成。

由此可见，GoldenGate 是一种基于软件的数据复制方式，它从数据库的日志解析数据的变化（数据量只有日志的四分之一左右）。GoldenGate 将数据变化转化为自己的格式，直接通过TCP/IP 网络传输，无需依赖于数据库自身的传递方式，而且可以通过高达 9:1 的压缩率对数据进行压缩，可以大大降低带宽需求。在目标端，GoldenGate 可以通过交易重组、分批加载等技术手段大大加快数据投递的速度和效率，降低目标系统的资源占用，可以在亚秒级实现大量数据的复制，并且目标端数据库是活动的。

OGG 需要 Oracle 数据库需要开启归档日志，并开启最小附加日志模式。

SQL> select supplemental_log_data_min from v$database; --查看是否开启了最小附加日志模式
SQL> alter database add supplemental log data; --开启最小附加日志模式

实际生产应用中，最好同时打开 ORACLE 的强制日志模式，以防止源数据库因直接路径加载忽略 redo 生成而导致这部分数据无法同步：

SQL> select force_logging from v$database;
SQL> Alter database force logging;

光开启最小附加日志模式还不够，还需要打开表级的补全日志，可以在 GoldenGate 中使用 add trandata 命令强制重做日志记录主键值，以保证在目标端能成功复制：

GGSCI> dblogin userid ogg,password oggpw --GoldenGate 中登录 OARCLE 数据库
GGSCI> add trandata ddw.<tablename>      --表名可以使用通配符
GGSCI> add trandata scott.per_test,nokey,cols(sampletime, objectid) --无主键指定字段补全的示例
--也可以在数据库中打开：
SQL> alter table <tablename> add supplemental log data (primary key) columns;

千万不要小看这步日志设置，其实在 GoldenGate 的配置中，这步是最容易出错的环节。如果开启 DDL 复制做冗灾备份，最好直接在数据库级别打开补全日志：

SQL> alter database add supplemental log data (primary key,unique,foreign key) columns;

SQL> select supplemental_log_data_min,supplemental_log_data_pk,supplemental_log_data_ui
from v$database;

三、关于 Oracle 补全日志补充说明

Oracle 日志（redo log）一般用于实例恢复和介质恢复，但是如果需要靠日志还原完整的 DML 操作信息（比如 Logmnr、Streams 和这里的 Goldengate），默认记录的日志量还不够。比如一个  UPDATE 的操作，默认 redo 只记录了 rowid 以及被修改的字段信息，但这里 GoldenGate 还原这个事务，因为不是根据 rowid 而是 SQL 层面根据唯一键值来定位记录，所以还需要将主键或者其他字段的信息附加到日志中去。要往日志中增加这些额外字段信息的操作，就是开启补全日志，即 Add Supplemental Logging。打开补全日志，会使数据库的日志量增加，所以只打开需要的级别和对象即可。

Oracle 补全日志可以在数据库级别设置，也可以在表级别设置。在数据库级别中，补全日志按补全的信息量，对应好几个级别：

（1） 最小附加日志（Minimal supplemental logging）：是开启 logmnr的最低日志要求，提供了行链接（chained rows）和多种数据存储（比如聚簇表、索引组织表）的信息。在 Oracle 9.2 之后的版本中，默认都不开启。

（2） 主键补全（Primary key supplemental logging）：在日志中补全所有主键列。如果表中无主键，则补全一个非空唯一索引列；如果非空唯一索引键也没，那么会补全除了 LOB 和 LONG 类型字段以外的所有列，这时就和下面的所有补全一样了。

（3） 唯一键补全（Unique key supplemental logging）： 当唯一键列或位图索引列被修改时，在日志中补全所有唯一键列或位图索引列。打开唯一键补全也会同时打开主键补全。注意这个级别是需要条件触发的。

（4） 外键补全（Foreign Key supplemental logging）：当外键列被修改时，将在日志中补全所有外键列。这个级别也是需要条件触发的。

（5） 所有补全（All supplemental logging）：在日志中补全所有字段（排除 LOB 和 LONG 类型）。

这里对于补全日志的详细操作语句不做一一说明。数据库级别中的 5 个类型中，除了最小附加日志级别，都可以在表级进行设置。除此之外，表级还可以明确指定需要补全的列。

Oracle 表级补全日志需要在最小补全日志打开的情况下才起作用，即若一个数据库没有开最小补全日志或之前 drop supplemental log data 操作则即便指定了表级补全日志，实际在重做日志输出的过程中描述的记录仍只记录rowid 和相关列值。而要关闭最小补全日志，也必须首先关闭数据库级别的其他补全级别后，才能关闭。

所以在 GoldenGate 中，对于 Oracle 数据库的日志补全要求，至少是打开最小附加日志和主键补全。主键补全只要在需要同步的表上开启即可。当然 GoldenGate 的 add trandata 语法中也可以指定补全的列，这和 Oracle 表级补全日志的功能完全一致。毕竟，日志还是由数据库生成的，GoldenGate 并不能直接控制日志的生成方式和规则，只能根据所捕获的数据库的日志规则而来。不同的数据库，日志补全的规则也会不同。

四、Logging

相关说明

Logging：当创建一个数据库对象时将记录日志信息到联机重做日志文件。LOGGING 实际上是对象的一个属性，用来表示在创建对象时是否记录 REDO 日志，包括在做 DML 时是否记录REDO 日志。

Force Logging：强制记录日志，即对数据库中的所有操作都产生日志信息，并将该信息写入到联机重做日志文件。

NoLogging：正好与 LOGGING、FORCE LOGGING 相反，尽可能的记录最少日志信息到联机日志文件。

Supplemental Log：补充日志，主要是针对 update 命令的，是对重做日志记录中变更矢量块的补充记录。日志挖掘器(LogMiner)、闪回事务及其查询等都需要补充日志的支持。补充的目的是高度还原 update 命令，避免因为 update 命令造成的行迁移和行移动影响对日志的分析，让LogMiner 通过分析重做日志识别 update 命令不是由 insert 和 delete 完成的。

五、早期的 DDL 同步说明

GoldenGate 的 DDL 同步只支持两边一致的数据库，限制条件较多（如不能进行字段映射、转换等），具体可以参考官方文档。早期版本的 DDL 的抓取不是通过日志抓取来捕获的，而是通过触发器来实现，所以对源数据库的性能影响要比单纯的数据抓取要大很多，可谓屏弃了 GoldenGate 的优势。尽量不要使用 GoldenGate 的 DDL 复制功能，在一些业务系统中，实际上不会有频繁的数据库结构变动，完全可以通过手工的方式进行维护。

5.1 开启 DDL 复制的基本配置步骤为：

（1）选择一个数据库 schema 存放支持 DDL 的 GoldenGate 对象，运行相应创建脚本。

（2）编辑 globals 参数文件。

（3）修改 extl 和 repl 的配置文件

具体操作步骤：

（1）编辑 globals 参数文件：

GGSCI>edit param ./globals

添加以下内容后保存：

GGSCHEMA ogg  --标明支持 DDL 的 GG 对象存放在哪个 schema 下

（2）执行创建脚本：

首先需要命令行进入 GG 安装目录下，然后再运行 sqlplus 执行脚本，如果不进入目录下脚本执行会报错（应该是由于 GG 脚本中子脚本嵌套使用相对路径的问题所造成）。

SQL>@marker_setup.sql --提示输入目标 schema ogg

SQL>@ddl_setup.sql --提示输入目标 schema ogg,输入 initialsetup 最后输入 yes

SQL>@role_setup.sql

SQL>grant GGS_GGSUSER_ROLE to ddw; --不进行该步赋权后面起进程会报错

SQL>@ddl_enable.sql  --使触发器生效

（3）修改提取进程和复制进程的配置文件，分别加入 ddl include all 属性。

此时 repl 必须指定 assumetargetdefs 属性，这表明只有两边数据库结构一致的情况下才可以启用 DDL 复制。另外，开启 DDL 同步不能再只映射单表了，对整个模式下的对象都有效。加入 DDL 复制之后，数据复制的 lag 明显增加了。

5.2 DDL 配置清除

清除数据库中 DDL 复制的设置

在实际测试中，由于我在同一个数据库中进行映射，映射表结构不一致，导致进程报了一系列的错误。这个时候需要把通过脚本创建的 OGG 对象中的数据清空，安装目录下只提供了清除对象的脚本，可以如下操作：

首先要求把所有的 OGG 进程停掉，包括 mgr 进程

SQL>@ddl_disable.sql --首先使 DDL 触发器失效

SQL>@ddl_remove.sql

SQL>@marker_remove.sql

role_setup.sql 没有对应的清除脚本，但是这块不影响配置信息的清除

然后重新再创建脚本。

六、OGG 对 Oracle 数据库要求

• 最小补充日志

• 归档模式

• Force logging

七、说明

DBA_GOLDENGATE_SUPPORT_MODE 显示有关 Oracle GoldenGate 捕获进程对数据库中表的支持级别的信息。

表的捕获进程支持级别：

SUPPORT_MODE 取值如下：

FULL - 捕获过程可以捕获对表中所有列所做的更改

ID KEY-一个捕获过程能捕捉到捕获进程所支持的表的主键列以及任何其他列所做的更改，除LOB，LONG，LONG RAW，和 XMLType 列。

INTERNAL- 捕获过程无法捕获对表中任何列所做的更改，因为该表是用户创建的表的次要表，并且会在对用户创建的表进行更改时隐式更新。此类表包括索引组织表的映射表、嵌套表的存储表、物化视图日志、与域索引关联的辅助对象和临时表。

NONE - 捕获过程无法捕获对表中任何列所做的更改，因为该表不支持复制。

DBA_GOLDENGATE_NOT_UNIQUE 显示所有没有主索引和非空唯一索引的表。

此视图显示的大多数表都受支持，因为它们的列包含足够的信息供 Oracle GoldenGate 维护。但是，某些表不受支持，因为它们的列不包含必要的信息。不受支持的表通常包含使用不受支持的数据类型定义的列。

================（未完待续）=================

以上资料来源于互联网和 Oracle GoldenGate 官方网站，由于本人技术能力有限，如有错误或不当之处，敬请谅解

，也可添加我个人微信【JiekeXu_DBA】一起交流探讨。预告：由于篇幅有限，明天将学习“利用 OGG 19c 迁移 Oracle11g 到 19C”。

❤️ 欢迎关注我的公众号，一起学习新知识！

————————————————————————————
公众号：JiekeXu DBA之路
墨天轮：https://www.modb.pro/u/4347
CSDN ：https://blog.csdn.net/JiekeXu
腾讯云：https://cloud.tencent.com/developer/user/5645107
————————————————————————————