简介这是Oracle GoldenGate 11.2.1.0.3针对Oracle 11g与Windows x64平台的组件包面向数据库运维、数据同步及灾备实施人员用来解决实时抽取、传输、复制中的环境部署与依赖配置问题。压缩包共185个文件约34.1MB以jar、exe可执行程序、dll动态链接库为主体同时包含sql脚本、txt配置说明、跨平台Makefile示例以及pdf/doc参考文档覆盖AIX、HPUX、Solaris、Linux等多个系统下的构建特征。包内可看到Extract、Data Pump、Replicat等OGG核心组件相关内容涉及trail文件写入、Java Agent启动脚本、ICU与Xerces依赖库以及多个C语言退出演示程序便于对照源码和脚本理解工作原理与参数调整方法。目前已有1408人学习或下载适合正在搭建Windows 64位OGG环境或准备深入掌握数据同步机制的初中级运维与DBA参考。1. 这不是过时产物Oracle GoldenGate 11.2.1.0.3 for Oracle 11g windows_x64 为何至今仍被生产环境需要当你在 2024 年检索 “Oracle_GoldenGate_11.2.1.0.3 for Oracle_11g_windows_x64” 这串字符时大概率不是来考古而是手里正攥着一台跑着 Oracle 11g 的 Windows Server被某个“必须把数据实时同步到备库或数仓”的需求逼到了墙角。Oracle 11g 已在 2020 年停止免费支持但大量银行、制造和政企系统的核心库短期内根本迁不走而 Oracle GoldenGate 11.2.1.0.3 正是 Oracle 官方针对 Windows x64 Oracle 11g 这套组合在末代推出的稳定桥梁。它解决的是最实际的问题跨服务器实时抽取日志、丢给下游做报表或容灾以及实现几乎零停机迁移。适合谁被客户点名“必须用 OGG” 的 DBA、负责数据同步的老运维以及准备接盘这套老方案的技术经理。接下来我按一线部署顺序把从装环境到参数调优再到撞墙排错的路径完整拆一遍。2. 在 Windows x64 上装好并跑通 OGG 11.2.1.0.3目录规划与最小配置2.1 三个必做的环境预检路径、运行库与 Oracle 补丁先说结论在 Windows 上装 GoldenGate 11.2.1.0.3第一道坎往往不是 Oracle 本身而是操作系统层面的依赖。OGG 的进程是标准的 Win32 程序但它内部调用了大量早年间 VC 运行库的 API。我遇到最典型的“翻车”现场是双击安装包一路 Next装完后在 CMD 里敲ggsci系统直接弹出 “应用程序无法启动” 或 “找不到 msvcp100.dll / msvcp120.dll”这根本不是 OGG 的问题是机器上没有对应的 Microsoft Visual C 2010 / 2013 运行库。切记64 位的 OGG 需要 64 位版本的 VC 运行库。另一个乳名坑是安装路径。OGG 11.2 对路径中的空格极度敏感装到C:\Program Files\Oracle\OGG下后续CREATE SUBDIRS生成的进程配置文件在解析时会出现各种无厘头的ERROR: Missing filename提示。老规矩直接放盘符根目录比如D:\Oracle\OGG这个习惯能帮你省掉后面 80% 的“玄学”问题。最后是 Oracle 11g 本身的补丁状态如果源端是 11.2.0.1 或 11.2.0.2OGG 11.2.1.0.3 在抽取日志时可能碰上LOGINTIMEOUT超时或抓不到归档日志。我一般要求生产环境至少打上 11.2.0.4 的补丁基线否则后续同步时的稳定性很难保证。:: 检查系统是否已安装 VC 运行库缺哪个补哪个 dir C:\Windows\System32\msvcp100.dll dir C:\Windows\System32\msvcp120.dll :: 设置系统级环境变量在“此电脑 - 属性 - 高级系统设置”里配置后重开 CMD setx ORACLE_HOME C:\Oracle\product\11.2.0\dbhome_1 setx OGG_HOME D:\Oracle\OGG setx NLS_LANG AMERICAN_AMERICA.ZHS16GBK setx ORACLE_SID ORCL逻辑说明ORACLE_HOME并非 OGG 启动的必选项但如果不设OGG 在解析tnsnames.ora连接串时需要你写完整绝对路径否则连库时报OCI 连接失败的频率会明显增高。NLS_LANG是重中之重它决定 OGG 进程读 Oracle redo 时以什么字符集编码解析数据。这里设成ZHS16GBK是因为源库常见编码就是 GBK如果你源库是 AL32UTF8这里就要改为AMERICAN_AMERICA.AL32UTF8。设错的话后面同步到目标库的中文全是问号而且这种乱码很难从日志里直接发现。2.2 解压安装与初始化 GGSCI从 GLOBALS 到 MGR 进程拿到Oracle_GoldenGate_11.2.1.0.3 for Oracle_11g_windows_x64这个压缩包后先解压到D:\Oracle\OGG目录。里面通常是一个安装引导程序运行它完成基础文件部署。安装完成后进入安装目录打开命令行工具启动ggsci。这是 OGG 的控制台所有进程管理都在这里完成。启动后会进入GGSCI提示符接下来必须依次执行初始化命令。# 进入 OGG 安装目录并启动命令行 cd D:\Oracle\OGG ggsci # 在 GGSCI 提示符下创建默认工作子目录 GGSCI CREATE SUBDIRS # 编辑全局配置文件 GLOBALS GGSCI EDIT PARAMS ./GLOBALSCREATE SUBDIRS会生成dirdef、dirprm、dirrpt、dirdat等默认目录。这些目录名不要改动尤其是dirdat它是存放 trail 文件的地方改错位置会导致 MGR 无法定位进程端口文件和队列文件。EDIT PARAMS ./GLOBALS打开的是一个全局配置文件通常在这个文件里指定GGSCHEMA ogg意思是为 OGG 在源端和目标端数据库里定义一个管理用户 schema。如果你不写这一行OGG 在后续做表映射时默认会使用SYS或当前用户权限边界会乱掉。# 继续在 ggsci 中配置 Manager 进程参数 GGSCI EDIT PARAMS MGR在打开的编辑器中输入以下内容并保存PORT 7809 DYNAMICPORTLIST 7820-7840 AUTOSTART ER * AUTORESTART ER *, RETRIES 3, WAITMINUTES 5参数说明PORT 7809是 MGR 进程的固定监听端口源端和目标端都要对彼此开放这个端口。DYNAMICPORTLIST是当主端口繁忙时MGR 自动分配给 Extract 或 Replicat 进程传输数据的额外端口区间。我见过不少人只放行了 7809结果 Extract 起不来报TCP/IP error因为数据通道用的映射端口被防火墙拦了。AUTOSTART和AUTORESTART是让 MGR 在启动时自动拉起所有配置好的 Extract/Replicat并且在进程意外 ABEND 时自动重试——在无人值守的 Windows 服务器上这两个参数几乎是必备的。保存参数后在GGSCI中执行GGSCI START MGR GGSCI INFO MGRINFO MGR输出中应显示Status: RUNNING。如果状态是ABEND多半是端口被占用或GLOBALS文件写得不对。检查端口占用用 Windows 自带命令netstat -ano | findstr 7809。这一步成功说明 OGG 的骨架已经搭好。2.3 源端数据库准备开归档、补日志与授权OGG 的核心是读 redo/archivelog 获取变更。如果 Oracle 11g 没开归档模式那 Extract 附着在日志上毫无意义很快就会以OGG-01224错误退出。因此源端数据库必须处于归档模式。同时还需要开启补充日志因为默认的 redo 日志只记录被修改的列值如果不开启补充日志OGG 无法拼出完整的列信息目标端会出现主键冲突或无效数据。这一步必须用 SysDBA 身份完成。-- 用 SQL*Plus 以 SYSDBA 登录源库 ALTER SYSTEM SET ENABLE_GOLDENGATE_REPLICATIONTRUE SCOPEBOTH; -- 开启数据库级补充日志关键 ALTER DATABASE ADD SUPPLEMENTAL LOG DATA; ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS; ALTER SYSTEM SWITCH LOGFILE; -- 确认归档模式 ARCHIVE LOG LIST;逻辑说明ENABLE_GOLDENGATE_REPLICATION参数在 Oracle 11g 中默认为FALSE不打开它即使之后注册了抽取进程也会报ERROR: Failed to enable GoldenGate replication。ALTER DATABASE ADD SUPPLEMENTAL LOG DATA让 redo 记录表行的主键信息和控制文件变更(PRIMARY KEY) COLUMNS确保 DML 操作后能定位到具体行。做过这两个操作后切换一次日志文件让它立即生效。这一步是许多新手的忽略点跳过它后面无论怎么调整参数都会在启动瞬时报错。接下来创建 OGG 管理账户并授权。我这里直接给最小但完整的权限集合避免用DBA角色包治百病因为生产环境审计不会放过这种大权限账号。-- 创建 OGG 专用表空间和用户 CREATE TABLESPACE OGG_TBS DATAFILE C:\ORADATA\OGG01.DBF SIZE 100M AUTOEXTEND ON; CREATE USER ogg IDENTIFIED BY ogg DEFAULT TABLESPACE OGG_TBS QUOTA UNLIMITED ON OGG_TBS; GRANT CONNECT, RESOURCE TO ogg; GRANT ALTER ANY TABLE, ALTER ANY CACHE TO ogg; GRANT SELECT ANY TABLE, INSERT ANY TABLE, UPDATE ANY TABLE, DELETE ANY TABLE TO ogg; -- 授予 GoldenGate 专用管理权限 EXEC DBMS_GOLDENGATE_AUTH.GRANT_ADMIN_PRIVILEGE(OGG, CAPTURE, TRUE);参数说明当你在 Oracle 11g 上执行DBMS_GOLDENGATE_AUTH.GRANT_ADMIN_PRIVILEGE时如果报ORA-06550: package DBMS_GOLDENGATE_AUTH does not exist说明数据库中还没安装 GoldenGate 配套的 PL/SQL 包。常规做法是去$ORACLE_HOME\rdbms\admin目录下执行dbms_goldgate_auth.plb脚本用 SQL*Plus 以 SYSDBA 身份运行它再重新授权。这一步很多人被卡住以为是版本问题其实是脚本没跑。以上配置完成后源端数据库就可以被 OGG 正常读写了。3. 配置 Extract 和 Replicat参数文件、队列映射与启动顺序的实战编排3.1 源端 Extract 参数EXTTRAIL 与 TABLE 映射的书写细节源端进程名通常叫EORA_1意思是 Extract Oracle。它的职责是连接源库、读取 redo 日志、把变更按顺序写成 trail 文件。trail 文件是 OGG 的中间交换格式目标端通过读 trail 文件来重放数据。理解这一点就能理解为什么参数里必须有EXTTRAIL。在 ggsci 中编辑抽取进程参数GGSCI EDIT PARAMS EORA_1在编辑器里写入EXTRACT EORA_1 USERID ogg, PASSWORD ogg GETUPDATEBEFORES EXTTRAIL D:\Oracle\OGG\dirdat\lt TABLE SCOTT.EMP; TABLE SCOTT.DEPT;参数说明USERID指定连接源库的账号这里要用我们刚才创建且授权过的 OGG 用户。GETUPDATEBEFORES必须加它让 trail 文件同时记录更新前的旧值和更新后的新值。如果不加目标端应用时只拿到新值一旦目标表需要根据旧值做唯一性判断例如主键变更Replicat 会直接因为找不到对应行而 ABEND这是血泪教训中排名前三的隐形坑。EXTTRAIL后面跟的是队列文件路径lt是 Extract 队列文件的命名前缀文件名长度有讲究OGG 11.2 要求 trailing 前缀不超过 8 个字符所以我们用lt而不是longtrail01。保存参数后回到 ggsci 命令行注册抽取进程并启动GGSCI ADD EXTRACT EORA_1, TRANLOG, BEGIN NOW GGSCI ADD EXTTRAIL D:\Oracle\OGG\dirdat\lt, EXTRACT EORA_1 GGSCI START EORA_1 GGSCI INFO EXTRACT EORA_1ADD EXTRACT EORA_1, TRANLOG, BEGIN NOW的TRANLOG表示从日志流中捕获BEGIN NOW表示从当前日志位置开始抓取。ADD EXTTRAIL ... EXTRACT EORA_1是把刚才参数里定义的队列路径与进程绑定这两条命令的顺序不能颠倒必须先有 Extract 实体才能挂载队列。启动后INFO EXTRACT EORA_1输出应为Status: RUNNING且Current Read Position有具体日志序列号。如果输出ABEND用VIEW REPORT EORA_1查看报告文件多数情况是密码大小写或 Oracle tnsname 解析问题。3.2 目标端 Replicat 参数从 CHECKPOINT 到 MAP 映射的书写逻辑目标端进程名通常叫RORA_1。它的作用是把 trail 文件里的数据变更重放到目标库。目标库同样需要建好 OGG 用户并授权。目标端 Replicat 的参数和 Extract 有本质区别它不需要EXTTRAIL因为它的输入源是源端传来的 trail 文件它只需要告诉进程“我要读哪个源队列映射到哪张表”。GGSCI EDIT PARAMS RORA_1在编辑器里写入REPLICAT RORA_1 USERID ogg, PASSWORD ogg ASSUMETARGETDEFS REPERROR DEFAULT, ABEND DISCARDFILE D:\Oracle\OGG\dirrpt\rrora.dsc, APPEND, MEGABYTES 100 MAP SCOTT.EMP, TARGET SCOTT.EMP; MAP SCOTT.DEPT, TARGET SCOTT.DEPT;参数说明ASSUMETARGETDEFS表示假设目标表结构与源端完全一致省去了生成元数据文件的步骤。这在表结构一致、且你严格控制 DDL 变更的简单场景下很好用。但如果两边的表结构有微小差异比如目标表多了一个空列OGG 会报OGG-01163 Column mismatch。所以在做异构同步或者跨版本同步时我会用DEFGEN工具生成defs文件并在参数里用SOURCEDEFS指定这样更稳妥。REPERROR DEFAULT, ABEND是复制错误处理策略默认遇到错误就挂起进程这能防止数据静默丢失。DISCARDFILE用于记录那些无法被正常应用的记录设置它可以让排错时有的放矢。生成并启动 ReplicatGGSCI ADD REPLICAT RORA_1, CHECKPOINT GGSCI START RORA_1 GGSCI INFO REPLICAT RORA_1ADD REPLICAT RORA_1, CHECKPOINT表示这是一个持续运行的复制进程而不是一次性的特殊运行。度在哪CHECKPOINT会让 OGG 在重做日志中记录已提交的事务点位这样即使进程重启它也能从断点继续而不是从队列头重复同步一遍。如果只是为了做一次性初始化用SPECIALRUN但生产同步必须用CHECKPOINT。启动后观察INFO REPLICAT RORA_1的输出状态变成RUNNING才算激活。3.3 带初始数据加载的同步用 Data Pump 灌基础数据再用 OGG 追平增量在一个空目标库上直接启动 Replicat 是不行的因为 Replicat 只会同步它开始在 trail 文件中看到的变更而之前的历史数据不会自己生成。生产上最常见的做法是先做一次基础数据拷贝拷贝期间产生的增量由 OGG 从BEGIN NOW时刻开始追。常见流程是在启动 Extract 之前先基于目录或表空间导出源库数据再导入目标库然后启动 Extract。-- 源端使用 Oracle Data Pump 导出用户数据在目标端也用同样方式导入 expdp ogg/oggORCL schemasSCOTT directoryDATA_PUMP_DIR dumpfilescott_initial.dmp logfileexp_scott.log# 目标端导入 impdp ogg/oggTARGET schemasSCOTT directoryDATA_PUMP_DIR dumpfilescott_initial.dmp logfileimp_scott.log导入完成后数据到达T0时刻。这时启动源端 ExtractBEGIN NOW从当前时间开始抓增量并启动目标端 Replicat。这里有一个关键点如果初始拷贝期间源库有 DML 操作那么从拷贝开始到 Extract 启动这段时间的数据会丢失。解决办法是在expdp导出的瞬间记录源库的 SCN然后 Extract 的ADD EXTRACT ... BEGIN NOW应改为使用带有 SCN 的起始点。OGG 支持ADD EXTRACT EORA_1, TRANLOG, BEGIN NOW若要精确到 SCN可以先把 Expdp 导出的 SCN 记录好再用ADD EXTRACT ... BEGIN SCN 1234567。这里涉及高阶技巧新手可以先采用“业务短停如夜里2点做完初始导入再开启 OGG 追增量”这种保守且稳妥的方案。4. Windows11gOGG 11.2 避坑实录四个高发故障与排查思路4.1 进程起不来OGG-01094 对象不存在与大小写敏感误报现象执行START EORA_1后进程一直RUNNING变ABEND查看报告VIEW REPORT EORA_1报错OGG-01094 Fatal error in Oracle OCI interface提示对象不存在。原因Windows 下 Oracle 11g 的账号默认是大小写敏感的。你在 Oracle 里创建的用户是ogg但参数文件里USERID ogg如果数据库参数sec_case_sensitive_logon被设为安全模式OGG 去连接时可能因为用户名大小写解析失败。另一个原因是表清单TABLE SCOTT.EMP;写的 schema 名大小写不对。Windows 环境里 SCOTT 的表如果实际是大写存储但你在 tnsnames 或会话中用了小写Oracle 会当作另一个对象。解决统一使用大写或与建表一致的大小写建议直接全大写。确认USERID和PASSWORD的大小写在 SQL*Plus 用alter user ogg identified by ogg;重置一次密码。然后在参数中将TABLE对象全部写成大写例如TABLE SCOTT.EMP;。另外推荐在GLOBALS文件中显式指定SCHEMATRANDATA这能帮助 OGG 更好地匹配 schema 元数据。4.2 字符集乱码与换行符NLS_LANG 未生效现象同步到目标库后中文全是问号或乱码数字和字母正常。有些字段末尾还多出\r\n换行符。原因Windows 的 OGG 服务或手工命令行启动进程时读取的环境变量NLS_LANG与你当前 CMD 窗口不一致。如果你在 CMD 里敲start EORA_1CMD 继承了当前用户的NLS_LANG但如果你把 OGG 注册成 Windows 服务ggsci install addservice服务进程不会读取你手动设的用户环境变量导致用 UTF8 或 US7ASCII 解析了 ZHS16GBK 的 redo 数据。解决在 Windows 服务管理器中找到对应的Oracle GoldenGate Manager服务右键属性将环境变量NLS_LANGAMERICAN_AMERICA.ZHS16GBK填入服务运行环境。如果进程是由ggsci直接启动确认控制系统环境变量后完全关闭并重新打开 CMD老窗口里的变量不会刷新。这是典型的“界面都改了进程还读旧值”的踩坑点。4.3 数据通道被隐形封杀Oracle 端口与 Windows 防火墙的深层关系现象Extract 与 Replicat 都在 RUNNING但 Lag 值持续增长查看STATS EXTRACT发现无任何输出交易或者报出OGG-01025 TCP/IP error: Connection refused。原因MGR 的PORT 7809开了防火墙但 OGG 在传输数据时抽取和复制进程之间会动态协商端口来自DYNAMICPORTLIST 7820-7840的数据连接如果没放行数据只能被阻塞进程表面存活实际上处于半死状态。解决在 Windows 防火墙的高级设置中添加入站规则放行 TCP 端口7809, 7820-7840且作用域限定在源/目标主机的内网 IP 段不要全放公网。另外检查是否有第三方安全软件如 360、McAfee中间件拦截了进程间 socket 通信。在 Windows 上我见多了“防火墙关掉了还不行最后发现是杀毒软件实时监控拦截了 OGG 动态文件读写”可以直接将D:\Oracle\OGG目录加入杀毒软件白名单。4.4 Disk 暴涨与队列文件生命周期Trail 文件清理不及时导致宕机现象C盘空间莫名其妙被占满dirrpt报告显示大量Ext trail文件大小以 GB 增长MGR 或 Extract 进程在后续写入队列时ABEND日志报File System Full。原因OGG 的 trail 文件是按事务量滚动的默认情况下不会自动清理老队列。如果不设置保留策略它会一直写到磁盘爆掉。目标端的 Replicat 在应用完队列后理论上可以删除文件但 Windows 文件锁和目录权限错误常常导致进程无法删除。解决在ggsci中执行清理命令让 MGR 定期清理过期队列文件。我在生产环境的习惯是保留 3 天数据确保不会因为下游目标库临时宕机导致队列被过早清理GGSCI PURGEOLDEXTRACTS D:\Oracle\OGG\dirdat\lt*, MINKEEPDAYS 3, USECHECKPOINTS参数解析PURGEOLDEXTRACTS按文件前缀匹配清理lt*匹配我们定义的队列前缀。MINKEEPDAYS 3表示至少留 3 天前的文件USECHECKPOINTS是开关它告诉 OGG 只有在 Replicat 检查点确实已越过该文件时才执行物理删除避免删掉还没应用完的数据这是防止“后悔药”失效、导致重放丢失的关键开关。5. 验证同步一致性与性能追赶用 STATS 与 LAG 量化健康度同步进程启动后不能只看进程状态是RUNNING就当甩手掌柜。我最常用来验证的手段是先用INFO ALL看整体进程树再用LAG命令查看数据落后程度。LAG EXTRACT EORA_1会显示当前日志读位点与数据库最新落地日志之间的时间差正常情况应小于几秒。如果出现分钟级甚至小时级 Lag先查源库是否有未提交大事务或者目标库是否因为索引重建导致应用缓慢。针对生产验证我会额外开启RUNTIMESTATS。这个参数能让你在STATS EXTRACT EORA_1时看到每秒处理行数、语句类型占比而不只是累计总数。它还能量化抽ingest和复制阶段的性能瓶颈。同样地在 Replicat 端加上REPORTCOUNT EVERY 10000, RATE它会每处理 1 万条记录时在日志里打印一次当前速率。这对判断到底是网络瓶颈、磁盘 I/O 瓶颈还是目标库 SQL 执行瓶颈极具参考价值。我曾在一台 Windows 机器上发现Lag 突然跳到 10 分钟RUNTIMESTATS显示写入目标库的平均响应时间从 20ms 涨到 900ms最终定位到目标表字段没有主键导致复制产生全表扫描锁。表格展示了我在生产环境最常用的几个健康度检查命令命令作用期望结果INFO ALL查看所有 Extract/Replicat 状态全部 RUNNINGINFO EXTRACT EORA_1查看源端进程位置Last Read Position 持续前移LAG REPLICAT RORA_1查看目标端复制延迟输出小于 10 秒STATS REPLICAT RORA_1, TOTAL查看累计处理行数数据量与源库差异为 0在 11g 这种老版本组合上进程重启和异常恢复是绕不开的话题。我始终保留一个生产习惯在每次维护窗口结束后手动执行一次ALTER EXTRACT EORA_1, CHECKPOINT和ALTER REPLICAT RORA_1, CHECKPOINT这个操作会重置进程内部的一致性位点确保崩溃恢复时不会重复加载。同时务必确认MGR进程在 Windows 重启后能自动拉起通过GGSCI INSTALL ADDSERVICE注册成后台服务并设置服务开机自启。这能避免服务器半夜重启后你被电话惊醒去手动敲START ER *的尴尬。毕竟解决同步问题靠的是纪律和可复现的步骤而不是运气。希望帮到你。本文还有配套的精品资源点击获取