企业官网建设流程全解析

1. 为什么OGG值得你花时间啃下来

搞数据库这行的，只要涉及到跨库同步、异构数据迁移、实时数据集成，Oracle GoldenGate（后面统一叫OGG）基本是绕不开的一座山。我最早接触OGG是在一个电信行业的计费系统项目里，源端是Oracle 11g RAC，目标端是Kafka做实时风控，中间还要经过一个Oracle中间库做数据清洗。当时团队里没人有OGG实战经验，全靠啃官方文档和踩坑硬趟，前后折腾了将近三周才把链路跑稳。后来陆续在金融、制造、政务几个行业的数据平台项目里反复用OGG，积累了不少血泪教训，今天就把从安装部署到故障排查的完整流程梳理一遍。

这篇文章适合谁看？如果你是DBA、数据工程师、ETL开发，或者正在做异构数据同步方案选型，那这篇内容应该能帮你省下不少试错时间。我会从OGG的核心架构讲起，把安装配置的关键参数、常见报错的排查思路、性能调优的实操技巧都拆开揉碎讲清楚。特别是那些官方文档里一笔带过但实际项目中一定会遇到的问题，我会重点展开。

OGG本质上是一个基于日志的结构化数据复制软件。它通过读取源数据库的在线日志或归档日志，提取数据变更（INSERT、UPDATE、DELETE、DDL等），然后将这些变更以事务为单位投递到目标端，保证数据最终一致性。和传统的ETL工具相比，OGG最大的优势是对源库几乎零侵入——它不依赖触发器、不修改应用SQL、不需要在源表上建任何额外对象，这对7×24小时运行的核心生产库来说太重要了。另一个优势是亚秒级延迟，在配置得当的情况下，源端提交的事务可以在毫秒级同步到目标端，这是DataGuard或物化视图刷新做不到的。

但OGG的复杂性也恰恰来源于它的灵活性。它支持多种拓扑结构（单向、双向、广播、聚合、级联），支持异构数据库（Oracle到MySQL、Oracle到Kafka、Oracle到Hadoop等），支持数据过滤、转换、映射。这些能力意味着配置项非常多，一个参数写错就可能导致数据不一致或者进程异常终止。所以我的经验是：先把最简单的单向复制跑通，再逐步叠加复杂功能，不要一上来就搞双向同步加数据转换，那样出了问题根本无从下手。

2. 安装前的环境准备与规划

2.1 源端与目标端的版本兼容性确认

OGG的版本兼容性是个大坑。我见过太多人拿着OGG 12c的安装包往Oracle 19c上装，结果各种报错。正确的做法是先查MOS文档（My Oracle Support上的Note 1303654.1），确认你的数据库版本对应的OGG版本。一般来说：

注意：OGG 21c开始，Oracle把版本号改成了年份命名（21c对应2021年），但核心架构和12c一脉相承，大部分参数是兼容的。

除了数据库版本，还要确认操作系统的兼容性。OGG对glibc版本有要求，比如OGG 21c在Linux 7上需要glibc 2.17以上。我遇到过在CentOS 6.9上装OGG 19c，启动时直接报GLIBC_2.14 not found，最后只能降级到OGG 12.3。

2.2 操作系统层面的准备工作

安装OGG之前，操作系统层面有几件事必须提前做：

创建专用用户和用户组。不要用root装OGG，也不要用oracle用户。我的习惯是创建独立的ogg用户，归属oinstall组。这样做的好处是权限清晰，后续排查问题时不会和数据库用户混淆。

groupadd oinstall useradd -g oinstall -m -d /home/ogg ogg passwd ogg

调整内核参数。OGG的Manager进程和Extract进程会占用一定的共享内存和信号量，建议在/etc/sysctl.conf里加上：

kernel.shmmax = 4294967296 kernel.shmall = 1048576 kernel.sem = 250 32000 100 128

改完执行sysctl -p生效。这些参数在数据库安装时通常已经调过，但如果是独立的应用服务器，需要手动加上。

创建OGG安装目录。我一般把OGG装在/u01/ogg下，目录结构规划如下：

/u01/ogg/ ├── 19c/ # OGG软件安装目录 ├── dirprm/ # 参数文件目录 ├── dirrpt/ # 报告文件目录 ├── dirtrc/ # 跟踪文件目录 ├── dirtmp/ # 临时文件目录 └── dirdat/ # 队列文件目录

其中dirdat目录要预留足够空间，因为Extract进程抽取的变更数据会先写到这里的trail文件，再由Pump进程传输到目标端。如果源端变更量大，这个目录可能增长很快。我的经验是至少预留50GB，并且用独立分区挂载，避免把根分区撑爆。

2.3 数据库层面的准备工作

源端数据库需要开启归档日志和补充日志。这是OGG能正常工作的前提条件，没有商量余地。

-- 确认归档模式 archive log list; -- 开启最小补充日志（数据库级别） ALTER DATABASE ADD SUPPLEMENTAL LOG DATA; -- 开启主键补充日志（必须） ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS; -- 如果表没有主键，需要开启所有列补充日志 ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;

提示：SUPPLEMENTAL LOG DATA (ALL) COLUMNS会显著增加归档日志量，因为每一行的所有列变更都会被记录。如果表有主键，优先用主键补充日志。只有在表确实没有主键且无法添加主键时，才用ALL COLUMNS。

另外，OGG需要访问源库的在线日志和归档日志，所以运行OGG的操作系统用户必须属于oinstall组（或者有权限读取日志文件）。如果是RAC环境，还需要确认OGG能访问所有节点的归档日志，通常通过ASM或者共享存储来实现。

3. OGG安装与初始化配置

3.1 软件安装的两种方式

OGG的安装方式有两种：图形化安装和静默安装。图形化安装适合第一次接触OGG的人，能直观看到每一步在做什么。静默安装适合批量部署，效率高。

图形化安装的步骤很简单：解压安装包，运行runInstaller，按照向导一步步走。但有几个地方容易出错：

• Inventory目录：如果服务器上已经装过Oracle数据库，Inventory目录已经存在，直接指向已有的即可。如果是全新服务器，需要新建一个Inventory目录，并且确保ogg用户对该目录有写权限。
• 安装类型选择：选"Oracle GoldenGate for Oracle Database"，不要选成"Oracle GoldenGate for Big Data"或者其他版本。
• 软件位置：建议用/u01/ogg/19c这样的路径，不要用默认的/u01/app/ogg，方便后续管理。

静默安装需要先准备一个响应文件（response file），内容大致如下：

oracle.install.responseFileVersion=/oracle/install/rspfmt_ogginstall_response_schema_v19_1_0 INSTALL_OPTION=ORA19c SOFTWARE_LOCATION=/u01/ogg/19c START_MANAGER=false MANAGER_PORT=7809 DATABASE_LOCATION=/u01/app/oracle/product/19.0.0/dbhome_1 INVENTORY_LOCATION=/u01/app/oraInventory UNIX_GROUP_NAME=oinstall

然后执行：

./runInstaller -silent -responseFile /tmp/ogg_install.rsp -waitforcompletion

安装完成后，需要执行root.sh脚本（如果有的话），然后创建OGG的目录结构。

3.2 创建OGG子目录与初始化

安装完软件后，进入OGG安装目录，执行ggsci进入命令行界面，然后创建必要的子目录：

GGSCI> CREATE SUBDIRS

这个命令会在OGG安装目录下创建dirprm、dirrpt、dirtrc、dirtmp、dirdat等子目录。如果之前手动创建过，这个命令会跳过已存在的目录。

接下来配置Manager进程。Manager是OGG的"总管"，负责启动、监控、管理其他进程。编辑dirprm/mgr.prm文件：

PORT 7809 DYNAMICPORTLIST 7810-7820 AUTOSTART EXTRACT * AUTORESTART EXTRACT *, RETRIES 5, WAITMINUTES 3 PURGEOLDEXTRACTS ./dirdat/*, USECHECKPOINTS, MINKEEPHOURS 24

逐行解释一下：

• PORT 7809：Manager的监听端口，默认就是7809，如果被占用可以改。
• DYNAMICPORTLIST：动态端口范围，Extract和Replicat进程通信时会从这里分配端口。
• AUTOSTART EXTRACT *：Manager启动时自动启动所有Extract进程。生产环境建议加上，避免服务器重启后忘记手动启动。
• AUTORESTART EXTRACT *, RETRIES 5, WAITMINUTES 3：Extract进程异常终止时自动重启，最多重试5次，每次间隔3分钟。这个配置能应对大部分临时性故障。
• PURGEOLDEXTRACTS：自动清理过期的trail文件，保留最近24小时的。这个很重要，不然dirdat目录会被撑爆。

配置完成后，启动Manager：

GGSCI> START MANAGER

然后用INFO MANAGER确认状态是Running。

3.3 源端Extract进程配置

Extract进程负责从源库抽取数据变更。配置Extract之前，需要先在数据库里创建OGG专用用户并授权：

CREATE USER ogg_user IDENTIFIED BY password; GRANT CONNECT, RESOURCE TO ogg_user; GRANT SELECT ANY DICTIONARY TO ogg_user; GRANT SELECT ANY TABLE TO ogg_user; GRANT FLASHBACK ANY TABLE TO ogg_user; GRANT EXECUTE ON DBMS_FLASHBACK TO ogg_user;

然后在GGSCI里添加Extract：

GGSCI> ADD EXTRACT ext1, TRANLOG, BEGIN NOW GGSCI> ADD EXTTRAIL ./dirdat/et, EXTRACT ext1, MEGABYTES 500

第一行添加一个名为ext1的Extract进程，从当前时间点开始抽取。第二行定义trail文件的前缀为et，每个文件最大500MB。

编辑dirprm/ext1.prm：

EXTRACT ext1 USERID ogg_user, PASSWORD password EXTTRAIL ./dirdat/et TABLE hr.employees; TABLE hr.departments; TABLE sales.orders, FILTER (ON INSERT, UPDATE, DELETE);

这里有几个关键点：

• USERID和PASSWORD是数据库连接信息。生产环境建议用USERIDALIAS配合Oracle Wallet，避免明文密码。
• TABLE指定要同步的表。可以用通配符TABLE hr.*同步整个schema。
• FILTER可以过滤DML类型，比如只同步INSERT和UPDATE，不同步DELETE。

配置完成后，启动Extract：

GGSCI> START EXTRACT ext1

用INFO EXTRACT ext1, DETAIL查看详细状态，确认Status是Running，Checkpoint Lag在合理范围内（通常小于10秒）。

3.4 目标端Replicat进程配置

Replicat进程负责将trail文件中的变更应用到目标库。配置Replicat之前，需要在目标库创建OGG用户并授权：

CREATE USER ogg_user IDENTIFIED BY password; GRANT CONNECT, RESOURCE TO ogg_user; GRANT INSERT, UPDATE, DELETE ON hr.employees TO ogg_user; GRANT INSERT, UPDATE, DELETE ON hr.departments TO ogg_user;

然后在GGSCI里添加Replicat：

GGSCI> ADD REPLICAT rep1, EXTTRAIL ./dirdat/et, CHECKPOINTTABLE ogg_user.chkpt

编辑dirprm/rep1.prm：

REPLICAT rep1 USERID ogg_user, PASSWORD password ASSUMETARGETDEFS MAP hr.employees, TARGET hr.employees; MAP hr.departments, TARGET hr.departments;

ASSUMETARGETDEFS表示源端和目标端的表结构完全一致，不需要OGG做列映射。如果结构不一致，需要用DEFGEN生成定义文件，然后用SOURCEDEFS指定。

启动Replicat：

GGSCI> START REPLICAT rep1

用INFO REPLICAT rep1, DETAIL查看状态，确认Status是Running，Lag在合理范围内。

4. 故障排查实战：那些年我踩过的坑

4.1 Extract进程无法启动的常见原因

Extract进程启动失败是最常见的问题之一。我整理了一个排查清单，按优先级排序：

第一，检查数据库连接。在GGSCI里执行DBLOGIN USERID ogg_user, PASSWORD password，如果能成功登录，说明连接没问题。如果报ORA-01017: invalid username/password，那就是密码错了或者用户被锁了。

第二，检查补充日志。执行SELECT SUPPLEMENTAL_LOG_DATA_MIN, SUPPLEMENTAL_LOG_DATA_PK FROM V$DATABASE;，确认两个值都是YES。如果SUPPLEMENTAL_LOG_DATA_PK是NO，Extract进程会报OGG-00446错误，提示缺少主键补充日志。

第三，检查归档日志路径。Extract进程需要读取归档日志，如果归档日志被删了或者路径变了，会报OGG-00446或者OGG-01091。用SELECT NAME FROM V$ARCHIVED_LOG WHERE FIRST_TIME > SYSDATE - 1;确认最近的归档日志存在。

第四，检查trail文件权限。如果dirdat目录的权限不对，Extract进程无法写入trail文件，会报OGG-01091。确保ogg用户对dirdat目录有读写权限。

实操心得：我习惯在启动Extract之前，先用START EXTRACT ext1, SKIPTRANSACTION跳过当前未提交的事务，避免因为一个长事务卡住整个进程。等进程稳定运行后，再STOP EXTRACT ext1，然后START EXTRACT ext1正常启动。

4.2 Replicat进程报错与数据不一致处理

Replicat进程的报错通常和数据本身有关。最常见的几种：

OGG-01296: Error mapping from table to table.这个错误说明源端和目标端的表结构不一致，或者列类型不匹配。解决办法是用DEFGEN重新生成定义文件，或者在Replicat参数里用COLMAP手动映射列。

OGG-01161: Column not found in target table.目标表缺少源端的某个列。需要检查目标表结构，补上缺失的列。

OGG-00868: Database error.这个错误范围很广，需要看具体的ORA错误码。如果是ORA-00001: unique constraint violated，说明目标端有重复数据，需要先清理重复数据再重启Replicat。

处理数据不一致的通用流程：

1. 停止Replicat进程：STOP REPLICAT rep1
2. 查看报错详情：VIEW REPORT rep1
3. 根据报错定位问题表和数据
4. 手动修复目标端数据
5. 跳过出错的事务：ALTER REPLICAT rep1, SKIPTRANSACTION
6. 重启Replicat：START REPLICAT rep1

注意：SKIPTRANSACTION会跳过整个事务，如果事务涉及多张表，可能导致部分表数据不一致。更安全的做法是用HANDLECOLLISIONS参数，让Replicat自动处理冲突数据。但HANDLECOLLISIONS只适合初始化阶段，长期开启会掩盖真正的数据问题。

4.3 性能问题的排查与调优

OGG的性能问题通常表现为延迟增大（Lag持续增长）。排查思路如下：

第一步，确认瓶颈在源端还是目标端。用INFO EXTRACT ext1, DETAIL查看Checkpoint Lag，如果这个值很小但INFO REPLICAT rep1, DETAIL的Lag很大，说明瓶颈在目标端。反之则在源端。

第二步，源端调优。如果Extract进程的Checkpoint Lag持续增长，可能是源库日志切换太频繁或者Extract进程处理速度跟不上。可以尝试：

• 增大EOFDELAY和EOFDELAYCSECS参数，减少Extract进程检查新日志的频率。
• 用TRANLOGOPTIONS EXCLUDEUSER排除不必要用户的变更。
• 如果源库是RAC，用TRANLOGOPTIONS DBLOGREADER启用DBLOGREADER模式，直接从ASM读取日志，性能更好。

第三步，目标端调优。如果Replicat进程的Lag持续增长，可能是目标库写入速度慢。可以尝试：

• 增大GROUPTRANSOPS参数，让Replicat批量应用事务。默认是1000，可以调到5000甚至10000。
• 用MAXTRANSOPS限制单个事务的大小，避免大事务阻塞。
• 如果目标库是Oracle，考虑用DBOPTIONS启用直接路径加载。

第四步，网络调优。如果源端和目标端之间的网络延迟高，可以调整Pump进程的TCPBUFSIZE和TCPFLUSHBYTES参数，增大网络缓冲区。

我遇到过最棘手的一次性能问题是：源端Extract进程正常，目标端Replicat进程也正常，但Lag就是降不下来。后来发现是源端有一个大事务（单事务超过100万行），Extract进程需要等整个事务提交后才能开始抽取，导致延迟飙升。解决办法是在源端应用层面把大事务拆成小事务，或者用SPLITTRANS参数让Extract进程分片处理大事务。

4.4 常见问题速查表

5. 日常运维与监控要点

5.1 关键监控指标

OGG的日常运维离不开监控。我通常关注以下几个指标：

进程状态。用INFO ALL查看所有进程的状态，确保都是RUNNING。如果有ABENDED的进程，需要立即处理。

延迟（Lag）。用INFO EXTRACT ext1, DETAIL和INFO REPLICAT rep1, DETAIL查看Checkpoint Lag和Lag。一般来说，Lag小于10秒是正常的，如果超过60秒就需要关注了。

trail文件使用情况。用INFO EXTRACT ext1, DETAIL查看Trail Name和Trail Size，确认trail文件没有积压。如果trail文件数量持续增长，说明Pump进程或Replicat进程处理不过来。

检查点。用INFO EXTRACT ext1, SHOWCH和INFO REPLICAT rep1, SHOWCH查看检查点信息，确认检查点在正常推进。

5.2 日常巡检脚本

我写了一个简单的巡检脚本，每天定时跑一次，把关键信息输出到日志文件：

#!/bin/bash export OGG_HOME=/u01/ogg/19c export LD_LIBRARY_PATH=$OGG_HOME:$LD_LIBRARY_PATH cd $OGG_HOME echo "===== OGG Daily Check =====" echo "Date: $(date)" echo "" echo "----- Process Status -----" ./ggsci <<EOF INFO ALL EOF echo "" echo "----- Extract Detail -----" ./ggsci <<EOF INFO EXTRACT ext1, DETAIL EOF echo "" echo "----- Replicat Detail -----" ./ggsci <<EOF INFO REPLICAT rep1, DETAIL EOF

这个脚本可以加到crontab里，每天早上8点跑一次，输出到/var/log/ogg_check.log。如果发现异常，再手动登录GGSCI处理。

5.3 备份与恢复策略

OGG本身的备份主要是备份参数文件和检查点。参数文件在dirprm目录下，直接打包备份即可。检查点信息存储在数据库的checkpoint表里（如果配置了CHECKPOINTTABLE），或者存储在dirchk目录下的文件里。

恢复OGG的步骤：

1. 停止所有OGG进程。
2. 恢复参数文件和检查点。
3. 启动Manager。
4. 启动Extract和Replicat。
5. 用INFO ALL确认状态。

如果检查点丢失，需要重新初始化数据。这个过程比较麻烦，需要先停止应用写入，然后导出源端数据，导入目标端，再重新配置OGG从当前时间点开始同步。所以定期备份检查点非常重要。

实操心得：我习惯每周做一次全量数据一致性校验。方法是在源端和目标端分别执行SELECT COUNT(*) FROM table_name，对比行数是否一致。如果行数不一致，再用MINUS操作找出差异数据。这个校验虽然简单，但能发现很多潜在问题。

6. 几个容易被忽略的细节

6.1 字符集问题

源端和目标端的字符集不一致是导致数据乱码的常见原因。OGG本身不做字符集转换，它只是把源端的二进制数据原样传输到目标端。如果源端是ZHS16GBK，目标端是AL32UTF8，中文数据就会乱码。

解决办法是在Extract或Replicat参数里指定字符集：

EXTRACT ext1 ... SOURCECHARSET ZHS16GBK TARGETCHARSET AL32UTF8

但更好的做法是在数据库层面统一字符集，避免OGG做转换。因为OGG的字符集转换能力有限，某些特殊字符可能转换失败。

6.2 DDL同步

OGG默认不同步DDL操作。如果源端表结构发生变化（比如加了一列），目标端不会自动同步，导致Replicat进程报错。解决办法是使用OGG的DDL同步功能，在Extract参数里加上：

DDL INCLUDE MAPPED DDLOPTIONS REPORT

然后在目标端用GGSCI执行DDLSUBST或者手动执行DDL。DDL同步是OGG的高级功能，配置起来比较复杂，建议先在测试环境验证。

6.3 大事务处理

前面提到过，大事务会导致延迟飙升。除了在应用层面拆分事务，还可以在OGG层面优化：

EXTRACT ext1 ... TRANLOGOPTIONS SPLITTRANS

SPLITTRANS让Extract进程把大事务拆成多个小事务处理，减少延迟。但要注意，SPLITTRANS可能导致事务边界模糊，如果目标端有触发器或者外键约束，可能引发问题。

6.4 网络中断处理

源端和目标端之间的网络中断是不可避免的。OGG的Pump进程和Replicat进程都有重试机制，网络恢复后会自动重连。但如果中断时间过长，trail文件可能积压过多，导致dirdat目录被撑爆。

我的做法是配置PURGEOLDEXTRACTS时留足缓冲，同时监控dirdat目录的使用率。如果使用率超过80%，就手动清理过期的trail文件。

7. 从踩坑到填坑的个人体会

OGG这个工具，入门容易精通难。我见过太多人按照官方文档一步步操作，结果卡在某个报错上几天都搞不定。问题往往不在于OGG本身有多复杂，而在于环境配置的细节太多，任何一个细节出错都会导致整个链路跑不通。

我的建议是：先在测试环境完整跑一遍单向复制，把每个步骤都记录下来，形成自己的checklist。然后在生产环境部署时，严格按照checklist执行，每完成一步就验证一步。不要跳步，不要想当然。

另外，OGG的日志和报告文件是排查问题的关键。dirrpt目录下的.rpt文件记录了进程的详细运行信息，dirtrc目录下的.trc文件记录了更底层的跟踪信息。遇到问题时，先看.rpt文件，如果不够再看.trc文件。大部分问题都能从日志里找到线索。

最后分享一个我常用的技巧：用SEND EXTRACT ext1, STATUS和SEND REPLICAT rep1, STATUS实时查看进程状态。这个命令比INFO更轻量，适合在进程运行时频繁执行，不会对性能造成明显影响。

OGG的生态还在不断演进，21c版本引入了微服务架构和REST API，管理方式有了很大变化。但核心的Extract和Replicat机制没有变，掌握了这些基础，迁移到新版本只是时间问题。希望这篇内容能帮你少走一些弯路，顺利把OGG跑起来。