Oracle GoldenGate 这套东西第一次接触的人很容易被它企业级的外表唬住觉得配置复杂、概念繁多、报错看不懂。但真正在生产环境里跑过几轮之后你会发现OGG 的核心逻辑其实非常朴素它就是在源端把数据库的变更日志读出来通过网络传到目标端再重放进去。难的不是理解这个模型难的是安装时的依赖、参数文件的细节、以及出故障时那一堆看起来毫无头绪的报错。这篇内容面向的是正在或即将上手 OGG 的 DBA 和运维工程师尤其是那些第一次部署就卡在安装环节、或者同步跑着跑着突然断了却不知道从哪查起的人。我会把从环境准备、安装、配置到故障排查的完整链路拆开讲重点放在那些官方文档里一笔带过、但实际会让你卡半天的坑上。全文基于常见的生产实践总结具体版本行为可能有差异以你实际环境为准。1. 装 OGG 之前先把这几个环境前提确认清楚很多人装 OGG 失败根子不在 OGG 本身而在环境没准备好。OGG 对操作系统、数据库版本、字符集、目录权限都有比较明确的要求这些条件不满足安装脚本可能跑得下去但后续抽取进程一启动就报错。1.1 数据库层面的前置检查OGG 抽取的是数据库的在线日志或归档日志所以源端数据库必须开启归档模式并且要开启最小补充日志和表级补充日志。这一步如果漏了抽取进程启动时会直接报 OGG-00868 之类的错误提示找不到需要的日志记录。具体要做的检查确认数据库处于归档模式archive log list如果显示未启用归档需要先切到归档模式并重启到 mount 状态执行。开启数据库级最小补充日志ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;对需要同步的表开启表级补充日志ALTER TABLE schema.table ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;这里有个容易忽略的点最小补充日志是数据库级的表级补充日志是逐表加的。很多人只加了数据库级的结果同步时发现 UPDATE 操作丢失了主键信息导致目标端更新错行。表级补充日志建议用 ALL COLUMNS虽然会多写一点日志但能保证所有列的前镜像都记录在案避免各种边界问题。另外源端和目标端的数据库字符集最好保持一致。如果源端是 ZHS16GBK、目标端是 AL32UTF8中文数据同步过去可能出现乱码。这个不是 OGG 的锅是字符集转换的问题但排查起来很费时间不如一开始就对齐。1.2 操作系统与目录权限的坑OGG 安装目录的权限问题是最隐蔽的坑之一。安装 OGG 的操作系统用户必须对 OGG 安装目录有完整的读写执行权限同时这个用户还要能访问数据库的告警日志目录和归档日志目录。我见过好几次这样的情况安装用户是oracle但 OGG 目录建在/ogg下属主是root结果oracle用户跑ggsci时各种权限拒绝。解决办法很简单安装前先确认mkdir -p /ogg chown -R oracle:oinstall /ogg chmod -R 775 /ogg还有一个细节是共享内存和信号量。OGG 的 Manager 进程和各个 Extract、Replicat 进程之间通过共享内存通信如果操作系统的共享内存段限制太小进程启动会失败。检查ipcs -lm里的max seg size一般建议不低于 4GB。如果不够需要调整/etc/sysctl.conf里的kernel.shmmax和kernel.shmall。提示调整内核参数后需要执行sysctl -p生效生产环境调整前最好确认没有其他应用依赖当前值。1.3 版本匹配这件事别想当然OGG 的版本必须和数据库版本、操作系统版本匹配。比如 OGG 19c 支持 Oracle 11.2.0.4 及以上OGG 21c 对数据库版本要求更高。如果你在 11g 数据库上装 21c 的 OGG可能装得上但跑不起来。我的建议是先确定数据库版本再去查对应 OGG 版本的认证矩阵。Oracle 官方有专门的Oracle GoldenGate 认证矩阵文档里面列了每个 OGG 版本支持的数据库、操作系统、补丁级别。花十分钟查一下比装完再返工省事得多。2. 安装过程本身不复杂复杂的是这些细节OGG 的安装严格来说就是解压加跑脚本但细节没处理好后面全是麻烦。这一节把安装的完整流程和几个关键决策点讲清楚。2.1 安装包获取与解压的正确姿势OGG 的安装包是一个压缩文件解压后直接就是 OGG 的目录结构。这里要注意的是解压的目标目录就是最终的安装目录OGG 没有独立的安装步骤解压即安装。# 假设安装包是 fmw_19.1.0.0.4_ogg_linux_x64.zip unzip fmw_19.1.0.0.4_ogg_linux_x64.zip -d /ogg cd /ogg # 解压后应该能看到 ggsci、Manager 等文件 ls -l解压后第一件事是设置环境变量。OGG 依赖ORACLE_HOME和LD_LIBRARY_PATH如果这两个没设对ggsci启动时会报找不到库文件。export ORACLE_HOME/u01/app/oracle/product/19.0.0/dbhome_1 export LD_LIBRARY_PATH$ORACLE_HOME/lib:/ogg:$LD_LIBRARY_PATH export PATH$ORACLE_HOME/bin:/ogg:$PATH注意LD_LIBRARY_PATH里 OGG 目录要放在$ORACLE_HOME/lib后面否则可能加载到错误的库版本。2.2 用 ggsci 创建 Manager 并配置安装完成后进入ggsci命令行创建 Manager 进程的参数文件。Manager 是 OGG 的总控进程负责启动、监控、管理其他进程。GGSCI (hostname) 1 create subdirs这个命令会在 OGG 目录下创建dirprm、dirrpt、dirdat、dirchk等子目录。dirprm放参数文件dirrpt放报告dirdat放 trail 文件dirchk放检查点。这些目录一个都不能少少了哪个后面都会报错。然后编辑 Manager 参数文件dirprm/mgr.prmPORT 7809 DYNAMICPORTLIST 7810-7820 AUTOSTART EXTRACT * AUTORESTART EXTRACT *, RETRIES 5, WAITMINUTES 3 PURGEOLDEXTRACTS /ogg/dirdat/*, USECHECKPOINTS, MINKEEPHOURS 24这里几个参数值得说明PORT 7809是 Manager 的监听端口源端和目标端要能互相访问这个端口。DYNAMICPORTLIST是动态端口范围Extract 和 Replicat 之间通信会用。AUTORESTART让进程异常退出后自动重启重试 5 次每次间隔 3 分钟。这个在生产环境很有用能扛住一些瞬时故障。PURGEOLDEXTRACTS自动清理旧的 trail 文件保留 24 小时。不配这个dirdat目录会越涨越大最后把磁盘撑爆。配置完启动 ManagerGGSCI start manager GGSCI info managerinfo manager能看到 Manager 的运行状态和端口确认是 RUNNING 就对了。2.3 源端和目标端的网络连通性验证这一步很多人跳过结果后面 Extract 和 Replicat 连不上排查半天。在配置之前先在源端用telnet或nc测试目标端 Manager 端口是否可达# 在源端执行 telnet target_host 7809 # 或者 nc -zv target_host 7809如果连不上先查防火墙。Linux 上firewall-cmd --list-ports看端口有没有放行云环境还要查安全组规则。这个检查花两分钟能省掉后面半小时的排查。3. 配置抽取和复制进程参数文件是重头戏OGG 的核心配置就是两个进程源端的 Extract 负责抽取目标端的 Replicat 负责应用。参数文件的写法直接决定了同步能不能跑通、跑得稳不稳。3.1 Extract 进程的参数设计先创建 Extract 进程GGSCI add extract ext1, tranlog, begin now GGSCI add exttrail /ogg/dirdat/lt, extract ext1第一条命令创建抽取进程ext1tranlog表示从在线日志抽取begin now表示从当前时间点开始。第二条命令指定本地 trail 文件的前缀是/ogg/dirdat/lt。然后编辑dirprm/ext1.prmEXTRACT ext1 SETENV (ORACLE_HOME /u01/app/oracle/product/19.0.0/dbhome_1) SETENV (ORACLE_SID orcl) USERIDALIAS ogg_user DOMAIN OracleGoldenGate RMTHOST target_host, MGRPORT 7809 RMTTRAIL /ogg/dirdat/rt TABLE hr.employees; TABLE hr.departments;几个关键点USERIDALIAS用的是 OGG 的凭证存储比直接写明文密码安全。创建凭证用GGSCI add credentialstore然后alter credentialstore add user ogg_user password xxx alias ogg_user。RMTHOST指定目标端主机和 Manager 端口。RMTTRAIL指定远程 trail 文件前缀。TABLE指定要同步的表支持通配符如hr.*。提示如果只同步部分列可以用TABLE hr.employees, COLS (id, name, salary);这种写法但要注意目标端表结构必须匹配。3.2 Replicat 进程的参数设计在目标端创建 ReplicatGGSCI add replicat rep1, exttrail /ogg/dirdat/rt编辑dirprm/rep1.prmREPLICAT rep1 SETENV (ORACLE_HOME /u01/app/oracle/product/19.0.0/dbhome_1) SETENV (ORACLE_SID orcl) USERIDALIAS ogg_user DOMAIN OracleGoldenGate ASSUMETARGETDEFS MAP hr.employees, TARGET hr.employees; MAP hr.departments, TARGET hr.departments;ASSUMETARGETDEFS表示源端和目标端表结构完全一致不需要额外的定义文件。如果两边结构有差异需要用DEFGEN生成定义文件这个后面单独说。3.3 源端和目标端表结构不一致怎么办这是实际项目里很常见的情况源端表多了几个列或者列名不一样。这时候ASSUMETARGETDEFS就不够用了需要用DEFGEN工具在源端生成表定义文件传到目标端。源端执行GGSCI edit param defgen内容DEFSFILE /ogg/dirdef/hr.def USERIDALIAS ogg_user DOMAIN OracleGoldenGate TABLE hr.employees; TABLE hr.departments;然后运行cd /ogg ./defgen paramfile dirprm/defgen.prm生成的hr.def文件传到目标端的dirdef目录Replicat 参数里改成SOURCEDEFS /ogg/dirdef/hr.def这样 OGG 就知道源端表的真实结构能正确做列映射。4. 故障排查从报错到根因的完整链路OGG 出故障时报错信息往往很笼统比如进程异常终止具体原因藏在报告文件里。这一节把常见的几类故障和排查方法讲透。4.1 进程起不来先看报告文件任何进程启动失败第一件事是看dirrpt目录下对应的报告文件。比如ext1进程的报告是dirrpt/ext1.rptrep1是dirrpt/rep1.rpt。报告文件里会记录进程启动的完整过程包括读取参数文件、连接数据库、打开 trail 文件等每一步的结果。报错通常在文件末尾格式类似ERROR OGG-00446 Could not find archived log for sequence 1234 thread 1.看到具体错误码再去查 OGG 的错误码文档基本能定位到方向。4.2 常见故障分类与处理我把实际遇到过的故障归成几类方便对照排查故障现象可能原因排查方向Extract 启动报 OGG-00868补充日志未开启检查数据库和表级补充日志Extract 报找不到归档日志归档被删除或未同步检查归档保留策略必要时从备份恢复Replicat 报 OGG-01296目标端应用数据出错看报告里的具体 SQL 和错误行进程频繁重启网络抖动或资源不足查 Manager 日志和系统资源同步延迟持续增大目标端应用慢或大事务查 Replicat 的 lag 和正在处理的事务4.3 一个真实的排查案例有次生产环境 Replicat 突然停了报告里报OGG-01296说应用某条 UPDATE 时违反唯一约束。但奇怪的是源端这条记录是正常的。排查过程是这样的先看 Replicat 报告找到报错的具体表名和主键值。去目标端查这条记录发现目标端已经存在一条相同主键的记录。回源端查发现源端这条记录是刚 INSERT 的但目标端早就有了。进一步查发现是之前有一次同步中断后手工补数据补重了。根因是手工干预导致的数据不一致。解决办法是删掉目标端重复记录然后让 Replicat 重新处理。但这个案例的教训是OGG 同步过程中尽量不要手工改目标端数据一旦改了后续同步很容易出问题。注意如果确实需要手工补数据补完之后要确认 Replicat 的检查点位置避免重复应用或漏应用。4.4 用 logdump 分析 trail 文件当报告文件的信息不够时可以用logdump工具直接看 trail 文件里的内容。这个工具能显示 trail 里每条记录的操作类型、表名、列值。cd /ogg ./logdump进入交互界面后Logdump 1 open /ogg/dirdat/lt000000 Logdump 2 ghdr on Logdump 3 detail on Logdump 4 nextghdr on显示记录头信息detail on显示详细列值next看下一条。通过这个能确认 trail 里到底有没有数据、数据对不对。5. 让同步跑得稳日常运维的几个关键动作配置跑通只是开始真正考验人的是长期运维。这一节讲几个让 OGG 稳定运行的关键动作。5.1 监控 lag 和检查点OGG 的同步延迟用 lag 表示GGSCI info all能看到每个进程的 lag 值。正常情况下 lag 应该在秒级如果持续增大说明目标端应用跟不上。GGSCI info all Program Status Group Lag at Chkpt Time Since Chkpt MANAGER RUNNING EXTRACT RUNNING EXT1 00:00:00 00:00:03 REPLICAT RUNNING REP1 00:00:05 00:00:01Lag at Chkpt是检查点延迟Time Since Chkpt是距离上次检查点的时间。两个都要看如果Time Since Chkpt很大但 lag 是 0可能是进程卡住了。5.2 处理大事务OGG 处理大事务时容易出问题。比如源端一个事务更新了 100 万行Extract 会把这个事务完整抽到 trail 里Replicat 应用时如果中间失败回滚和重试都很慢。应对办法是配置MAXTRANSOPS参数让 OGG 把大事务拆成多个小事务处理-- 在 Replicat 参数里加 MAXTRANSOPS 10000这样每个事务最多处理 10000 条操作超过就分段提交。代价是失去了事务的原子性如果业务对一致性要求极高需要权衡。5.3 定期检查磁盘空间dirdat目录会随着同步不断增长虽然配了PURGEOLDEXTRACTS但如果同步中断trail 文件不会被清理磁盘可能被撑爆。建议加个监控定期检查dirdat目录大小和磁盘剩余空间。我一般设两个阈值目录超过 50GB 告警磁盘剩余低于 20% 告警。du -sh /ogg/dirdat df -h /ogg5.4 参数文件变更的正确流程修改参数文件后需要重启进程才能生效。但重启有讲究先stop extract ext1或stop replicat rep1。修改dirprm下的参数文件。start extract ext1重新启动。如果是 Replicat重启前要确认检查点位置避免重复应用。可以用GGSCI info replicat rep1, detail看详细的检查点信息。提示生产环境修改参数前最好先在测试环境验证确认没问题再上生产。6. 几个容易被忽略但很关键的细节最后补充几个实际踩过的坑都是那种不知道就等着出事的类型。6.1 时间同步问题源端和目标端的系统时间如果差太多OGG 的检查点时间戳会对不上可能导致同步异常。建议两端都配置 NTP 时间同步偏差控制在秒级以内。6.2 字符集转换的隐性成本如果源端和目标端字符集不同OGG 会做转换这个转换是有性能开销的。数据量大时转换可能成为瓶颈。能对齐字符集就对齐对不齐的话要预留足够的性能余量。6.3 表结构变更的处理源端表加列、改列类型OGG 不会自动感知。需要在源端和目标端同时做 DDL 变更。如果变更影响同步需要重新生成 DEF 文件。必要时重启 Extract 和 Replicat。DDL 同步是 OGG 的一个薄弱环节很多版本需要额外配置 DDL 支持或者用触发器辅助。这块建议单独规划不要指望 OGG 自动搞定所有 DDL。6.4 凭证存储的备份OGG 的凭证存储credential store是加密的如果丢失所有用USERIDALIAS的进程都起不来。建议定期备份dirprm下的凭证文件并且记住主密钥。# 备份凭证存储 cp /ogg/dirprm/*.cs /backup/ogg/这个文件不大但丢了很麻烦重建需要重新录入所有数据库凭证。6.5 版本升级的注意事项OGG 升级不是简单替换文件。升级前要停止所有进程。备份整个 OGG 目录。确认新版本和数据库、操作系统的兼容性。升级后检查参数文件是否有不兼容的语法。升级过程中最容易出问题的是参数文件语法变更新版本可能废弃了某些旧参数。升级前把参数文件过一遍对照新版本的文档确认。我在实际运维中最大的体会是OGG 的稳定性很大程度上取决于前期的规划。环境检查做扎实、参数配置想清楚、监控做到位后面基本不用怎么操心。反而是那些先跑起来再说的部署后面问题一个接一个。另外遇到报错不要慌报告文件里基本都有线索顺着错误码查下去大部分问题都能定位到。真正难的是那些数据不一致的问题这类问题往往需要结合业务逻辑去分析光看 OGG 的日志不够。