fbo_ggs 实战：Oracle GoldenGate 19.1 安装与调优

简介Oracle热备工具FBO_GGS_Linux_x64_shiphome是针对Oracle数据库实时复制与灾备场景的完整安装包面向DBA、运维工程师和需要搭建GoldenGate热备环境的技术人员用于解决异地主备库数据同步与故障切换问题。压缩包共419个文件大小约529.98MB以jar、so、properties、xml等为主涵盖核心组件运行库、配置文件、图形界面资源、JRE环境及安装脚本并附有OGG 19.1.0.0.4版本说明PDF和README.txt便于安装与升级参考。目前已有713人学习下载适合需要离线部署GoldenGate的团队直接获取。通过该安装包可掌握Extract、Replicat、Manager等进程配置方法理解参数文件与GGSCI命令使用同时借助内置的各类库文件和配置模板快速在Linux x64环境下搭建热备复制链路。1. 为什么说 fbo_ggs 是 Oracle 热备里最容易被低估的包做 Oracle 灾备的人对 GoldenGate 不陌生但第一次拿到fbo_ggs_Linux_x64_shiphome.zip这个包时多半会被它的名字绕晕。fbo_ggs 全称是 Fast Backup Oracle GoldenGate实际上就是 Oracle GoldenGate 在 Linux x64 平台上的标准安装介质shiphome 是 Oracle 安装包的传统目录结构。这个 zip 解开后里面有OGG_WinUnix_Rel_Notes_19.1.0.0.4.pdf、OGG-19.1.0.0-README.txt以及一批 fontconfig、cacerts 文件初次接触的人会误以为这只是个证书或字体依赖包但它其实是完整的 OGG 19.1 分发件解压即用、无需 Oracle 数据库软件本体。对需要在 Linux x64 上搭建实时复制链路、做灾备切换或异构数据同步的 DBA 和运维工程师来说这个包的价值在于它同时覆盖了安装、配置和运行时依赖三个层面。本文从包结构讲起把组件选型、参数配置、排错思路和性能调优一次说透。2. 包结构拆解shiphome 不只是安装脚本2.1 解压后先分清三类文件拿到安装包后第一件事不是急着./runInstaller而是把目录里的文件按用途归类。这个包里最常见的文件有三组一组是.bfc后缀的 fontconfig 文件覆盖 SuSE、Turbo、RedHat 5/6 等发行版一组是cacerts和blacklisted.certs这类 Java 证书库还有一组是.pdf和.txt的文档说明。很多人会忽略.bfc文件但实际上 OGG 的 Extract 进程在部分 Linux 发行版上渲染日志和报告时需要字体配置缺了它会出现fontconfig相关的告警虽然不影响核心复制功能但会干扰后续排错时的日志阅读。我的习惯是把这些.bfc文件按操作系统版本对比一遍确认与当前发行版匹配后再执行安装避免安装器在预检查阶段报fontconfig相关的 warning。cacerts和blacklisted.certs属于 Java 运行时证书库。OGG 19.1 的 Manager 进程和部分集成功能依赖 JDK证书库用于建立加密连接和 Microservices Architecture 的 RESTful 通信。如果目标机是内网隔离环境这些证书文件通常可以直接沿用如果要对接公网或跨域同步需要额外导入企业 CA 证书否则启动 Manager 时会报 SSL 握手失败。具体命令是keytool -importcert -alias ogg_ca -file ca.cer -keystore cacerts -storepass changeit注意导入前先备份原始 cacerts。2.2 版本说明文件要先读哪几页OGG_WinUnix_Rel_Notes_19.1.0.0.4.pdf这份文档接近两百页不需要通读但有两个部分必须看一个是 New Features 章节确认 19.1 里新增的集成抽取方式是否会给现有架构带来变化另一个是 Known Issues 和 Bugs Fixed 部分这里面提到的补丁号往往就是后续生产环境踩坑的根源。OGG-19.1.0.0-README.txt更要逐字读一遍它里面有安装前置条件、内核参数要求和快速启动步骤。README 里明确写了 19.1 在 Linux x64 上要求 glibc 2.17 以上且不建议与 Oracle 11.2.0.4 的老库共用一套环境变量这些信息 PDF 里虽然也有但 README 的表述更直接。2.3 包名里的版本线索fbo_ggs中的 fbo 是 Full Backup Option 语境下的叫法安装后在$OGG_HOME下能看到ggsci、extract、replicat、mgr等可执行文件。版本号 19.1.0.0.4 对应 Oracle GoldenGate 19.1 的第四个补丁集。这个版本对 Oracle 数据库的支持范围是 11.2.0.4 到 19c对异构数据库的支持包括了 MySQL、PostgreSQL、SQL Server所以在确认业务场景时先核对源库和目标库的版本是否落在支持矩阵内避免装完才发现不兼容。文件/目录用途重要程度fontconfig.*.bfc字体渲染配置影响日志与报告输出低缺失产生告警cacertsJava 信任证书库用于加密通信中加密链路必配blacklisted.certs被吊销/不受信任证书列表中安全审计用OGG_WinUnix_Rel_Notes_19.1.0.0.4.pdf版本说明、新特性、已知问题高升级前必读OGG-19.1.0.0-README.txt安装指南、系统要求、快速启动高装前必读3. 复制链路的核心机制与进程选型3.1 四大进程谁在什么时候干活GoldenGate 的实时复制本质上是一个日志消费管道。源端数据库把 DML 操作写进 redo logExtract 进程捕获这些变更并翻译成 GoldenGate 专有的 trail 文件格式。Pump 进程负责把 trail 文件从源端传输到目标端这一步是可选的——如果 Extract 直接写到目标端的远程 trail就不需要单独的 Pump但大多数生产环境会保留 Pump因为这样做可以把网络传输和日志捕获解耦即使网络抖动也不会阻塞 Extract 继续抓取。目标端的 Replicat 进程读取 trail 文件把变更应用到目标库。Manager 是总控进程负责启停其他三个进程、创建 trail 文件、处理端口通信。这个链路里有几个容易误解的细节。第一Extract 捕获的是提交后的数据Oracle redo log 里只有已提交事务的变更所以 GoldenGate 天然不会复制未提交数据这是它和触发器复制最本质的区别。第二trail 文件是 GoldenGate 自己的格式不是 SQL 文本所以不能用文本编辑器直接查看要看内容必须用ggsci里的logdump工具。第三Replicat 在目标端的应用方式默认是批量的它会缓存一批事务后一次性应用到目标库这保证了吞吐量但也意味着目标库的数据在短时间内可能滞后于源库这个滞后量可以通过info replicat xxx查看 lag 值。3.2 抽取模式选集成还是经典19.1 版本里 Extract 有两种运行模式经典抽取方式Classic Capture和集成抽取方式Integrated Capture。经典抽取方式直接读 redo log兼容性最广但需要数据库开启补充日志而且对 redo log 的并发写入压力有感知。集成抽取方式利用数据库的 logmining server 作为数据源由数据库自己抓取 redo 并交给 Extract这样 Extract 不直接碰 redo log 文件对源库的性能影响更小尤其是在源库是大事务高并发场景下优势明显。选集成模式的前提是源库和企业版 Oracle且版本不能低于 11.2.0.4。配置上多了两步先注册 Extract 进程到数据库DBMS_CAPTURE_ADM.REGISTER_SCHEMA_CAPTURE或者通过 GGSCI 的REGISTER EXTRACT命令再授予必要的角色权限DBMS_GOLDENGATE_AUTH.GRANT_ADMIN_PRIVILEGE。经典模式则没有这些前置要求只需要GRANT SELECT ANY TRANSACTION, FLASHBACK ANY TABLE给抽取用户。如果源库不是企业版比如是 Standard Edition就只能用经典模式这一点在选型时要提前确认否则部署到一半才发现许可证不支持会很被动。3.3 参数文件里的门道每个进程都有一个参数文件放在$OGG_HOME/dirprm目录下命名规则是进程名加.prm后缀。先看 Extract 的参数文件最基本的配置是这样的EXTRACT ext1 USERIDALIAS ogg_source EXTTRAIL ./dirdat/et TABLE scott.emp; TABLE scott.dept;EXTRACT指定进程名必须和启动时用add extract注册的名字一致。USERIDALIAS指向凭据存储中的别名这个别名在GGSCI里通过ALTER CREDENTIALSTORE ADD USER维护参数文件里不直接写密码避免明文泄漏。EXTTRAIL定义本地 trail 文件的路径和前缀./dirdat/et表示在dirdat目录下生成以et开头的文件。TABLE每行声明一张要捕获的表支持通配符比如TABLE scott.*;表示捕获 scott 模式下所有表但要注意通配符写法对性能有一定影响因为 Extract 需要维护一个动态的表清单。Pump 的参数文件更简单EXTRACT pump1 USERIDALIAS ogg_source RMTHOST 192.168.1.20, MGRPORT 7809 RMTTRAIL ./dirdat/rt TABLE scott.emp; TABLE scott.dept;RMTHOST和MGRPORT指定目标端 Manager 的 IP 和端口RMTTRAIL是目标端 trail 文件的位置。这里有个约定源端 Extract 写本地 trailPump 读本地 trail 再写到远程所以 Extract 的EXTTRAIL和 Pump 的RMTTRAIL在dirprm里是分开配置的不能混用。如果把源端 trail 路径写错Pump 启动时会报no trail file found一类错误排查时可以先用ggsci里的info extract ext1确认本地 trail 是否正常生成。Replicat 的参数文件和 Extract 对称REPLICAT rep1 USERIDALIAS ogg_target MAP scott.emp, TARGET scott.emp; MAP scott.dept, TARGET scott.dept;MAP左侧是源表右侧是目标表支持表名映射比如源端是PROD.EMP目标端是ODS.EMP写法是MAP PROD.EMP, TARGET ODS.EMP;。如果需要做字段映射或数据转换可以在MAP后面加COLMAP子句这是 GoldenGate 自带的数据整形能力适合做异构表结构同步。4. 从按下回车到链路跑通部署与配置实操4.1 解压安装和环境变量把fbo_ggs_Linux_x64_shiphome.zip上传到服务器假设放在/u01/ogg/software目录下cd /u01/ogg/software unzip fbo_ggs_Linux_x64_shiphome.zip cd fbo_ggs_Linux_x64_shiphome export JAVA_HOME/usr/lib/jvm/java-1.8.0 export PATH$JAVA_HOME/bin:$PATH ./runInstallerrunInstaller是图形化安装器如果服务器没有图形界面可以加-silent参数配合响应文件执行静默安装。最常见的问题是JAVA_HOME变量指向了 Oracle 自带的 JDK 版本而 OGG 19.1 需要 Java 8解决方法是显式指定系统安装的 OpenJDK 路径。安装完成后ogg_home目录下应该能看到ggsci在 bash 里执行echo export OGG_HOME/u01/ogg ~/.bash_profile echo export PATH$OGG_HOME:$PATH ~/.bash_profile source ~/.bash_profile which ggsci如果which ggsci能输出路径说明安装层没有问题了。注意OGG_HOME不要和ORACLE_HOME混在一起两个环境变量并存时LD_LIBRARY_PATH的搜索顺序容易导致 OGG 链接到错误的 Oracle 客户端库表现为启动 Manager 时提示找不到libclntsh.so。4.2 数据库侧的准备步骤在启动 GGSCI 之前必须先完成数据库层面的前期工作顺序错了后面会多花几倍时间排错。第一步是开启最小补充日志ALTER DATABASE ADD SUPPLEMENTAL LOG DATA; ALTER DATABASE FORCE LOGGING;补充日志是让 redo log 包含更多列信息因为 GoldenGate 在目标端执行 DML 时不仅需要被修改的列还需要知道主键或唯一键。如果不开补充日志源表有主键但 redo 里没有记录主键列的变化前镜像Replicat 在目标端就没法定位要更新的行会报ERROR并中断复制。第二步是创建 GoldenGate 数据库用户并授权CREATE USER ogq_admin IDENTIFIED BY your_password; GRANT CONNECT, RESOURCE, DBA TO ogg_admin; EXEC DBMS_GOLDENGATE_AUTH.GRANT_ADMIN_PRIVILEGE(ogg_admin);DBMS_GOLDENGATE_AUTH.GRANT_ADMIN_PRIVILEGE这个包是 Oracle 11.2.0.4 以上版本才有的它的作用是授予用户操作 LogMiner 和捕获环境的权限。如果用经典抽取模式可以不走这个包直接给SELECT ANY TRANSACTION和FLASHBACK ANY TABLE权限但集成模式逃不掉这一步。4.3 GGSCI 里的标准操作序列GGSCI 是 GoldenGate 的命令行管理工具所有进程的启停、状态检查和日志追踪都在这里面完成。下面是完整的最小操作序列GGSCI CREATE SUBDIRS GGSCI ADD CREDENTIALSTORE GGSCI ALTER CREDENTIALSTORE ADD USER ogg_adminora19c IDENTIFIED BY your_password GGSCI DBLOGIN SOURCE ogg_adminora19cCREATE SUBDIRS在OGG_HOME下生成dirprm、dirrpt、dirdat等标准子目录参数文件和后缀报告都放在这里。ADD CREDENTIALSTORE创建凭据库之后ALTER CREDENTIALSTORE ADD USER把数据库用户名密码存到凭据库里这样参数文件里用USERIDALIAS引用别名而不必暴露密码。DBLOGIN验证数据库连接是否正常连接成功后才能继续做下面的注册操作。注册抽取进程GGSCI REGISTER EXTRACT ext1 DATABASE GGSCI ADD EXTRACT ext1, INTEGRATED TRANLOG, BEGIN NOW GGSCI ADD EXTTRAIL ./dirdat/et, EXTRACT ext1REGISTER EXTRACT在源库的数据字典里登记了这个抽取进程只有注册过的 Extract 才能使用集成抽取模式。ADD EXTRACT的第一个参数是进程名第二个参数指定模式INTEGRATED TRANLOG表示集成抽取经典模式则写成TRANLOG。BEGIN NOW的意思是捕获从现在开始的事务如果要做初始化装载先跑一次数据库全量导出再启动抽取进程。源端配置完成后分别启动 Manager 和 ExtractGGSCI START MANAGER GGSCI START EXTRACT ext1 GGSCI INFO EXTRACT ext1INFO EXTRACT输出的内容里有几个关键字段要会看Status必须是RUNNINGCheckpoint表示当前读取到的 redo log 位置Lag显示源库与 Extract 之间的延迟Log Read Checkpoint如果长期不动说明 Extract 没有抓到新事务要么是补充日志没开要么是日志归档模式没启动。如果有异常看view report ext1打开 Extract 的进程报告里面会有详细的报错行号。4.4 目标端配置的坑目标端要先启动 Manager然后创建 Replicat 进程并指定 checkpoint 表。checkpoint 表是目标数据库上一张专门记录复制进度的表它让 Replicat 在异常重启后能知道自己已经应用到哪里避免重复应用或漏应用。建表命令在 GGSCI 里执行GGSCI DBLOGIN TARGET ogg_adminora19c GGSCI ADD CHECKPOINTTABLE这里最容易犯的错是忘了DBLOGIN TARGET直接执行ADD CHECKPOINTTABLEGGSCI 会报找不到默认数据库的错误。Replicat 注册命令GGSCI ADD REPLICAT rep1, INTEGRATED, EXTTRAIL ./dirdat/rt, CHECKPOINTTABLE ggadmin.checkpoint GGSCI START REPLICAT rep1INTEGRATED表示集成应用模式19.1 里集成应用通过数据库的 apply server 批量应用事务性能远优于经典模式的单条 SQL 逐条执行。如果你的数据库是标准版INTEGRATED会报错只能退回到经典模式命令改成ADD REPLICAT rep1, EXTTRAIL ./dirdat/rt。4.5 常见启动失败与排查路径链路跑不通时先看 Manager 有没有起来再看 Extract 和 Replicat 各自的报告文件。最常见的三种异常情况是端口被防火墙拦截、参数文件里的别名对不上凭据库里的名字、目标端表结构不一致。端口问题表现为 Extract 启动后处于STARTING状态但不进RUNNING一般是被防火墙拦了执行telnet 目标IP 7809验证。别名对不上表现为USERIDALIAS报credential store not initialized或alias not found执行ALIASES命令看当前凭据库里的实际名字。表结构不一致则是 Replicat 启动后立即 abend报告里提示map scott.emp找不到列多半是源表和目标表字段有增减。以上三类都用view report打开对应的进程报告定位速度会快很多。5. 参数调优与异常数据处理的进阶实践5.1 大事务和批量 DML 的吞吐量瓶颈GoldenGate 的默认参数偏保守生产环境直接拿默认值跑吞吐量大概率达不到预期。影响吞吐量的关键参数有三个EXTTRAIL的大小和数量、RMTHOST的压缩选项、Replicat 的BATCHSQL模式。Extract 侧在参数文件里可以加GGSCI ALTER EXTRACT ext1, TRANLOGOPTIONS ALTLOGDEST GGSCI EDIT PARAMS ext1在参数文件里调整RMTHOST的传输参数或者在 Extract 参数中增加TRAILBYTES设置这些调整影响的是单个 trail 文件的大小trail 文件写满后会切换下一个太小会导致频繁切换略增 I/O 开销。更常见的做法是打开传输压缩RMTHOST 192.168.1.20, MGRPORT 7809, COMPRESSCOMPRESS参数用在网络带宽紧张的跨机房链路上LZ 压缩在中高并发场景下能减少大概一半的传输流量代价是源端 CPU 会多花一点这个取舍在网络不是瓶颈时划不来。Replicat 侧调整的是事务合并粒度REPLICAT rep1 BATCHSQL BATCHTRANSOPS 1000BATCHSQL开启后 Replicat 会把多条同类 SQL 合并成一条数组绑定操作交给数据库BATCHTRANSOPS 1000表示最多累积 1000 个事务后执行一次批量应用。这个参数适合大量小事务的场景比如交易流水表如果是仓库里的大事务单事务行数动辄几十万批量合并反而会拖慢因为数组绑定内存占用太大容易触发 PGA 压力。5.2 只需要复制部分数据的过滤配置不是所有表都需要全量同步有的业务表数据量大但只有关键字段需要用到目标库在全量复制时会占用大量网络和磁盘。GoldenGate 的TABLE和MAP语句里支持WHERE条件过滤和字段投影MAP PROD.ORDERS, TARGET ODS.ORDERS, WHERE (STATUS PAID AND AMOUNT 100), COLMAP (USED 1, ORDER_ID ORDER_ID, CUSTOMER_ID CUSTOMER_ID, TOTAL_AMOUNT AMOUNT);WHERE子句在源端就做了行过滤不符合条件的行不会进入 trail 文件这比全量传到目标端再过滤节省得多。COLMAP定义字段的映射关系左侧是目标列右侧是源列或常量常量可以用来标记数据来源比如USED 1就给目标表打上了固定值。使用过滤时要注意一点时时更新主键或唯一键列如果被过滤掉Replicat 在目标端就找不到更新目标了所以COLMAP里至少要有所有主键列。5.3 数据不一致的校验和修复复制链路跑了一个月后源表和目标表的数据极大概率会有零星不一致来源包括网络闪断后的漏传、Replicat abend 期间的业务写入、或者手工在目标库做过修改。GoldenGate 自带的校验工具是 Verify但多数人用得更多的是在 GGSCI 里查看复制统计来定位异常区间GGSCI STATS REPLICAT rep1, TOTALSOFAR GGSCI STATS EXTRACT ext1, TOTALSOFARSTATS命令输出每个表的 Insert、Update、Delete 次数把源端 Extract 的统计和目标端 Replicat 的统计对比如果某个表的数字对不上基本可以确定该表有数据差异。定位到表以后日常修复做法是在源表上加一个临时抽取进程单独对该表做在线初始化装载GoldenGate 的初始化命令是GGSCI ADD EXTRACT init_emp, SOURCEISTABLE GGSCI ADD EXTTRAIL ./dirdat/ie, EXTRACT init_empSOURCEISTABLE表示这个 Extract 不读 redo log而是直接把源表当前数据全量吐到 trail 文件然后目标端用一个临时的 Replicat 把这批数据应用到目标表。这个操作会在源库执行一次全表扫描对大表有性能影响一般安排在业务低峰期做。初始化和在线复制共享同一套 trail 文件机制但没有事务顺序依赖所以要注意初始化装载完成后必须手工停掉临时进程避免它和正式 Replicat 的写入相互覆盖。5.4 参数改错后的快速回退调优过程中改错参数是高概率事件。比如把BATCHTRANSOPS从小改大后目标端 PGA 内存不足导致 Replicat abend这时候不要慌张。GGSCI 里执行STOP REPLICAT rep1然后重新编辑参数文件把错误的参数注释掉再START REPLICAT rep1。如果错误参数已经导致 checkpint 表里的进度产生了异常可以通过ALTER REPLICAT rep1, CHECKPOINTTABLE old_checkpoint回退到旧的 checkpoint 表或者用ALTER REPLICAT rep1, ETROLLOVER重新指定读取位置。回退操作的最后一步一定是确认info replicat里的 lag 值在正常范围内否则目标端的数据可能已经有大缺口光靠复制进程追平已经不够这时候就得上 5.3 的初始化装载流程重新对齐数据。注意ALTER REPLICAT修改 checkpoint 有风险非必要不做做了之后一旦数据已产生较大偏差最稳的修复路径是重做初始化装载而不是试图手工调整 checkpoint。6. 验证复制链路健康度的四个命令组合链路跑通只是第一步日常运维中更关键的是快速判断链路是否健康。GGSCI 里有一套命令组合可以按顺序执行覆盖了进程状态、延迟、数据量统计和错误报告四个维度熟练使用这套组合可以在一分钟内定位绝大多数问题。先看进程状态和整体延迟GGSCI INFO ALLINFO ALL输出所有 Manager、Extract、Pump、Replicat 进程的当前状态一眼就能看出哪个进程不在RUNNING。这里要看两个位置Status列是RUNNING还是ABEND以及Lag字段是否超过合理阈值。如果 Extract 正常运行但INFO ALL里 Replicat 的 lag 持续上涨而不回落说明目标端应用速度跟不上源端产生速度通常是目标库本身存在 SQL 慢问题或者表缺少索引。再看单个进程的详细检查点GGSCI INFO REPLICAT rep1, DETAILDETAIL选项会输出 Replicat 当前正在处理的 trail 文件序号和内部偏移量结合源端 Extract 输出里的 trail 文件序号可以判断数据在管道中的积压位置。如果两边读到的 trail 文件序号一致但 lag 高说明问题出在目标端应用环节而不是网络传输环节。然后看数据流量统计GGSCI STATS REPLICAT rep1, LATESTLATEST显示最近一次统计窗口内各表的 DML 操作次数用这个数值和应用系统的业务量对比。比如白天业务高峰期每五分钟产生的订单量是一万条但这里显示的 Insert 只有几百说明源端可能有部分表的捕获漏掉了。常见的原因是新添加到复制的表没有加到参数文件里或者表结构变更后 Extract 进入 abend 没有自动恢复。最后打开错误报告GGSCI VIEW REPORT rep1报告文件记录了进程启动以来的所有运行信息和错误信息。日常运维建议每周快速扫一遍报告文件里有没有WARNING级别的重要日志。常见的告警包括表列名映射缺失、字符集转换提示以及长事务警告。这里的核心原则是不要只盯进程状态要习惯性地对比 Extract 和 Replicat 两端的INFO、STATS输出差异GoldenGate 的问题多数体现在不对称而非单点故障上。部署时顺手把INFO ALL和STATS REPLICAT ... LATEST的输出重定向到本地日志文件做成一个五分钟粒度的定时任务就能在业务报告延迟之前提前发现问题。本文还有配套的精品资源点击获取