第115期：02.关于微服务的构架

原创 ByteHouse 2026-01-19

151

摘要：使用案例详细介绍了 19C ogg 的微服务构架，如有错误可以私信我修改完善。

第110篇专题：OGG 微服务架构的介绍 https://www.modb.pro/db/2002928197801959424
第111篇专题：01.GoldenGate Microservices Architecture https://www.modb.pro/db/2006005568231251968
第115期：02.关于微服务的构架 https://www.modb.pro/db/2013094199253082112

1.架构

Oracle GoldenGate 主要由如下组件组成。

工作流程：

源端利用Extract(Capture)抽取模块在源端数据库中读取在线日志(Online Redo Log)(默认)或归档日志(Archive Log)，然后进行解析，只提取其中数据的变化信息，比如DML操作-增、删、改操作，将抽取的信息转换为GoldenGate自定义的中间格式存放在队列文件(Trail文件)中。
源端利用Extract(Data Pump)推送模块将队列文件(Trail文件)通过TCP/IP传送到目标端。
目标端利用Collector收集模块接收从源端传输过来的数据变化信息，把信息缓存到GoldenGate 队列文件(远程Trail文件)中。
目标端利用Replicat复制模块从队列文件(远程Trail文件)中读取数据变化信息，并创建对应的SQL语句，通过数据库的本地接口执行，提交到目标端数据库，提交成功后更新自己的检查点，记录已经完成复制的位置，数据的复制过程最终完成。

2.Manager管理模块

Manager进程运行在源端和目标端。
每个源端或者目标端有且只能存在一个Manager进程。在其他进程启动之前，Manager进程必须先要在源端和目标端启动。

作用：

启动、监控、重启其他进程。
报告错误及事件。
分配数据存储空间。
发布阈值报告。
管理Trail文件的生成、删除。
整体监控、报表。
执行用户命令。
维护各进程端口号。

通信：

UI与Manager：TCP/IP。
Extract/Replicat与本地Manager：共享内存。
Extract(Data Pump)与远端Manager：TCP/IP。

1.Checkpoints

用于定位中断的位置，下次启动从中断的位置开始恢复。

Extract Checkpoints

Extract read checkpoints

Startup checkpoint
当 Extract 进程启动的时候，会创建 startup checkpoint，用来记录此时 record 的相关信息。该 checkpoint 是第一个checkpoint。
startup checkpoint的统计信息包含如下内容：

Thread#: 创建checkpoint 的thread编号；
Sequence#: 创建checkpoint 时对应的 sequence 号码，即归档日志的序号；
RBA: 创建checkpoint 时，redo log 里面 record 的 relative byte address；
Timestamp: 创建checkpoint 时record对应的timestamp；
SCN: 创建checkpoint 时 record 对应的system change number；
Redo File: 创建checkpoint 时record对应的事务日志路径；

Recovery checkpoint
recover checkpoint 记录的是 data source（online redo log 或者归档中）中 Extract 没有开始没处理的 record 的位置。该checkpoint 的统计信息和startup checkpoint一样。
Current checkpoint
current checkpoint 是 data source中Extract 最后一次读取的record的位置。

GGSCI (ogg02) 4>  info ext1

 EXTRACT    EXT1      Last Started 2014-12-27 17:42   Status RUNNING
 Checkpoint Lag          00:00:00 (updated 00:00:04 ago)
 Process ID                31621
 Log Read Checkpoint  Oracle Redo Logs
                      2014-12-27 18:06:05  Seqno 15, RBA 18128896
                      SCN 0.1142344 (1142344)

Seqno 和 RBA 会变，说明ogg是在工作的。

GGSCI (ogg02) 5>  info ext1,showch

 EXTRACT    EXT1      Last Started 2014-12-27 17:42   Status RUNNING
 Checkpoint Lag       00:00:00 (updated 00:00:00 ago)
 Process ID           31621
 Log Read Checkpoint  Oracle Redo Logs
                      2014-12-27 18:11:06  Seqno 15, RBA 18188800
                      SCN 0.1142472 (1142472)


 Current Checkpoint Detail:

 Read Checkpoint #1

   Oracle Redo Log

   Startup Checkpoint (starting position in the data source):
     Thread #: 1
     Sequence #: 11
     RBA: 7646224
     Timestamp: 2014-12-27 16:20:48.000000
     SCN: 0.1136079 (1136079)
     Redo File: /oradata/ogg02/redo02.log

   Recovery Checkpoint (position of oldest unprocessed transaction in the data source):
     Thread #: 1
     Sequence #: 15
     RBA: 18187792
     Timestamp: 2014-12-27 18:09:41.000000
     SCN: 0.1142443 (1142443)
     Redo File: /oradata/ogg02/redo03.log

   Current Checkpoint (position of last record read in the data source):
     Thread #: 1
     Sequence #: 15
     RBA: 18188800
     Timestamp: 2014-12-27 18:11:06.000000
     SCN: 0.1142472 (1142472)
     Redo File: /oradata/ogg02/redo03.log

Write Checkpoint #1

   GGS Log Trail

   Current Checkpoint (current write position):
     Sequence #: 4
     RBA: 1755
     Timestamp: 2014-12-27 18:11:43.251745
     Extract Trail: /u01/zt/dirdat/lt
     Trail Type: RMTTRAIL

 Header:
   Version = 2
   Record Source = A
   Type = 10
   # Input Checkpoints = 1
   # Output Checkpoints = 1

 File Information:
   Block Size = 2048
   Max Blocks = 100
   Record Length = 2048
   Current Offset = 0

 Configuration:
   Data Source = 3
   Transaction Integrity = 1
   Task Type = 0

 Status:
   Start Time = 2014-12-27 17:42:32
   Last Update Time = 2014-12-27 18:11:43
   Stop Status = A
   Last Result = 400

Extract write checkpoints

该checkpoint包含如下信息：

Sequence#: checkpoint 正在写的 trail 文件的序列号;
RBA: 创建checkpoint 时 trail 文件里record 的relative byte address;
Timestamp: 创建checkpoint 时 record 对应的timestamp;
Extract trail: trail 文件的路径;
Trail Type: 标识 trail 文件类型。有2个值：
- EXTTRAIL：表示该trail 是本地的trail，文件由OGG进程直接写如本地disk。
- RMTTRAIL：表示是远程的trail，该文件不会写入本地的磁盘，而是传到远端的的OGG上，在有远端OGG的collector 进程写disk。
  比如pump 进程，里面就会写RMTTRAIL。

GGSCI (ogg04) 1>  info rep1

 REPLICAT   REP1      Last Started 2014-12-27 14:07   Status RUNNING
 Checkpoint Lag         00:00:00 (updated 00:00:01 ago)
 Process ID               26088
 Log Read Checkpoint  File /u01/zt/dirdat/lt000004
                      2014-12-27 16:49:03.408880  RBA 1755

GGSCI (ogg04) 2>  info rep1,showch

 REPLICAT   REP1      Last Started 2014-12-27 14:07   Status RUNNING
 Checkpoint Lag         00:00:00 (updated 00:00:07 ago)
 Process ID               26088
 Log Read Checkpoint  File /u01/zt/dirdat/lt000004
                      2014-12-27 16:49:03.408880  RBA 1755

 Current Checkpoint Detail:

 Read Checkpoint #1

   GGS Log Trail

   Startup Checkpoint (starting position in the data source):
     Sequence #: 3
     RBA: 20259
     Timestamp: 2014-12-27 14:06:57.000000
     Extract Trail: /u01/zt/dirdat/lt

   Current Checkpoint (position of last record read in the data source):  --最后一次读取文件的位置
    Sequence #: 4
     RBA: 1755
     Timestamp: 2014-12-27 16:49:03.408880
     Extract Trail: /u01/zt/dirdat/lt

 Header:
   Version = 2
   Record Source = A
   Type = 1
   # Input Checkpoints = 1
   # Output Checkpoints = 0

 File Information:
   Block Size = 2048
   Max Blocks = 100
   Record Length = 2048
   Current Offset = 0

 Configuration:
   Data Source = 0
   Transaction Integrity = -1
   Task Type = 0

 Database Checkpoint:
   Checkpoint table = ggs.checkpoint
   Key = 982417365 (0x3a8e7fd5)
   Create Time = 2014-12-27 10:46:19

 Status:
   Start Time = 2014-12-27 14:07:31
   Last Update Time = 2014-12-27 17:03:30
   Stop Status = A
   Last Result = 400

 GGSCI (ogg04) 3>

data dump进程：将队列数据发送到目标
1…预防网络和源库的故障；

可以对数据进行过来和转换；
synchronize方式从多个源库上合并数据到一个中心库；
synchronize方式将一个源库数据传到多个目标库;

Checkpoint table

有两种类型：主表和辅助表。
主表根据用户定义名称来来创建，辅助表会自动创建。
辅助表就是 transaction table, 名称是 checkpoint table名上加_LOX。

SQL> conn ogguser/admin123 
Connected.
SQL> select table_name from user_tables;

TABLE_NAME
------------------------------------------------------------
CHKPOINT
CHKPOINT_LOX

SQL>

Checkpoint table配置方法：
step 1.在 ./GLOBALS 文件里添加 checkpoint 表名

GGSCI(suys1) 1> view param ./GLOBALS

ggschema jcpt
checkpointtableogg.checkpointtab

GGSCI (suys1) 2>

step 2.连上DB，创建checkpoint表

GGSCI(suys1) 85> dblogin userid ogg, password ogg

Successfullylogged into database.

GGSCI(suys1) 86> add checkpointtable ogg. checkpointtab

Successfully created checkpoint table ogg.checkpointtab.

生成这个检查点记录表

step 3.验证

SQL> conn ogguser/admin123 
Connected.
SQL> select * from CHKPOINT;

 GROUP_NA GROUP_KEY  SEQNO    RBA AUDIT_TS                      CREATE_TS    LAST_UPDATE_ CURRENT_DIR
 -------- ---------- ------ ----------------------------------- ------------ ------------
 REP1    3987940558     12   1564 2011-11-17 17:21:55.471376    17-NOV-11   17-NOV-11    /u01/ggate

SQL>

2.Supplemental Logging and TRANDATA

schema trandata, table trandatam, 过程trandatam

Supplemental Logging

附加日志（supplemental log）可以指示数据库在日志中添加额外信息到日志流中，，可以捕获表中的附加信息，如主键、唯一约束、外键等,以支持基于日志的工具，如逻辑standby、streams、GoldenGate、LogMiner。可以在数据库和表上设置。
启用SUPPLEMENTAL LOG DATA后，Oracle将记录特定列的变更信息到日志文件中。这些变更信息对于数据恢复、故障排查和数据分析非常有用。通过分析附加日志记录，可以了解表中数据的变更历史。

数据库级设置，分两类：

最小附加日志（minimal supplemental logging）：
启用最小日志可以确保LogMiner（或其他任何基于LogMiner的产品）可以支持行链接、簇表、索引组织表等。
DATA 选项启用最小附加日志。

alter database {add|drop} supplemental log data;

标识键日志（identification key logging）：
在源库日志为变化来源同步其他数据库的情况下，比如逻辑备用数据库，受影响的数据行必须以列数据标识（而不是rowid），必须启用此种附加日志。
DATA(all,primary key,unique,foreign key) columns选项启用最小日志及列数据日志。

alter database {add|drop} supplemental log {data(all,primary key,unique,foreign key) columns};

缺省情况下，Oracle不启用以上任何附加日志。当使用ALL,PRIMARY,UNIQUE或FOREIGN附加日志时最小补全日志默认开启(即检查结果为IMPLICIT)。在删除所有导致IMPLICIT最小化附加日志的附加日志后，最小化附加日志变为NO。
查询当前设置：

SELECT supplemental_log_data_min min,
       supplemental_log_data_pk pk,
       supplemental_log_data_ui ui,
       supplemental_log_data_fk fk,
       supplemental_log_data_all allc
  FROM v$database;

表级附加日志设置，分两类

可以通过以下语句设置命名日志组：

alter table table_name add supplemental log group group_a(column_a [no log],column_b,...) [always];

NO LOG选项用于指定在日志中排除哪些列。
在命名日志组中，至少存在一个无”NO LOG“的定长列。比如，对LONG列使用 no log选项，可以在更改LONG列时，记录其他列的内容（LONG列本身不能存在日志里）。
ALWAYS选项, 在更新时，日志组中的所有列都会记录在日志中。
这就是所谓的”无条件“日志组，有时也叫”always log group“。如果不指定该选项，只有在日志组中的任何列被修改时，所有列才会出现在日志中。这就是所谓的”有条件“日志组。

同一列可以在多个日志组中存在，但日志中只记录一次；同一列在“无条件”与“有条件”日志组中存在时，该列将“无条件”记录。

可以通过以下语句设置所有列或主键/外键/唯一键组合日志组：

alter table table_name add supplemental log data(all,primary key,unique,foreign key) columns;

Oracle将生成无条件或有条件日志组。对于无条件日志组，日志中将记录该日志组中的所有列；对于有条件日志组，只有日志组中的列有变化时，才会记录日志组中的所有列。
如果指定“ALL”列，日志中将包含所有最大大小固定长度的列。这种日志是系统创建的无条件日志组。
如果指定“PRIMARY KEY”列，只要有更新，组成主键的所有列都会记录在日志中。这种日志是系统创建的无条件日志组。

Oracle使用如下顺序确定附加记录哪些列：

组成主键的列（主键有效，或rely且非DISABLED or INITIALLY DEFERRED状态）
最小的、至少有一个非空列的唯一索引
记录所有标量列

如果指定“UNIQUE”列，如果任何组成唯一键或位图索引的列被修改，组成该唯一键或位图索引的其他列都会记录在日志中。这种日志是系统创建的有条件日志组。
如果指定“FOREIGN KEY”列，如果任何组成外键的列被修改，组成该外键的其他列都会记录在日志中。这种日志是系统创建的有条件日志组。

step 1.10g需要激活补充日志

select supplemental_log_data_pk,supplemental_log_data_ui from v$database;

alter database drop supplemental log data (primary key, unique index) columns;
alter database add supplemental log data;

step 2.将redo日志文件添加到logmnr分析日志列表

exec sys.dbms_logmnr.add_logfile(logfilename=>‘redo日志1’, options=>sys.dbms_logmnr.new);
exec sys.dbms_logmnr.add_logfile(logfilename=>‘redo日志2’, options=>sys.dbms_logmnr.addfile);
exec sys.dbms_logmnr.add_logfile(logfilename=>‘redo日志n’, options=>sys.dbms_logmnr.addfile);

step 3.启动并分析redo日志

exec sys.dbms_logmnr.start_logmnr(options => sys.dbms_logmnr.dict_from_online_catalog);

step 4.查看分析结果

spool c:\log.txt
select * from v$logmnr_contents ;
spool off

step 5.停止logmnr

exec sys.dbms_logmnr.end_logmnr

step 6.取消补充日志

alter database drop supplemental log data (primary key) columns;
alter database drop supplemental log data (unique) columns;
alter database drop supplemental log data;

TRANDATA

从oracle redo log 抽取数据之前，在配置OGG时，需要给同步的表添加补充日志，在ggsci命令行执行

$ cd /ggs $ ggsci
GGSCI (unixserver) > DBLOGIN USERID userid
GGSCI (unixserver) > ADD TRANDATA schema.<table-name>

默认情况下，对update操作，oracle 只会记录变化的列。正常情况下，这意味着主键列在update操作时不会被记录。
但是，为了在目的库上应用源端ogg进程传输过来update变化，ogg 的 replicat 进程需要主键列。
添加 trandata 让oracle 对所有update操作都记录主键列。
为了添加补充日志（supplemental log data）,在unix下执行下面的命令。table名可以用*代替。所有被捕捉的表必须被添加补充日志。

该命令实际上包含两层含义：

table有PK或UK ,则目标端能准确依据PK或UK找到源端DML更新的数据，从而在目标端同步。
table没有PK和UK,则目标端只能依据该table的所有列来找到源端DML更新的数据，从而在目标端同步。

与OGG添加补充日志等效，在SQL*PLUS中有等效语法：

与第一层含义等效的语法（有主键或唯一键）

alter table user.table add supplemental log group ggs_table_1 (PK or UK) always;

与第二层含义等效的语法（没有主键和唯一键）

alter table user.table add supplemental log group ggs_table_1 (all column) always;

当某个table的column超过32个字段的时候，使用add trandata就会报错：

WARNING OGG-00706 Failed to add supplemental log group on table user.table due to ORA-02257: maximum number of columns exceeded 
......

这个时候，就要使用：

# 启用主键和唯一约束的附加日志记录：
ALTER TABLE table_name ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY, UNIQUE);

# 启用外键的附加日志记录：
ALTER TABLE table_name ADD SUPPLEMENTAL LOG DATA (FOREIGN KEY);

# 停用附加日志记录：
ALTER TABLE table_name DROP SUPPLEMENTAL LOG DATA (ALL);

此时又分两种情况：
第一情况是列超过32个，但有主键或唯一键：

alter table user.table add?supplemental log group ggs_table_1 (PK or UK) always;

第二情况是列超过32个，没有主键和唯一键：

alter table user.table add?supplemental log group ggs_table_1 (all column <32) always;
alter table user.table add?supplemental log group ggs_table_2 (all colum >32) always;

如果不执行 add trandata，在 oracle 数据库上做 insert 同步没有问题，但是在同步update或delete操作时，就会因为丢失主键报同步错误。
不开启表级的最小附加日志，update的redo 信息不记录没有进行更新的字段信息，如主键不更新的话主键不记录在redo中，所以会导致同步失败。

GGSCI (yjfora81 as ggs_admin@testdb) 2> add trandata test.t1
 2016-03-08 11:47:36  WARNING OGG-00706  Failed to add supplemental log group on table PPZHU1.TEST3 due to ORA-00054: resource busy and acquire with NOWAIT specified or timeout expired SQL ALTER TABLE “TEST″.”T1″ ADD SUPPLEMENTAL LOG GROUP “GGS_87926″ (“USER_ID”) ALWAYS  /* GOLDENGATE_DDL_REPLICATION */.
 2016-03-08 11:53:00  WARNING OGG-00706  Failed to add supplemental log group on table PPZHU1.TEST3 due to ORA-03113: end-of-file on communication channel
 Process ID: 23575
 Session ID: 80 Serial number: 2709 SQL BEGIN DBMS_CAPTURE_ADM.PREPARE_TABLE_INSTANTIATION(table_name => ‘”TEST″.”T1″‘, supplemental_logging => ‘none’); END;.

可以确定 add trandata 至少做了如下操作

1. ALTER TABLE “TEST″.”T1″ ADD SUPPLEMENTAL LOG GROUP “GGS_87937″ (“USER_ID”) ALWAYS
2. ALTER TABLE “TEST″.”T1″ ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY, UNIQUE, FOREIGN KEY) COLUMNS 
3. DBMS_CAPTURE_ADM.PREPARE_TABLE_INSTANTIATION(table_name => ‘”TEST″.”T1″‘, supplemental_logging => ‘none’

1, 2 是以NOWAIT方式锁定资源，可以及时报错出来 “ORA-00054: resource busy”，不会堵塞; 查看视图 dba_log_group_columns, dba_log_groups

3 会加锁并且不是NOWAIT的方式，如果表上有事物正在运行，那么这个语句会等待，因为他需要一个MODE 4的锁在表级S锁

SQL> select * from v$lock;
 ADDR             KADDR                   SID TYPE        ID1        ID2      LMODE    REQUEST      CTIME      BLOCK
—————- —————- ———- —- ———- ———- ———- ———- ———- ———-
00000001BD52BC80 00000001BD52BCF8         80 TX       655363       1685          6          0        122          0
 00007F716C65A908 00007F716C65A968         80 TM        87926          0          0          4        122          0

DML会在表级别上一个SX级别的3级锁，所以不兼容一直卡着，并且它还会影响随后的DML因为DML需要表级别的SX锁，这样对生产系统的影响很大。解决方式就是KILL掉OGG登陆的会话。

3.extract (capture) 进程

Extract进程运行在源端。从源端的ONLINE LOGFILE中捕获数据,也可配置只从ARCHIVE LOG中捕获。

装载过程：

初始数据装载阶段(Initial Loads)：直接从源端的数据表中抽取所有数据。
增量同步(Change Synchromization)：负责捕获源端数据的变化（DML和DDL）。

Extract利用Checkpoint机制，周期性地检查并记录其读写的位置，通常是写入到一个本地的Trail文件。这种机制是为了保证如果Extract进程终止或者操作系统宕机，重新启动Extract进程后，GoldenGate能够恢复到以前的状态，从上一个断点处继续往下运行，而不会有任何数据损失。

抽取时机，满足任一：

缓冲区(内存)写满。
设置间隔时间(FLUSHSECS/FLUSHCSECS参数)：默认1秒，最小10毫秒。

当配置为同步变化时，Extract捕获对Extract配置中的对象执行的DML和DDL操作。Extract存储这些操作，直到收到包含这些操作的事务的commit记录或rollback。收到rollback时，Extract会丢弃该事务的操作。收到commit时，Extract会将该事务的操作写入磁盘上的一系列文件，称为Trail文件，它们在那里排队，等待传递给目标系统。每个事务中的所有操作都被作为一个按顺序组织的事务单元写入Trail文件。这种设计确保了速度和数据完整性。

多个Extract可以同时操作不同的对象。例如，当数据库很大时，两个Extract可以并行地将数据提取和传输给两个Replicat（使用两个Trail文件），最小化目标延迟。要区分不同的抽取过程，需要为每个抽取过程分配一个组名。

抽取和故障恢复原理

当Extract在Redo Log中遇到某个事务的起点（在Oracle中通常为第一个可执行的SQL语句）时，便会将从该事务中捕获到的所有数据缓存到内存中，即使开始该事务不包含任何数据，Extract也必须将事务缓存到内存中，因为该事务中后面的操作可能包含要捕获的数据。
当Extract遇到事务的commit记录时，便会将缓存在内存中的整个事务写入Trail文件，并将其从内存中清除。
当Extract遇到事务的rollback记录时，便会丢弃缓存中缓存的整个事务。

在Extract处理commit或rollback记录之前，都会视事务为open状态（未提交或回滚的），并持续不断地收集该事务的信息。

如果Extract在遇到事务的commit或rollback记录之前停止，则在Extract重启后，必须对所有缓存在内存中的信息进行恢复。此操作适用于Extract进程停止时所有处于open状态的事务。

为了控制Extract发生中断后必须重新处理的事务日志量，Extract会以特定的时间间隔将正在处理的事务（包括长时间运行的事务的状态和数据）的当前状态及数据写入磁盘。

长时间未commit或rollback事务的故障恢复，采用Bounded Recovery(BR)(例:4小时)+BR检查点(BR Checkpoint)+磁盘持久化(Discard文件?)机制。

工作模式

Extract 可以配成如下两种模式：

Initial Load:
在初始化装载过程中，Extract 进程直接从源对象中抽取当前的数据。
Change synchronization:
为了保证源数据和其他对象保持数据的一致，extract 进程会捕获源对象自初始化同步以后的DML 和DDL 的变化。

如果接收到的是rollback，那么Extract 会清除该事务之前的所有记录。
如果接收到的是commit，Extract 会将之前存储的事务信息进行持久化，即将事务信息写入磁盘上的trail 文件，然后按队列传送到目标库。

添加 capture 进程

add extract ext2, tranlog, begin now EXTRACT added.

4.EXTTRAIL

为了支持数据库更改的持续提取和复制，Oracle GoldenGate将捕捉到的更改记录临时存储在磁盘上的一系列文件中，称为trail。在本地系统中，它被称为extract trail(或local trail)。在远程系统上，它被称为remode trail。

add exttrail /u01/app/oracle/ogg/dirdat/ld, extract ext2 EXTTRAIL added.

5.data pump 进程

Data Pump进程运行在源端。

Data Pump 是一个可选组件，如果不配置 Data Pump，那么由 Extract 主进程将数据发送到目标端的 Remote Trail 文件中；如果配置了Data Pump，会由 Data Pump 将 Extract 主进程写好的本地Trail文件通过网络发送到目标端的 Remote Trail 文件中。Data Pump 可以执行数据过滤、映射和转换。Data Pump 推送时数据可压缩。

data pump 增加了存储灵活性，还可以将Extract与TCP/IP活动隔离。
通常，data pump可以执行数据过滤、映射和转换，或者可以配置为直通模式，在这种模式下，数据按原样被动传输，无需操作。
直通模式增加了data pump的吞吐量，因为查找对象定义的所有功能都被绕过了。

add extract dmp2,exttrailsource /opt/oracle/ggate/dirdat/ld

add rmttrail /opt/oracle/ggate/dirdat/ld, extract dmp2 RMTTRAIL added.

使用Data Pump的好处：

如果目标端或者网络失败，源端的Extract进程不会意外终止。
需要在不同的阶段实现数据的过滤或者转换。
多个源数据库复制到数据中心。
数据需要复制到多个目标数据库。

推送时机，满足任一：

缓存写满(RMHOST参数的TCPBUFSIZE选项)：默认30000字节。
设置间隔时间(FLUSHSECS/FLUSHCSECS参数)：默认1秒，最小10毫秒。

6.Collector收集模块

Collector进程运行在目标端。
Collector把Extract(Capture/Data Pump)投递过来的数据块重新组装成Trail文件，即远程Trail文件。

7.replicate (delivery)进程

Replicat进程运行在目标端。

Replicat读取Extract提取到的数据（变更的事务或DDL变化）并应用到目标数据库。Replicat使用动态SQL编译一条SQL语句，然后使用不同的绑定变量多次执行它。

装载过程：

初始数据装载阶段(Initial Loads)：应用数据到目标对象或者路由它们到一个高速的Bulk-load工具上。
增量同步(Change Synchromization)：将Extract捕获到的提交了的事务应用到目标数据库中。

Replicat有同Extract一样的Checkpoint机制。

执行方式：

以变更行为单位生成SQL语句并执行。
基于主键(或唯一键)和变更前的值(可选)更新。

工作模式

Replicate可以配置成如下模式：
（1）Initial loads:
（2）Change synchronization

当仅配置了一个Replicate 进程的时候，可以对该进程配置为coordinated 或者 integrated 模式：
（ 1）Coordinated mode
Coordinated 模式支持所有OGG支持的数据库。在该模式下，Replicat有一个协调线程，并且协调一个或者多个coordinates thread 并行的执行 replicate的 SQL 操作。
（ 2）Integrated mode： Integrated 模式仅支持 11. 2. 0. 4 之后的Oracle 数据库。

7.1.BatchSQL

使用BATCHSQL参数来提高Replicat的性能。BATCHSQL导致Replicat将类似的SQL语句组织成数组，并以更快的速度应用它们。在正常模式下，Replicat一次应用一条SQL语句。

在BATCHSQL模式下，Replicat在内存队列中将类似的SQL语句组织成批，然后在一个数据库操作中应用每个批。批处理包含影响相同表、操作类型(插入、更新或删除)和列列表的SQL语句。例如，以下每一个都是一个批：

Inserts to table A
Inserts to table B
Updates to table A
Updates to table B
Deletes from table A
Deletes from table B

在执行批处理之前，Oracle GoldenGate 会分析它们的外键引用依赖关系。如果不同批处理中的语句之间存在依赖关系，则可能需要每个批处理多个SQL语句来维护引用完整性。

以下SQL语句不能使用BATCHSQL，包括：

包含LOB或LONG数据的语句。
包含长度超过25k的行的语句。
除了主键外，目标表还有一个或多个唯一键的语句。这些语句不能成批处理，因为如果非主键的值可能改变，BATCHSQL不能保证正确的顺序。
(SQL Server)目标表具有触发器的语句。
导致错误的语句。

7.2.Parallel Replicat并行复制模式

通过在数据库外部执行依赖项计算和并行性，Parallel Replicat提供了Integrated Replicat的所有优点。

Parallel Replicat确保所有事务都基于key依赖项(主键(PK)、外键(FK)和唯一键(UK))排序。这与Integrated Replicat有很大的不同，后者的依赖项和写入都是在数据库中完成的。

Parallel Replicat的组成部分为：

Mapper可以并行地读取Trail、映射Trail记录、将映射记录转换为Integrated Replicat LCR格式，并将LCR发送到Merger进行进一步处理。一个Mapper映射一组事务，下一个Mapper映射下一组事务。Trail信息是分割的，而Trail文件是不变的，因为它按顺序排列Trail信息。
主进程有两个线程，Collater和Scheduler。Collater从Mapper接收映射的事务，并将它们放回Trail Order中进行相关性计算。Scheduler计算事务之间的依赖关系，将事务分组为独立的batch，并将batch发送给Applier以应用于目标数据库。
Applier在batch中重新排序记录以执行数组。它将batch应用到目标数据库并执行错误处理。它还跟踪Checkpoint表中应用的事务。

此外，可以配置并行副本运行在以下模式之一:

集成模式：这类似于以前版本的Integrated Replicat，只是Parallel Replicat的Integrated模式的读取器和写入器不在数据库外部。此模式仍然使用数据库的内部机制来管理流程。
非集成模式：在这种模式下，Replicat仍然并行运行。然而，现在它完全在数据库之外。

add replicat rep2, exttrail /opt/oracle/ggate/dirdat/ld, checkpointtable ggate.checkpoint

8.Trail files

源头的 trail file：由源头抽取进程写入。
目的端的 trail file：源头传输进程传输到目的端，由目的端的server 进程写入目的端操作系统的指定路径下。

为了持续地提取与复制数据库变化，GoldenGate将捕获到的数据变化临时存放在磁盘上的一系列专有格式的文件中，这些文件就叫做Trail文件。

Trail文件可以在源DB上，也可以在目标DB上，也可以在中间系统上。在源端的叫做 Local Trail/Extract Trail，在目标端的叫做 Remote Trail。

Trail文件可将事务信息持久化，使用Checkpoint机制记录读写位置，防止单点故障。

每个在线Extract过程都必须链接到一个Trail文件，同一时刻只有一个Extract可以写入给定的Local Trail文件，所有Local Trail文件必须有不同的名字。

无论源端是否使用Data Pump，在目标端都会生成Trail文件。

8.1.存储方式、内容

Trail文件位于dirdat目录下，默认为10MB，通过 alter 命令调整 megabytes 参数可控制大小。

Trail文件命名格式：两个字符+六个数字，其中两个字符可以自己设定，六个数字是系统自动从000000到999999的序列数，当序列数超过了999999的时候，又从000000开始。

头+记录信息：10.0版本以后的GoldenGate，会在Trail文件头部存储包含Trail文件信息的记录，而10.0之前的版本不会存储该信息。每个Trail文件中的数据记录包含了数据头区域和数据区域，数据头区域中包含事务信息，数据区域包含实际抽取的数据。CSN作为事务开始的标识存储在事务日志中和Trail文件中。

为了减小系统的I/O负载，抽取的数据通过大字节块的方式存储到Trail文件中。同时为了提高兼容性，存储在Trail文件中的数据以通用数据模式(一种可以在异构数据库之间进行快速而准确转换的模式)存储。当然，根据不同应用的需求，数据也可以存储为不同的模式。

默认情况下，Extract以追加的方式写入Trail文件。当Extract异常终止时，Trail文件会被标记为需要恢复。当Extract重新启动时会追加Checkpoint之后的数据到该Trail文件中。在GoldenGate 10.0之前的版本， Extract采用的是覆盖模式，即当Extract异常终止，则会将至上次完整写入的事务数据之后的数据覆盖现有Trail文件中的内容。

Trail文件会自动老化，并且允许进程可以在不打断的情况下维护这些Trail文件，设置PURGEOLDEXTRACTS参数可使GoldenGate自动删除(过期时间(优先)/文件数)Trail文件。

最后修改时间：2026-01-19 15:02:08

「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」

关注作者

第115期：02.关于微服务的构架

1.架构

2.Manager管理模块

1.Checkpoints

Extract Checkpoints

Extract read checkpoints

Extract write checkpoints

Checkpoint table

2.Supplemental Logging and TRANDATA

Supplemental Logging

数据库级设置，分两类：

表级附加日志设置，分两类

TRANDATA

3.extract (capture) 进程

抽取和故障恢复原理

工作模式

4.EXTTRAIL

5.data pump 进程

6.Collector收集模块

7.replicate (delivery)进程

工作模式

7.1.BatchSQL

7.2.Parallel Replicat并行复制模式

8.Trail files

8.1.存储方式、内容

评论