ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

Oracle GoldenGate 安装配置与故障排查实战指南

2026/9/19 13:51:38 拓冰建站 浏览量
Oracle GoldenGate 安装配置与故障排查实战指南 1. 为什么OGG值得花时间啃下来搞数据库这行的只要涉及到跨库同步、异构数据迁移、双活容灾Oracle GoldenGate后面统一叫OGG基本是绕不开的一个工具。它的定位很明确基于日志的实时数据复制软件在源端抽取日志变化通过抽取进程、传输进程、复制进程三段式链路把数据变更近乎实时地投递到目标端。跟传统的物化视图刷新、DataGuard 物理同步、或者自己写触发器定时任务相比OGG 最大的优势是对源库侵入极小、支持异构、可以按表按字段过滤、能保证事务一致性。但说实话OGG 这玩意儿上手门槛不低。我见过太多人卡在安装阶段就放弃了——不是缺依赖包就是环境变量没配好要么就是建库参数不对导致抽取进程起不来。更别提后面还有长事务、字段映射、冲突处理、延迟排查这些深水区。网上很多教程要么只讲安装不讲原理要么只贴命令不讲为什么出了问题根本不知道怎么查。这篇内容我打算按我自己实际部署和运维 OGG 的经验从安装前的环境准备一路讲到常见故障的排查思路把每个环节容易踩的坑都摊开说。适合两类人看一类是刚接触 OGG、准备在测试环境搭一套练手的 DBA 或数据工程师另一类是已经在用 OGG、但遇到问题只能靠重启和重装来解决的运维同学。我会尽量把每个参数、每个命令背后的逻辑讲清楚让你知其然也知其所以然。提示本文所有操作基于 Oracle 11g/12c/19c 与 OGG 12c/19c/21c 的常见组合不同版本细节有差异我会在关键处标注。生产环境操作前务必在测试库验证。2. 安装前的环境准备与依赖梳理2.1 操作系统层面的硬性要求OGG 对操作系统的要求其实不算苛刻但有几个点必须提前确认否则安装脚本跑一半报错回头查很浪费时间。第一是内核参数。OGG 的抽取进程需要读取在线日志和归档日志对共享内存和信号量有要求。Linux 下重点看这几个# 查看当前内核参数 ipcs -l sysctl -a | grep -E shmmax|shmall|semkernel.shmmax建议不低于物理内存的一半kernel.shmall要跟 shmmax 匹配。如果源库和 OGG 部署在同一台机器上还要考虑 Oracle 实例本身已经占用的共享内存别让 OGG 抢不到资源。我遇到过一台 64G 内存的机器shmmax 只设了 4G结果抽取进程启动时报OGG-01028共享内存分配失败改完参数重启就好了。第二是文件句柄数。OGG 每个进程都会打开大量文件ulimit -n建议设到 65536 以上。检查方法ulimit -n # 临时调整 ulimit -n 65536 # 永久调整编辑 /etc/security/limits.conf oracle soft nofile 65536 oracle hard nofile 65536第三是磁盘空间。OGG 安装目录本身不大几百兆到一两个 G但trail 文件队列文件会持续增长。如果目标端消费慢或者网络抖动导致传输积压trail 文件能迅速吃掉几十上百 G。所以安装目录所在分区至少预留 50G 以上生产环境建议单独挂盘。2.2 数据库层面的前置检查OGG 对源库和目标库都有要求源库这边尤其重要因为抽取进程直接读日志。归档模式必须开启这是硬性条件。archive log list确认一下。如果没开抽取进程根本没法工作。补充日志Supplemental Logging是另一个关键点。OGG 需要额外的日志信息来还原完整的前镜像尤其是更新操作。至少要开启数据库级的最小补充日志-- 数据库级最小补充日志 ALTER DATABASE ADD SUPPLEMENTAL LOG DATA; -- 如果涉及主键更新还需要开启主键补充日志 ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS; -- 检查是否开启 SELECT supplemental_log_data_min, supplemental_log_data_pk, supplemental_log_data_ui FROM v$database;这里有个坑补充日志开启后日志量会明显增加。我见过一个库开启全列补充日志后归档日志生成速度翻了三倍。所以生产环境要评估好归档空间和备份策略别开了之后把归档区撑爆。强制日志模式FORCE LOGGING也建议开启避免有人用NOLOGGING操作导致数据变更丢失ALTER DATABASE FORCE LOGGING;目标端这边相对简单主要是确认字符集兼容、目标表结构已存在OGG 默认不建表除非用 DDL 同步、目标用户权限足够。2.3 OGG 安装包选择与目录规划OGG 的安装包按源端和目标端区分按数据库版本区分还按操作系统区分。下载的时候一定要看清楚比如191004_fbo_ggs_Linux_x64_shiphome.zip这种命名fbo是 for big data/oracle 的意思191004是版本号。目录规划我建议这样目录用途建议路径说明OGG 安装目录/u01/ogg软件本体权限 755trail 文件目录/u01/ogg/dirdat单独挂盘更好参数文件目录/u01/ogg/dirprm存放所有 prm 文件报告目录/u01/ogg/dirrpt进程报告日志目录/u01/ogg/dirlog进程日志安装用户建议用 oracle 用户或者单独建一个 ogg 用户但要有读 Oracle 相关文件的权限。千万别用 root 装后面权限问题能烦死你。注意OGG 安装目录不要放在 Oracle 的 ORACLE_HOME 下面两者环境变量会打架。我试过图省事装在 ORACLE_HOME/ogg结果LD_LIBRARY_PATH冲突ggsci 都起不来。3. 安装过程详解与常见报错处理3.1 静默安装与响应文件配置OGG 支持图形化和静默两种安装方式。生产环境基本都是静默装因为服务器通常没有图形界面。解压安装包后进入fbo_ggs_Linux_x64_shiphome/Disk1目录会看到一个response目录里面有模板响应文件。复制一份改吧改吧cd /u01/software/fbo_ggs_Linux_x64_shiphome/Disk1 cp response/oggcore.rsp ./my_ogg.rsp vi my_ogg.rsp关键参数就几个INSTALL_OPTIONORA11g SOFTWARE_LOCATION/u01/ogg START_MANAGERfalse MANAGER_PORT7809 DATABASE_LOCATION/u01/app/oracle/product/11.2.0/dbhome_1 INVENTORY_LOCATION/u01/app/oraInventory UNIX_GROUP_NAMEoinstallINSTALL_OPTION根据你的数据库版本选11g 选 ORA11g12c 选 ORA12c19c 选 ORA19c。DATABASE_LOCATION是 ORACLE_HOME 路径这个必须对否则后面抽取进程找不到库。然后执行./runInstaller -silent -responseFile /u01/software/fbo_ggs_Linux_x64_shiphome/Disk1/my_ogg.rsp安装过程大概几分钟看到Successfully Setup Software就成功了。3.2 安装报错的典型场景报错一DISPLAY not set。这是图形化安装没设 DISPLAY 导致的用静默安装就能绕过。如果非要用图形化得先配好 X11 转发。报错二The inventory location is not writable。oraInventory 目录权限不对用 root 执行一下chown -R oracle:oinstall /u01/app/oraInventory。报错三Check if the DISPLAY variable is set或者安装到一半卡住。这种情况多半是响应文件里DATABASE_LOCATION写错了或者 ORACLE_HOME 不存在。检查一下echo $ORACLE_HOME和响应文件里写的是否一致。报错四libnnz11.so: cannot open shared object file。这是LD_LIBRARY_PATH没包含 ORACLE_HOME/lib。在 ogg 用户的环境变量里加上export LD_LIBRARY_PATH$ORACLE_HOME/lib:/u01/ogg:$LD_LIBRARY_PATH我自己的习惯是在 ogg 安装目录下建一个ogg.env文件把所有环境变量写进去每次用之前 source 一下避免污染全局环境# /u01/ogg/ogg.env export OGG_HOME/u01/ogg export ORACLE_HOME/u01/app/oracle/product/19.0.0/dbhome_1 export ORACLE_SIDorcl export LD_LIBRARY_PATH$ORACLE_HOME/lib:$OGG_HOME:$LD_LIBRARY_PATH export PATH$OGG_HOME:$ORACLE_HOME/bin:$PATH3.3 创建 OGG 专用数据库用户安装完软件只是第一步还得在源库和目标库分别建 OGG 用的数据库用户。这个用户需要不少权限我一般直接给 DBA 角色省事但生产环境建议按最小权限原则来。源库用户需要CREATE USER ogg_src IDENTIFIED BY ogg_src DEFAULT TABLESPACE users; GRANT DBA TO ogg_src; GRANT SELECT ANY DICTIONARY TO ogg_src; GRANT FLASHBACK ANY TABLE TO ogg_src; GRANT EXECUTE ON DBMS_FLASHBACK TO ogg_src;目标库用户需要CREATE USER ogg_tgt IDENTIFIED BY ogg_tgt DEFAULT TABLESPACE users; GRANT DBA TO ogg_tgt; GRANT SELECT ANY DICTIONARY TO ogg_tgt; GRANT INSERT, UPDATE, DELETE ON 业务表 TO ogg_tgt;建完用户后在 ggsci 里配置凭证GGSCI DBLOGIN USERID ogg_src, PASSWORD ogg_src GGSCI ADD CHECKPOINTTABLE ogg_src.ggschkptCHECKPOINTTABLE是 OGG 用来记录抽取和复制进度的表非常重要。如果这张表丢了或者损坏进程恢复时会出大问题。4. 核心进程配置与实操演练4.1 Manager 进程配置Manager 是 OGG 的守护进程所有其他进程都由它管理。配置在dirprm/MGR.prmPORT 7809 DYNAMICPORTLIST 7810-7820 AUTOSTART EXTRACT * AUTORESTART EXTRACT *, RETRIES 5, WAITMINUTES 3 PURGEOLDEXTRACTS /u01/ogg/dirdat/*, USECHECKPOINTS, MINKEEPHOURS 24 LAGREPORTHOURS 1 LAGINFOMINUTES 30 LAGCRITICALMINUTES 60逐行解释一下。PORT是 Manager 监听端口其他进程通过这个端口注册。DYNAMICPORTLIST是动态端口范围抽取和复制进程通信时会从这里分配。AUTOSTART让 Manager 启动时自动拉起所有 Extract 进程。AUTORESTART是自动重启策略进程异常退出后重试 5 次每次间隔 3 分钟。PURGEOLDEXTRACTS是 trail 文件清理策略保留 24 小时内的配合检查点使用避免误删还在用的文件。LAGREPORT系列是延迟告警阈值超过 60 分钟会在报告里标红方便监控。启动 ManagerGGSCI START MANAGER GGSCI INFO MANAGER4.2 源端抽取进程配置抽取进程负责从源库日志里抓取变更。配置dirprm/EXT1.prmEXTRACT EXT1 SETENV (ORACLE_SIDorcl) SETENV (NLS_LANGAMERICAN_AMERICA.AL32UTF8) USERID ogg_src, PASSWORD ogg_src EXTTRAIL /u01/ogg/dirdat/ea TABLE hr.employees; TABLE hr.departments;SETENV设置环境变量NLS_LANG一定要跟源库字符集匹配否则中文会乱码。EXTTRAIL指定本地 trail 文件路径ea是文件前缀OGG 会自动生成ea000000、ea000001这样的文件。TABLE指定要抽取的表支持通配符比如TABLE hr.*;抽取 hr 下所有表。也可以加过滤条件TABLE hr.employees, WHERE (department_id 10);添加并启动抽取进程GGSCI ADD EXTRACT EXT1, TRANLOG, BEGIN NOW GGSCI ADD EXTTRAIL /u01/ogg/dirdat/ea, EXTRACT EXT1 GGSCI START EXT1 GGSCI INFO EXT1TRANLOG表示从在线日志抽取BEGIN NOW表示从当前时间点开始。如果要初始化数据通常先用BEGIN NOW跑起来然后用 expdp/impdp 做全量再让复制进程从全量结束的 SCN 开始。4.3 传输进程与目标端复制进程传输进程Data Pump负责把本地 trail 文件通过网络传到目标端。配置dirprm/PUMP1.prmEXTRACT PUMP1 RMTHOST 192.168.1.100, MGRPORT 7809, COMPRESS RMTTRAIL /u01/ogg/dirdat/ra PASSTHRU TABLE hr.employees; TABLE hr.departments;RMTHOST是目标端 IP 和 Manager 端口COMPRESS开启压缩跨广域网时能省不少带宽。RMTTRAIL是目标端的 trail 路径。PASSTHRU表示不做任何转换直接透传性能最好。目标端复制进程配置dirprm/REP1.prmREPLICAT REP1 SETENV (ORACLE_SIDorcl) SETENV (NLS_LANGAMERICAN_AMERICA.AL32UTF8) USERID ogg_tgt, PASSWORD ogg_tgt ASSUMETARGETDEFS DISCARDFILE /u01/ogg/dirrpt/REP1.dsc, APPEND, MEGABYTES 100 MAP hr.employees, TARGET hr.employees; MAP hr.departments, TARGET hr.departments;ASSUMETARGETDEFS表示源端和目标端表结构一致不用额外定义。如果结构不同需要用DEFGEN生成定义文件。DISCARDFILE是丢弃文件复制失败的数据会写到这里排查问题时很有用。添加并启动GGSCI ADD REPLICAT REP1, EXTTRAIL /u01/ogg/dirdat/ra GGSCI START REP1 GGSCI INFO REP14.4 验证同步链路是否正常配置完之后得验证数据是不是真的同步过去了。最直接的办法是在源端做 DML然后去目标端查-- 源端 INSERT INTO hr.employees (employee_id, last_name, email) VALUES (999, TEST, TESTX.COM); COMMIT; -- 目标端 SELECT * FROM hr.employees WHERE employee_id 999;如果目标端能查到说明链路通了。再用STATS命令看统计信息GGSCI STATS EXT1 GGSCI STATS REP1重点看Total inserts、Total updates、Total deletes是否跟源端操作一致以及Lag延迟是否在可接受范围。5. 故障排查实战与避坑经验5.1 进程起不来怎么办这是最常见的问题。START EXT1之后INFO EXT1显示ABENDED先看报告文件dirrpt/EXT1.rpt里面会有具体错误码。OGG-01028 共享内存分配失败前面提过调大shmmax和shmall。OGG-00446 无法打开 trail 文件检查EXTTRAIL路径是否存在、权限是否正确。我遇到过目录被误删的情况重建目录后ADD EXTTRAIL重新添加即可。OGG-01296 无法连接数据库多半是USERID/PASSWORD错了或者ORACLE_SID不对。用DBLOGIN单独测试一下GGSCI DBLOGIN USERID ogg_src, PASSWORD ogg_src如果这里就报错说明数据库连接有问题跟 OGG 本身无关。OGG-00868 无法找到表定义源端表没有开启补充日志或者表结构变了但 OGG 缓存没更新。执行FLUSH EXTRACT EXT1刷新一下。5.2 延迟越来越大的排查思路延迟是 OGG 运维的核心指标。LAG分两种LAG AT CHKPT和LAG AT RBA。前者是检查点延迟后者是当前读取位置的延迟。如果LAG AT RBA很大但LAG AT CHKPT正常说明抽取进程在追日志但还没追到最新位置。延迟大的常见原因原因排查方法解决思路源库日志生成过快看归档日志生成速率评估是否业务高峰必要时限流网络带宽不足ping 延迟、iftop 看流量开启 COMPRESS或升级带宽目标端写入慢看目标库 AWR、锁等待优化目标表索引减少触发器大事务看 trail 文件大小突增拆分大事务或调大MAXTRANSOPS抽取进程参数不合理看报告文件调整FETCHOPTIONS、TRANSMEMORY我遇到过一次延迟飙到 8 小时最后查出来是源端有个批量删除操作一次性删了 200 万行OGG 在目标端逐行删除根本追不上。后来跟业务商量改成分批删每次 1 万行延迟就降下来了。5.3 数据不一致的定位方法数据不一致是最头疼的问题因为往往发现的时候已经积累了很久。定位思路是从目标端反查源端或者用VERIFY工具。OGG 自带的VERIFY可以比对源端和目标端数据GGSCI VERIFY REP1, TABLE hr.employees但这个工具对大表很慢生产环境慎用。更实用的办法是基于主键做分段比对比如按employee_id每 10 万一段用MINUS找差异-- 在目标端执行找源端有但目标端没有的 SELECT employee_id FROM hr.employeessource MINUS SELECT employee_id FROM hr.employees;发现不一致后不要急着全量重刷。先看DISCARDFILE里有没有记录再看复制进程报告里有没有OGG-01296之类的错误。很多时候是某几条记录因为约束冲突被丢弃了补上就行。5.4 日常运维的避坑清单最后整理一份我踩过的坑按优先级排注意以下每一条都是真实教训建议逐条核对。trail 文件目录别跟安装目录放一起。有次安装分区满了OGG 直接挂掉连 ggsci 都进不去。后来单独挂盘再没出过这事。PURGEOLDEXTRACTS一定要配USECHECKPOINTS。不加这个参数OGG 会按时间删文件可能把还没消费的 trail 删掉导致数据丢失。DDL 同步要单独配置。OGG 默认不同步 DDL源端加个字段目标端不知道复制进程直接报错。要么用DDL INCLUDE配置要么建立变更管理流程DDL 手动同步。字符集不一致会出大问题。源端ZHS16GBK目标端AL32UTF8中文直接变问号。要么统一字符集要么在复制进程里配SOURCEDEFS做转换。长事务监控要常态化。GGSCI SEND EXTRACT EXT1, STATUS可以看当前事务状态。超过 1 小时的事务要告警否则一旦回滚OGG 要处理大量回滚记录延迟爆炸。定期检查检查点表。SELECT * FROM ogg_src.ggschkpt;看看有没有异常增长。这张表太大也会影响性能。升级 OGG 版本要谨慎。跨大版本升级比如 12c 到 19c参数文件格式可能有变化先在测试环境跑通再上生产。监控要覆盖进程状态、延迟、trail 文件大小三个维度。只监控进程状态不够进程活着但延迟 10 小时等于没监控。6. 性能调优的几个关键参数6.1 抽取进程调优抽取进程的性能瓶颈通常在读日志和写 trail。几个关键参数-- 增大事务内存减少磁盘 IO TRANSMEMORY 64M -- 每次读取的日志块大小 FETCHOPTIONS FETCHPKUPDATECOLS, USESNAPSHOT -- 并行读取日志 -- 需要配合多个抽取进程使用TRANSMEMORY默认 32M大事务多的时候调到 64M 或 128M 能明显减少 trail 文件碎片。FETCHOPTIONS里的USESNAPSHOT在源库压力大时有用但会增加 undo 使用。6.2 复制进程调优复制进程的瓶颈通常在目标端写入。关键参数-- 批量提交大小 BATCHSQL BATCHESPERQUEUE 100 OPSPERBATCH 1000 -- 并行复制 -- 需要按主键拆分配置多个 REPLICATBATCHSQL开启批量 SQL 模式把多条 DML 合并成一条对批量插入场景提升巨大。但要注意BATCHSQL模式下如果有一条失败整批都会回滚排查起来麻烦。建议先在测试环境验证。6.3 网络传输调优跨机房同步时网络往往是瓶颈。除了COMPRESS还可以调整 TCP 缓冲区RMTHOST 192.168.1.100, MGRPORT 7809, COMPRESS, TCPBUFSIZE 4194304, TCPFLUSHBYTES 4194304TCPBUFSIZE是 TCP 发送缓冲区TCPFLUSHBYTES是刷新阈值。这两个参数调大能提升吞吐但会占用更多内存。我一般设 4M效果比较均衡。7. 写在最后的一些个人体会OGG 这东西说难也难说简单也简单。难在细节多、坑多简单在只要链路通了它就能稳定跑很久。我维护过一套跑了三年没重启过的 OGG 链路也见过每天都要重启的。差别就在于前期配置是否规范、监控是否到位、出问题是否知道怎么查。如果你刚开始接触 OGG我的建议是先在测试环境完整搭一套从安装到同步到故障模拟每个环节都手动做一遍。特别是故障模拟故意把目标库停了、把网络断了、把表结构改了看看 OGG 什么反应报告文件里长什么样。这些经验比看十篇教程都管用。另外OGG 的官方文档其实写得不错尤其是Error Messages和Troubleshooting两章遇到报错先查文档大部分问题都有解释。社区里 Oracle 官方论坛和 Stack Overflow 也有不少案例搜错误码基本能找到答案。最后分享一个小技巧在dirprm目录下建一个README文件把每个进程的用途、负责人、依赖关系写清楚。过半年再回来看你会感谢自己的。