Oracle GoldenGate在线迁移数据库：从原理到实战的完整指南

做了这么多年数据库迁移，我最怕听到的一句话就是"停机窗口只有一小时"。业务方轻描淡写，DBA心里翻江倒海。后来OGG同步迁移数据库成了我的主力方案，Oracle GoldenGate这东西，说白了就是靠解析归档日志和在线日志，把源端的增删改操作近乎实时地搬到另一端，迁移过程中业务完全不用停。这篇文章把我实际做OGG同步迁移数据库的完整思路、参数配置、踩坑记录和切换方案整理出来，希望能帮到正在折腾OGG的同路人。

适合读这篇内容的，主要是有一定Oracle基础、想用OGG做在线迁移或异构同步的DBA、运维工程师和数据架构师。纯零基础也没关系，我会把原理讲得接地气一点，命令和参数都是可以直接抄作业的。

1. OGG迁移前必须想清楚的三件事

1.1 OGG到底适合哪种迁移场景

OGG的全称是Oracle GoldenGate，核心能力是日志级实时同步。它的工作对象不是业务表本身，而是数据库产生的REDO日志。每次提交事务，OGG从日志里恢复出对应的SQL操作，封装成自定义格式的trail文件，再通过网络传到目标端重放。整个过程对源库的正常业务几乎没有侵入，这才是它敢做在线迁移的底气。

在我实际接触的项目里，OGG用得最多的场景有三类：

第一类是同构Oracle到Oracle的在线迁移。源库和目标库都是Oracle，只是物理机器、存储或版本不同。这类场景OGG最拿手，原生支持度高，DDL和DML同步都靠谱。

第二类是异构数据库同步。比如Oracle到MySQL、Oracle到PostgreSQL这类，目标库可以是完全不同的产品。OGG有对应的适配器，但注意功能和性能会比同构场景打折扣，字段类型映射、函数转换都得提前核对。

第三类是做数据分发或读写分离。一个源端同时同步到多个目标端，比如给报表库、测试库、灾备库分别喂数据。OGG天然支持一对多的拓扑，省去业务方自己写同步程序的麻烦。

很多人一听说"数据库迁移"就想到停机、导出、导入、再停机、再验证。OGG的诱惑在于：全量数据初始化可以在业务运行期间完成，之后增量日志自动追平，最后切换只需极短的可控窗口。对于7x24小时在线的系统，这是近乎唯一优雅的路径。

1.2 为什么不是Data Guard，也不是expdp/impdp

很多刚接触OGG的人会问：Oracle自带Data Guard，为什么非要额外引入OGG？我简单做个对比，你一下子就明白。

Data Guard的优点在于几乎零数据丢失，但它本质上是物理备库，目标库必须是Oracle，而且你不能只同步某几张表。expdp/impdp适合做一次性全量迁移，但要停业务、停应用，数据量一大根本扛不住。OGG正好补齐了这两者中间的空白。

补充一点：现在Oracle也在推自己的在线迁移套件，但OGG依然是跨异构、跨版本场景中最成熟的选择。如果源库是Oracle，目标也是Oracle，版本跨度又大（比如11g迁19c），OGG的兼容性表现相当好，基本不用改表结构。

1.3 OGG工作流程快速扫盲

OGG的同步链路由三部分组成，记住这三件套后面所有配置都好理解了。

抽取进程（Extract）负责在源端读取日志，把变更解析出来。它会注册到源库的日志挖掘机制里，相当于替你去读REDO和归档，然后把操作写到本地trail文件。投递进程（Data Pump）是抽取和复制之间的搬运工，把本地trail文件通过网络传到目标端的远程trail文件，它的作用是解耦源端压力，避免网络抖动直接影响抽取。复制进程（Replicat）在目标端读取远程trail文件，把里面的增删改操作应用到目标库。

很多人配置OGG翻车，就是没搞清这三个进程的定位。把抽取进程直接投递到目标端行不行？技术上行，但生产环境我强烈不推荐。Data Pump就像缓冲区，网络断了它可以暂停源端抽取吗？不能。有了Data Pump，源端抽取只写本地磁盘，网络有问题受影响的是投递，源端业务和抽取进程依然稳定运行。这是架构设计上一个很小的细节，但生产环境里能救你的命。

另外还有一个容易忽略的组件：管理进程（Manager）。它不处理数据，只负责拉起、监控其他进程，处理端口通信和参数动态调整。配置OGG先启动Manager，这是所有操作的前提。

2. 架构设计与参数规划

2.1 环境评估清单

每次做OGG迁移，我都要求把下面这张表填完再动手，省得半路陷入被动。

源端Oracle库版本和目标端版本，两端是否在OGG支持的兼容列表内。我自己见过一个案例，源库是11.2.0.4，目标端是19c，OGG版本选对了完全没问题，但如果版本选错，同步过程中会出现莫名奇妙的解析错误。

字符集是隐形杀手。源库和目标库的字符集不一致，比如源库ZHS16GBK、目标库AL32UTF8，同步后中文乱码的坑我踩过不止一次。OGG有自己的字符集转换机制，但前提是两端数据库字符集声明要正确，且映射表要提前测。建议在联调阶段专门造一批含生僻字和特殊符号的数据跑一遍。

主键和唯一约束必须提前检查。OGG同构同步时，如果没有主键，它会退化成基于整行所有字段的匹配，性能差不说，遇到同ID多版本数据还可能错乱。无主键表最稳妥的做法是补齐主键，实在补不了就用OGG的KEYCOLS参数指定业务唯一键。

补充日志是否开启。OGG要完整解析日志，必须开补充日志。这个操作可以在线执行，但会影响归档量大小，所以要在低峰期操作，并且事先评估日志增长。

网络联通性。源端和目标端之间需要开放指定端口（默认7809，我习惯自定义）。另外OGG传输的数据是文本型的操作记录，压缩后相对紧凑，但频繁更新的大表流量依然不小，最好先做压测。

2.2 网络带宽与磁盘空间估算

OGG同步迁移数据库能不能安稳跑起来，网络和磁盘是两大命门。

先谈网络。OGG的trail文件是压缩过的，但压缩比取决于数据类型。字符型多的表压缩比高，数字型多的表压缩比低，我通常按源端归档日志产生速率的1.5到3倍来估算网络流量。举个例子：源库高峰期每小时产生10GB归档日志，平均每GB日志解析出的OGG流量大约在200MB到500MB之间（和事务类型相关），一个小时的OGG同步流量就是2GB到5GB。如果要求延迟在10秒以内，每秒至少要有1MB到3MB的稳定带宽。一般跨机房专线问题不大，但如果是公网传输，这个估算就要收紧。

再谈磁盘。源端本地trail、目标端远程trail都需要磁盘。trail文件默认大小是100MB，保留时长我习惯配两天，也就是磁盘要能撑住48小时不断网。计算方法是：日增归档量乘以每GB产生的OGG流量，再乘2。比如日增50GB归档，流量按1.5倍算，每天trail约75GB，两天就是150GB。源端和目标端各留200GB比较稳妥。千万别把trail目录放在系统盘，也千万别开什么自动清理脚本去删正在写入的文件，否则同步进程直接挂。

2.3 初始化方式选型

OGG迁移数据库的经典流程，是先全量后增量，也就是Data Initial Load配合持续同步。全量数据的初始化有两条路：

第一条是用OGG自带方式，通过RMTTRAIL和EXTFILE把源表数据抽出来生成trail文件，再由复制进程加载到目标端。优点是流程统一，一套工具搞定，但遇到超大表或大规模数据时性能一般，过程也不太好监控。

第二条是用第三方工具做全量，比如用expdp导出再用impdp导入，或者用其他数据同步工具拉全量，同时OGG只负责追增量。这种方式全量速度快、可控性强，但难点在于如何保证"全量导入完成那一时刻"的增量起点和OGG抽取起点对齐。实操中我一般这样处理：先在源端启动抽取进程，记录下启动时的日志SCN，作为基线SCN。然后做全量导出导入时，用这个SCN做一个闪回查询或一致性导出，保证全量数据对应的是基线SCN之前的状态。全量导入完成后，再启动复制进程，让它从同样的SCN开始应用增量。这样就能做到两边数据最终一致。

补充一下，无论用哪种初始化方式，我都建议在目标库上先禁用外键约束和触发器等对象。同步过程中大量数据写入，有外键约束会显著拖慢应用速度，遇到数据顺序问题还可能报错。

3. 实操步骤：从搭环境到追平数据

3.1 源端与目标端的准备工作

我用一个最小可用的同构场景来演示步骤：源端和目标的Oracle库都是Linux环境，OGG版本选择19.1。

源端目标端都需要创建OGG操作系统用户，安装OGG软件，设置环境变量ORACLE_HOME、ORACLE_SID和GG_HOME。安装过程没什么特别，按照官方文档解压、运行runInstaller就行。但我强调两点：第一，OGG安装目录不要和Oracle软件放同一个目录，以免权限混乱；第二，服务器上要有足够的内存和文件描述符限制，否则并发高时进程起不来。

源端数据库这边的动作：

-- 启用最小补充日志 ALTER DATABASE ADD SUPPLEMENTAL LOG DATA; -- 启用所有列补充日志（为了无主键表也能准确定位） ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS; -- 开启归档模式 SHUTDOWN IMMEDIATE; STARTUP MOUNT; ALTER DATABASE ARCHIVELOG; ALTER DATABASE OPEN;

生产环境开启补充日志会增大归档量，我实测大约增加5%到15%，取决于表结构更新频率。别慌，这个开销是OGG工作的基础，不能省。另外还需要设置数据库的GLOBAL_NAMES和REDO大小之类，但一般保持默认即可。

目标端数据库创建OGG用户并授权，只需要连库操作权限，源端抽取用户需要能访问DBA视图的权限。

CREATE USER ogg_rep IDENTIFIED BY ogg_rep_pass DEFAULT TABLESPACE users QUOTA UNLIMITED ON users; GRANT CONNECT, RESOURCE TO ogg_rep; GRANT SELECT ANY TABLE TO ogg_rep;

3.2 配置抽取进程

进入GGSCI命令行：

./ggsci dblogin userid ogg_ext, password ogg_ext_pass ADD EXTRACT ext_full, TRANLOG, BEGIN NOW ADD EXTTRAIL /ogg/dirdat/lt, EXTRACT ext_full

上面的命令创建了一个名为ext_full的抽取进程，从现在开始读日志，trail文件写到/ogg/dirdat/lt。这里有个细节：trail文件名是两字符前缀加序号，我习惯用lt、rt这种前缀。别用太长的前缀，OGG只识别两字符。

编辑该进程的参数文件，我一般直接用vi编辑：

-- 文件：dirprm/ext_full.prm EXTRACT ext_full USERID ogg_ext, PASSWORD ogg_ext_pass EXTTRAIL /ogg/dirdat/lt TABLE ogg_mig.t_orders; TABLE ogg_mig.t_customer;

注意点：TABLE参数可以写多个，也可以写通配，比如TABLE ogg_mig.*;。但如果你只想同步少数几张表，明确写出来更清晰。参数文件里不支持注释符号哦，参数行以--开头只是我个人习惯，OGG参数文件用的是#注释，大家别学我写错。

3.3 配置投递进程

投递进程在源端本地，它读取抽取进程生成的trail文件，通过网络传到目标端。配置如下：

ADD EXTRACT dp_full, EXTTRAILSOURCE /ogg/dirdat/lt ADD RMTTRAIL /ogg/dirdat/rt, EXTRACT dp_full

参数文件：

-- 文件：dirprm/dp_full.prm EXTRACT dp_full USERID ogg_ext, PASSWORD ogg_ext_pass RMTHOST 目标端IP, MGRPORT 7809 RMTTRAIL /ogg/dirdat/rt TABLE ogg_mig.t_orders; TABLE ogg_mig.t_customer;

RMTHOST指定目标端地址和Manager端口。投递进程的端口通信就是在这一层发生的。如果网络有防火墙，记得放行这个端口。

3.4 配置复制进程

目标端的GGSCI里，先登录目标库，创建复制进程：

dblogin userid ogg_rep, password ogg_rep_pass ADD REPLICAT rep_full, EXTTRAIL /ogg/dirdat/rt, BEGIN NOW

参数文件：

-- 文件：dirprm/rep_full.prm REPLICAT rep_full USERID ogg_rep, PASSWORD ogg_rep_pass ASSUMETARGETDEFS MAP ogg_mig.t_orders, TARGET ogg_mig.t_orders; MAP ogg_mig.t_customer, TARGET ogg_mig.t_customer;

这里需要解释两个重要参数。ASSUMETARGETDEFS表示源端和目标端表结构完全一致，允许OGG不做字段映射，性能最好。如果两端表结构有差异，比如字段名不同、多几个计算列，就必须创建DEFGEN文件描述源端表结构，用SOURCEDEFS替代该参数。另一个是MAP的映射关系，支持按表名、通配符、甚至按行过滤条件，灵活度非常高。

3.5 全量初始化与增量追赶

用OGG自带方式做全量加载时，复制进程要专门跑加载模式。先把复制进程改成加载模式：

STOP REPLICAT rep_full EDIT PARAMS rep_full

把之前的参数清空，写成：

REPLICAT rep_full USERID ogg_rep, PASSWORD ogg_rep_pass ASSUMETARGETDEFS MAP ogg_mig.t_orders, TARGET ogg_mig.t_orders, INITLOAD; MAP ogg_mig.t_customer, TARGET ogg_mig.t_customer, INITLOAD;

然后启动抽取进程写全量trail，启动复制进程做加载。加载完成后，再把复制进程参数改回正常模式，重新启动，继续追增量。整个过程要注意一点：全量加载到一半时，源端业务还在写新的数据，抽取进程已经把这些新日志记录到trail里了，但复制进程处于加载模式时不会应用这些增量，等切换回正常模式后才开始追。追平的速度取决于网络和数据库性能，我遇到过全量一天、追增量半小时的情况，也遇到过追了十几个小时的，和平常的更新量有关。

4. 参数文件示例与避坑记录

4.1 一份生产可用的参数示例

下面这组参数是我从某个迁移项目里简化出来的，同构Oracle到Oracle，包含三张业务表和一张配置表，已经很贴近生产可用的状态。

源端抽取进程/dirprm/ext_orders.prm：

EXTRACT ext_orders USERID ogg_ext, PASSWORD ogg_ext_pass EXTTRAIL /ogg/dirdat/lt TRANLOGOPTIONS EXCLUDEUSER ogg_ext REPORTCOUNT EVERY 10000 RECORDS GETTRUNCATES TABLE ogg_mig.t_orders; TABLE ogg_mig.t_order_detail, KEYCOLS (order_id, line_no); TABLE ogg_mig.t_customer; TABLE ogg_mig.t_config;

简单解读一下：TRANLOGOPTIONS EXCLUDEUSER让抽取进程不记录OGG用户自身的操作，避免自同步死循环；REPORTCOUNT每隔一万条记录打一次日志，方便监控进度；GETTRUNCATES是同步TRUNCATE操作，不需要的话就移除。ORDER_DETAIL表没有主键，用KEYCOLS指定业务联合键，解决定位问题。

投递进程参数提过了，不重复。目标端复制进程/dirprm/rep_orders.prm：

REPLICAT rep_orders USERID ogg_rep, PASSWORD ogg_rep_pass ASSUMETARGETDEFS HANDLECOLLISIONS REPORTCOUNT EVERY 10000 RECORDS MAP ogg_mig.t_orders, TARGET ogg_mig.t_orders; MAP ogg_mig.t_order_detail, TARGET ogg_mig.t_order_detail; MAP ogg_mig.t_customer, TARGET ogg_mig.t_customer; MAP ogg_mig.t_config, TARGET ogg_mig.t_config;

HANDLECOLLISIONS的作用是当写入目标端遇到主键冲突时自动更新对应行，典型用在初始化加载阶段。注意这个参数在正常运行阶段要移除，否则遇到真正的主键冲突会被吞掉，脏数据就进来了。

4.2 高频问题排查实录

OGG跑起来之后，真正磨人的是各种边缘问题。我把自己DIY过的问题大致归类，方便大家按图索骥。

主键冲突。最常见的是初始化阶段目标库还有些旧数据没清干净。处理方式是先清空目标表，再用HANDLECOLLISIONS跑一遍全量。已经跑到正常模式还报主键冲突，优先怀疑是不是在同步过程中源端有跨表事务或者延迟提交，导致两个事务到达目标端的顺序颠倒了。

无主键表数据错乱。用OGG同步无主键表，默认会尝试匹配整行。遇到源表某一行被UPDATE两次，两次变化压缩到同一个trail里，目标端可能只更新一次或者匹配到别的行。用KEYCOLS指定业务键能解决大部分问题，但业务键本身必须稳定、唯一，否则还是白搭。

LOB字段不同步。默认情况下OGG对CLOB、BLOB的同步需要额外配置。不是字段类型不支持，而是需要指定LOB的传输模式。如果你发现CLOB字段在目标端是NULL，检查参数里有没有加TRANSFORMS或者用LOBWRITE模式，另外注意大对象和普通字段的合并拆分。稳妥做法是先在测试环境把大字段的实际值测一遍。

字符集乱码。目标端显示问号或乱码，先检查两端数据库字符集，再用OGG的SETENV NLS_LANG参数指定源端语言环境。有些老库的NLS_LANG配置本身就脏，这会导致OGG抽取进程读取日志时做错误的字节转换。对于这种问题，唯一的解决办法是源端固定NLS_LANG后重启抽取进程，并在应用层确认业务写入时的字符集约定。

序列不同步。和数据无关，但迁移后最容易漏。源表的某个自增列如果由序列生成，OGG只会同步表数据，不会同步序列的CURRVAL。你在目标端继续插入新记录，很可能立刻撞上主键冲突。解决办法简单粗暴：在切换前把源端序列的LAST_NUMBER读出来，在目标端用alter sequence restart with重新设置。

4.3 GGSCI日常运维速查

用GGSCI命令行管理OGG，高频命令我整理了一份速查表：

我习惯每天早上看一眼info all和lag，延迟超过15秒就上view report查原因。OGG的报错其实很直白，开头都是OGG-XXXXX，后面跟着英文解释，装个英文翻译插件就能看明白。

5. 割接切换与回退方案

5.1 切换流程设计

增量追平之后，真正让人觉得紧张的其实是切换那一刻。我的标准流程是四步走。

第一步，切换前再做一次全量校验。对比源端和目标端的关键表count(*)和数据校验和，比如对每个数字列求sum，对字符列算长度总和。这个粗糙但很快，能发现明显差异。

第二步，停源端写业务。这是整个迁移里唯一需要短暂停机的环节，通常在凌晨低峰期进行。停源端应用或数据库，把最后一段日志完整抽取完。

第三步，确认两边的SCN和日志点一致。通过info ext_orders查看抽取进程已经追到源库最新SCN，手动加一条测试数据在目标端验证能正常同步，验证完成后这条数据不再保留。

第四步，把应用连接切换到目标库。这一步改动应用的数据源配置或DNS指向，切换完成后观察应用日志、数据库告警日志，再对重要的交易数据做抽样比对。

四个步骤里，前两步通常占一两个小时，第三步几乎瞬间完成。真正写切换窗口的其实很短，这也是OGG在线迁移最吸引人的地方。

5.2 回退方案

没人愿意聊回退，但每个成熟的迁移方案都必须有回退预案。OGG的回退比传统停机迁移要简单得多：切换完成后，如果发现目标库业务异常，需要回退到源库，只要源库没有被后续写入污染，把源端连接重新指回原库就行。

更保险的做法是提前建立反向同步。我的建议是：如果切换窗口之后有24小时以上的业务观察期，再决定是否拆除反向同步。反向同步的配置和正向基本一样，只是源端和目标端互换。注意序列问题也要互换，别让反向同步在目标端生成的序列和源端现有序列冲突。当然反向同步会增加维护负担，如果业务能容忍一小时的中断，其实不做反向同步，直接回退到手工补数据也完全可行。

5.3 迁移后的验证清单

迁移完成后，我习惯用下面这份清单做收尾验证：

抽查源端和目标端各业务表的数据量和关键字段值，重点看日期时间字段和状态字段。检查应用日志有无报错，特别关注数据库连接、锁等待和死锁相关记录。执行几轮关键业务访问，比如登录、查余额、提交订单，确认目标库上的表现行为正常。检查后台定时任务和存储过程是否正常调度，有些环境的目标库没有配置相关JOB。检查告警平台里数据库连接池错误、慢SQL告警是否上升。切换后头两天，密切观察目标数据库性能指标，比如CPU、IO、命中率。

其中最容易遗漏的是JOB和数据库链接。很多老系统会在数据库里直接配DBLINK和JOB，切换目标库后这些对象要一并迁移，否则应用能连上但后台任务全挂了。

最后再分享一个我自己的习惯：切换完成后的当天，不管多累，我都会把OGG的view report日志和切换过程的命令记录整理成一份文档归档。这个习惯救过我很多次，因为每次迁移项目总有那么一两处环境差异，事后复盘时翻旧档比翻聊天记录高效太多。数据库迁移这事儿就是经验叠加的活，踩过的坑越多，后面的路越顺。真心建议你把第一次OGG迁移做成一个可复用的脚本包，下一次换汤不换药，稳中有快。