Oracle GoldenGate 11.2.1.0.3在Windows x64上的实时同步配置与避坑实战

简介面向 Oracle 11g 数据库在 Windows x64 平台上的实时数据同步与迁移场景此版本11.2.1.0.3专为 Windows Server 2003/2008 的 64 位环境设计适合需要低延迟复制、零停机切换的数据库管理员与数据运维人员使用也可作为企业级容灾建设时的参考方案。压缩包共包含 185 个文件整体大小约 34.1MB其中以 52 个 jar 管理组件、38 个 sql 配置脚本、17 个 exe 可执行程序、12 个 dll 运行库为主体并辅以 xml、properties、bat 批处理、C 源码和 Makefile 示例覆盖抽取Extract、数据泵Pump、复制Replicat、管理控制台以及 Trail 文件等核心环节同时附带 Linux、AIX、HP-UX、Solaris 平台文件以作对比参考便于理解跨平台部署的差异。目前已有 1408 人浏览学习。除运行所需的核心二进制与依赖库外包内还提供 exitdemo 演示程序及工程配置示例可帮助读者快速搭建基础环境、理清各进程参数配置思路并为同步故障排查、版本升级演练提供一手参考。1. Oracle_GoldenGate_11.2.1.0.3 for Oracle_11g_windows_x64这串名字背后是数据同步的硬仗如果业务方甩给你一个压缩包文件名是 Oracle_GoldenGate_11.2.1.0.3 for Oracle_11g_windows_x64那多半是让你在两套 Oracle 11g 之间打通实时增量同步。这东西不是数据库本身而是一座把源库 redo 日志翻译成目标库 SQL 的“翻译桥”。我见过不少 DBA 在这件事上翻车包能解压进程能起来但数据就是对不上数最后发现是版本选型或 Windows 服务权限埋了雷。适合谁读被 Oracle 11g 从旧时代绑架、又不准升级的你也适合准备做读写分离、灾备或临时数据抽取的团队。先给个反直觉结论在 Windows x64 上最花时间的不是配同步映射而是让 Manager 进程以服务形态安稳睡在机器里。2. 先拆包再拆逻辑OGG 11.2.1.0.3 的进程模型与硬性选型边界2.1 三进程架构Extract 抓、Pump 传、Replicat 放Manager 当管家Oracle GoldenGate 的核心是一套基于日志捕获的进程体系。在 11.2.1.0.3 这个版本里没有图形界面所有管理都靠 ggsci 命令行但你只要搞懂四个角色后面所有配置都是往这四个文件里塞参数。进程可执行文件运行位置干的活Managermanager.exe源/目标监听端口、拉起进程、做自动重启Extractextract.exe源端读取 redo/archive 日志把变更写到本地 trailData Pumpextract.exe源端读本地 trail压缩加密后发到目标端Replicatreplicat.exe目标端读远程 trail把变更解析成 SQL 并执行有人会问为什么源端要多放一个 Data Pump 进程直接让 Extract 往目标写不行吗行但不安全。Extract 必须紧贴源库日志如果网络抖动或者目标端 Manager 挂了Extract 会被堵住连带源库日志消费受影响。本地 trail 相当于一个缓冲快递盒Data Pump 只负责跨网络传输本地 trail 没写成功Extract 不需要背锅。在 11.2.1.0.3 里这两个进程虽然都叫 extract.exe但参数文件完全不同进程名可以通过INFO ALL区分开。Replicat 在目标端做的是“重放”工作它读到的 trail 是一段紧凑的二进制变更流包含了 SQL 操作类型、行主键、前后镜像和操作时间戳。Replicat 将其拼成目标库可执行的 SQL。这个版本没有内置冲突解决遇到主键冲突、唯一键冲突会直接报错不像是 12c 之后有专门的并行复制和冲突处理所以调参和排错是家常便饭。理解了这条链路你再看后面每一条参数就知道自己正在配置哪一截了。2.2 11.2.1.0.3 的定位与兼容边界这个包名里的 11.2.1.0.3 是 GoldenGate 11g 产品线里的一个修复版本解决了早期 11.2.x 的一些崩溃问题。为什么会到今天还有人在装两个原因一是源库是 Oracle 11.2.0.4新版 GoldenGate 12c/19c 对数据库最低版本要求更高不少生产环境连升级数据库的排期都拿不下来只能挑一个和 11g 匹配的 OGG 老版本兜底二是这套东西经过了多年生产验证参数写法、坑位在大脑中已经成型真出了事敢下手。需要划清的边界是这个包特别注明 for Oracle_11g意思是只保证对 Oracle 数据库的日志解析和复制不是广义的数据套件也别指望用它同步 MySQL、SQL Server。平台限制是 windows_x64所以操作系统必须是 64 位 Windows同时数据库也得是 64 位或者提供了 64 位 OCI 客户端。如果你在一个 x64 的 Windows 上装 32 位 Oracle 11g那么 OGG 64 位进程连接数据库时大概率会在 OCI 层翻车。至于 arm64别想了这个包只认 x64 指令集Windows on ARM 环境不能用。还有一条被很多人忽略的边界授权。OGG 是独立产品不随 Oracle 数据库赠送。如果你在测试环境随便跑没问题生产环境请先确认公司是否买了 GoldenGate 的 license否则后面数据库巡检、版权审计都是雷。老版本虽然没有在线注册强制要求但商业合规不该省。2.3 Windows x64 上的环境前提安装目录、VC 运行库和账号从包名看不出安装向导实际上 Oracle GoldenGate for Windows 从 11g 开始就是“解压即用”没有 setup.exe。但解压不是随便找个盘一放了事有三个硬性前提。第一安装目录别放在带空格或中文的路径下。C:\Program Files 这种经典路径会让不少脚本和服务启动方式挂掉因为引号处理稍有不慎就找不到可执行文件。我一般会单独划一个盘符比如 D:\OGG 或 C:\OGG路径越短越好。第二Windows 下跑 11.2.1.0.3需要 Microsoft Visual C 2013 Redistributable Package (x64)。这不是可选项而是支持库。OGG 的 exe 是 C 编译出来的没有 msvcp120.dll 这类运行库Manager 起都起不来。装完后可以在“程序和功能”里能看到 Microsoft Visual C 2013 Redistributable (x64) 字样。这只是运行库全家桶的基础实际部署时建议 2010、2013、2015-2022 的 x64 都装一遍免得后期还被别的组件卡住。第三Windows 服务账号不能依赖 LocalSystem。OGG 要访问 Oracle 数据库就需要读取 ORACLE_HOME、ORACLE_SID、NLS_LANG 这些环境变量LocalSystem 在服务上下文里不会自动继承系统用户环境变量。建议单独建一个本地账号设置密码永不过期先丢进 Administrators 组里把环境跑通再按最小权限收敛。账号方面还有一个不起眼但作用巨大的权限项作为服务登录。否则后面sc create或INSTALL注册成服务后一启动就报“服务没有所需的权限”。这些细节等出了问题回看会非常痛。3. 在 Windows x64 上把 OGG 跑起来从压缩包到干净的 Manager 服务3.1 解压介质与验明正身拿到Oracle_GoldenGate_11.2.1.0.3_for_Oracle_11g_windows_x64.zip后第一步不是双击而是用 PowerShell 解压到干净目录。下面这段命令我用的是 C:\OGG注意-Force参数用于覆盖解压残留。# 解压到干净目录 Expand-Archive -Path .\Oracle_GoldenGate_11.2.1.0.3_for_Oracle_11g_windows_x64.zip -DestinationPath C:\OGG -Force # 核对文件完整性拿到官方 MD5 后比对 Get-FileHash .\Oracle_GoldenGate_11.2.1.0.3_for_Oracle_11g_windows_x64.zip -Algorithm MD5 | Format-List # 确认关键文件解压完成 Get-ChildItem C:\OGG | Select-Object Name, Length解压后目录里应该有 ggsci.exe、manager.exe、lib 等文件和子目录。Get-FileHash是本地计算的散列不是官方核验但至少能确认下载过程没有把文件“解出”残破版本。OGG 是免安装包没有 Windows 安装向导所以目录结构不对后面所有进程都会在启动阶段直接失败。如果发现ggsci.exe双击没反应多半是运行库缺失可以先去装 VC 2013 x64。3.2 创建用户与系统环境变量接下来把 Oracle 环境变量写进系统层避免服务启动时找不到库。以管理员身份打开 PowerShell用 .NET 方式写 Machine 级环境变量不是为了临时跑通而是为了让 Manager 以 Windows 服务方式启动时也能读到。# 设置系统环境变量机器级别对所有用户生效 [Environment]::SetEnvironmentVariable(ORACLE_HOME, D:\app\product\11.2.0\dbhome_1, Machine) [Environment]::SetEnvironmentVariable(ORACLE_SID, ORCL, Machine) [Environment]::SetEnvironmentVariable(NLS_LANG, AMERICAN_AMERICA.AL32UTF8, Machine) # 把 OGG 主目录和 Oracle 客户端 bin 加入 PATH [Environment]::SetEnvironmentVariable(PATH, $env:PATH ;C:\OGG;D:\app\product\11.2.0\dbhome_1\bin, Machine)NLS_LANG这里先写成 AL32UTF8 是常用默认值生产环境必须跟随源库字符集否则后面中文同步会有乱码。如果源库是 ZHS16GBK这里就写AMERICAN_AMERICA.ZHS16GBK。ORACLE_HOME需要根据实际安装路径修改不能照抄。设置完后打开新的命令行窗口验证echo %ORACLE_HOME%。然后建立一个 Windows 账号用于跑 OGG 服务net user ogg_svc Pssw0rd /add /passwordchg:no /expires:never net localgroup administrators ogg_svc /add先加 Administrators 是为了减少测试阶段的权限干扰瓶颈期过后建议降级为普通用户仅保留“作为服务登录”权限和日志目录写权限。密码策略里一定要关掉“密码永不过期”否则某天午夜服务密码过期Manager 悄悄死给你看。3.3 用 ggsci 初始化子目录并启动 Manager在命令行里进入 C:\OGG执行 ggsci。第一次进来先执行create subdirs让 OGG 把 dirprm、dirrpt、dirdat、dirchk 等标准目录生成好。老版本可能提示子目录已存在没关系。cd C:\OGG ggsci进入 ggsci 后GGSCI (WIN-SERVER) 1 create subdirs GGSCI (WIN-SERVER) 2 edit params mgredit params mgr会打开一个文本编辑器默认文件是dirprm/MGR.prm。一个能扛生产的 Manager 参数至少要包含端口、动态端口、自动重启和 trail 清理策略。PORT 7809 DYNAMICPORTLIST 7810-7819 AUTORESTART EXTRACT *, RETRIES 3, WAITMINUTES 5 PURGEOLDEXTRACTS ./dirdat/*, USEHOURS 72 LAGREPORTHOURS 1PORT 7809是 Manager 的固定监听端口后续 Extract 的RMTHOST都要指向这个端口。DYNAMICPORTLIST 7810-7819是给 Data Pump 和 Replicat 之间数据通道用的端口范围方便防火墙开白名单不需要一段段猜端口。AUTORESTART EXTRACT *是 OGG 的后悔药进程因为瞬时错误退出后自动拉起来重试 3 次间隔 5 分钟。PURGEOLDEXTRACTS指定 trail 文件保留 72 小时避免磁盘被无限写满。LAGREPORTHOURS让 Manager 每小时生成一次滞后报告方便事后审计。保存后在 ggsci 里启动 ManagerGGSCI (WIN-SERVER) 3 start MGR GGSCI (WIN-SERVER) 4 info allinfo all如果能看到 MGR 状态为 RUNNING说明端口和参数没问题。如果状态是 ABENDED 或进程消失立刻执行view report MGR或直接看dirrpt/ggserr.log最常见的报错就是端口被占用后面避坑章再展开。3.4 把 Manager 注册成 Windows 服务命令行启动的 Manager 会跟着终端窗口走一关窗口就退不能用于生产。常见做法是先停止 MGR再注册成服务。在 ggsci 里执行install是老版本自带的服务注册命令GGSCI (WIN-SERVER) 5 stop MGR GGSCI (WIN-SERVER) 6 install如果这个版本的install命令不可用就用 Windows 的 sc 命令绕过去# 管理员权限 PowerShell注册 OGG Manager 服务 sc create OracleGoldenGateMGR binPath C:\OGG\manager.exe start autosc create的语法要求在binPath和start后面要有空格。服务名不能和已有服务冲突。创建后到“服务”面板里把登录身份改成 ogg_svc再启动。如果服务能稳定运行OGG 在 Windows x64 上的地基就稳了。这里插一句安装目录里如果有中文路径sc 注册时经常会在带引号的 binPath 上踩坑所以前面说目录要干净。4. 跑通第一对 Extract/Replicat热点表实时同步的配置步骤4.1 源端数据库准备补充日志与 OGG 账号权限OGG 不碰业务表只碰联机日志和归档日志所以数据库必须处于归档模式。先确认环境SELECT log_mode FROM v$database;如果不是 ARCHIVELOG需要先改归档并重启实例。改模式是标准操作这里不再重复。然后开启最小补充日志再加附加日志ALTER DATABASE ADD SUPPLEMENTAL LOG DATA; ALTER DATABASE FORCE LOGGING;FORCE LOGGING防止某些表被 nologging 方式操作导致日志信息缺失。补充日志不开Extract 能抓到事务但拼不出完整的前镜像目标端会报主键缺失或列值为空。接着创建 OGG 专用账号CREATE USER ogg IDENTIFIED BY ogg_password DEFAULT TABLESPACE users QUOTA UNLIMITED; GRANT CONNECT, RESOURCE TO ogg; GRANT SELECT ANY TRANSACTION TO ogg; GRANT SELECT ANY TABLE TO ogg; GRANT ALTER ANY TABLE TO ogg; GRANT ALTER SESSION TO ogg; -- 测试环境先给 DBA生产环境自行收敛 GRANT DBA TO ogg;这里最关键的是SELECT ANY TRANSACTION它让 Extract 能读取在途事务的 redo 信息。DBA角色确实给大了但很大概率会少一两个隐藏权限导致 Extract 起不来。我的习惯是测试阶段先放开链路跑通后逐条回收然后挂在回归测试。请注意这是 Oracle 数据库里的 OGG 账号和 Windows 服务账号是两回事不要混。4.2 配置 Extract确定捕获方式和本地 trail源端进入 ggsci先登录数据库确认权限可用GGSCI (WIN-SERVER) 1 dblogin userid ogg, password ogg_password GGSCI (WIN-SERVER) 2 add extract ext1, tranlog, begin now GGSCI (WIN-SERVER) 3 add exttrail ./dirdat/lt, extract ext1, megabytes 500dblogin是让 ggsci 验证 OGG 账号和 Oracle 连接如果不做后续add extract可能会报权限错误。add extract里的tranlog表示这是一个日志捕获进程begin now是启动时的数据起点一般首次配置选 now后续再接历史追数。add exttrail创建本地 trail 文件./dirdat/lt表示以lt作为文件名前缀OGG 会生成lt000000、lt000001这类文件。megabytes 500是单个 trail 文件大小超过 500MB 就滚动新文件。接着写 Extract 参数文件EXTRACT ext1 USERID ogg, PASSWORD ogg_password TRANLOGOPTIONS DBLOGREADER SOURCECATALOG ORCL TABLE HR.EMPLOYEES; TABLE HR.DEPARTMENTS;TRANLOGOPTIONS DBLOGREADER让 Extract 直接通过数据库的日志读取接口读取 redo而不是自己啃日志文件效率更稳妥。SOURCECATALOG ORCL是源数据库的 SID 或服务名如果本机配置了 TNS 别名就填 TNS 里那个名字。TABLE HR.EMPLOYEES是白名单方式要同步几张表就写几条。表多了可以用TABLE HR.*;但用通配符时一定要想清楚哪些表要排除否则目标库会收到一堆垃圾表。写完参数后启动 ExtractGGSCI (WIN-SERVER) 4 start ext1 GGSCI (WIN-SERVER) 5 info ext1状态 RUNNING 后用stats ext1能看到当前捕获速率。如果状态 ABENDEDview report ext1是第一个要查的报告文件。4.3 配置 Data Pump跨节点传输的中间通道源端只写本地 trail 是不够的目标端拿不到数据。需要在源端再建一个 Data Pump名字叫 dp1它的输入是本地 trail 文件输出是目标端 trail 文件。在 ggsci 里执行GGSCI (WIN-SERVER) 6 add extract dp1, exttrailsource ./dirdat/lt注意到这里没有tranlog因为 dp1 不是从日志抓取而是从本地 trail 续读。参数文件edit params dp1EXTRACT dp1 RMTHOST 192.168.10.20, MGRPORT 7809, COMPRESS RMTTRAIL ./dirdat/rt TABLE HR.EMPLOYEES; TABLE HR.DEPARTMENTS;RMTHOST 192.168.10.20, MGRPORT 7809告诉 dp1 数据要发给哪台机器目标端 Manager 监听在 7809。COMPRESS开启传输压缩跨机房或公网链路时能省不少带宽和时延。RMTTRAIL ./dirdat/rt表示到目标端后trail 文件名前缀是rt。源端和目标端的 trail 前缀不需要一致但目标端 Replicat 读的就是这个rt所以要记清楚。dp1 的参数里不需要USERID它不连接数据库。启动 pdp1 后如果stats dp1一直显示 0说明本地 trail 还没内容多为 Extract 没抓到日志或同步表没事务。4.4 配置 Replicat目标端把变更写回业务表目标端同样进入 ggsci。先建一个 checkpiont 表用于 Replicat 记录已经应用到什么位置。在目标库创建 OGG 账号的语句和源端类似这里不再重复。先编辑 GLOBALS 文件GGSCI (TARGET) 1 edit params ./GLOBALS写入一行CHECKPOINTTABLE ogg.checkpoint然后登录目标库并创建 checkpoint 表GGSCI (TARGET) 2 dblogin userid ogg, password ogg_password GGSCI (TARGET) 3 add checkpointtable ogg.checkpointcheckpoint 表是 Replicat 管理恢复位点的关键没有它目标端重启后可能重复应用事务导致主键冲突或数据重复。接着添加 ReplicatGGSCI (TARGET) 4 add replicat rep1, exttrail ./dirdat/rtReplicat 参数文件edit params rep1REPLICAT rep1 USERID ogg, PASSWORD ogg_password MAP HR.EMPLOYEES, TARGET HR.EMPLOYEES; MAP HR.DEPARTMENTS, TARGET HR.DEPARTMENTS;MAP是核心映射语句左边是源表的 schema.table右边是目标表的 schema.table。如果两边表名一样可以简写但列名不一样就必须用COLMAP例如MAP HR.EMPLOYEES, TARGET HR.EMPLOYEES, COLMAP (EMP_ID EMPLOYEE_ID, NAME EMP_NAME);列映射不写的时候默认按列名一一对应很多同步错位问题都是这里埋下的。启动 ReplicatGGSCI (TARGET) 5 start rep1 GGSCI (TARGET) 6 info rep1如果 Replicat 一直回放追不上view report rep1里会有详细 SQL 错误如果报 ORA-01403 找不到数据大概率是初始化数据不一致的锅避坑章会讲。4.5 首轮验证用 stats 和 lag 判断同步健康度链路配完用两个命令确认是否真正干活。在源端 ggsci 执行GGSCI (WIN-SERVER) 7 stats ext1 GGSCI (WIN-SERVER) 8 stats dp1在目标端执行GGSCI (TARGET) 7 stats rep1 GGSCI (TARGET) 8 lag rep1stats输出每秒 DML 增量、事务数等如果都是 0检查同步表是否真有变更。lag是最直观的滞后指标显示当前时间与目标端已应用事务时间点的差值。但 lag 小不代表不丢数只能说明链路当前健康。真正验证需要做一次业务写入测试在源端更新一条员工记录再回目标端用相同条件查一次。如果两边的工资字段一致说明最小链路已经跑通。此后再考虑性能调优和异常场景的兜底。5. 常见问题与避坑Windows 上跑 OGG 11.2.1.0.3 最容易翻车的 5 个细节5.1 Manager 进程起来三秒就消失现象在 ggsci 里start MGRinfo all显示 ABENDEDWindows 任务管理器里 manager.exe 闪退。查看dirrpt/ggserr.log有类似ERROR: Unable to bind port。原因7809 端口被其他程序占用或者 Windows 防火墙拦截了 OGG 的入站监听。很多人第一次配置时都喜欢用默认端口于是最容易撞车。还有一种情况是设置了 DYNAMICPORTLIST 的端口区间和别的应用冲突。解决先查端口占用用 Windows 自带工具把占用的进程揪出来。netstat -ano | findstr 7809 tasklist | findstr PID如果是业务程序占用了 7809在 MGR.prm 里改一个不常用端口比如 7901再start MGR。如果是防火墙拦截加一条入站规则放行netsh advfirewall firewall add rule nameOGG MGR 7901 dirin actionallow protocolTCP localport7901改端口这件事越早越好因为后面所有 Extract 参数里的MGRPORT都要跟着改中途再动就像改了一排房子的门牌号容易乱。5.2 Extract 启动报 OCI 连不上数据库现象start ext1后view report ext1里出现ERROR: OCI Error: ORA-12154: TNS:could not resolve the connect identifier specified或者ORA-01017: invalid username/password。原因OGG 是 64 位进程但它加载的 Oracle 客户端可能是 32 位或者 ORACLE_HOME 环境变量没有被 Manager 子进程继承。在 Windows 上如果装了 32 位和 64 位两套客户端PATH 顺序不对就会抓错。解决先确认数据库和客户端都是 x64然后把系统环境变量里的ORACLE_HOME指到 64 位 client 的目录并把%ORACLE_HOME%\bin放在 PATH 里最前面。还有一个能写到 Manager 参数里的办法MGR.prm 支持SETENV把变量传给所有子进程PORT 7901 SETENV (ORACLE_HOME D:\app\product\11.2.0\dbhome_1) SETENV (NLS_LANG AMERICAN_AMERICA.ZHS16GBK)如果服务是由sc create注册的在服务属性里把“登录身份”改为 ogg_svc 时也要确保该账号能在登录会话里读取 ORACLE_HOME。很多老鸟在这里翻车命令行手动启动一切正常一注册成服务就报 OCI 找不到就是环境变量继承的锅。5.3 中文数据同步后变成乱码现象源库是 ZHS16GBK同步到也是 ZHS16GBK 的目标库表和字符集看起来都没问题但同步过去的中文内容变成“¿¿¿”或问号。原因OGG 进程在解析 redo 时默认按客户端字符集 AL32UTF8 解析但源数据在库内存的是 GBK 字节两边换算出错。字符集问题不会让进程崩溃但会在业务文本列上悄悄留坑。解决在 Extract 和 Replicat 参数文件里显式设置NLS_LANG。源端 ext1.prm 里写SETENV (NLS_LANG AMERICAN_AMERICA.ZHS16GBK)目标端 rep1.prm 里也要写上同样的字符集并且和目标库会话字符集一致。如果源库是 AL32UTF8目标库是 AL32UTF8就不用刻意改。乱码这类问题测试数据量小的时候根本发现不了所以我在做 OGG 验证时一定会额外造几条中文、特殊符号、超长字符串的数据跑一轮否则上线后才发现是最难受的。5.4 trail 文件写满磁盘Manager 却不肯自动清理现象dirdat 目录下有几百个 .lt 开头的大文件C 盘直接飘红。删掉一部分后Extract 反而 ABENDED报找不到 trail 文件。原因trail 文件分为已读和未读Manager 只能清理“已被下游消费完”的文件。如果 Data Pump 或目标端 Replicat 长时间断连trail 会持续堆积。这其实是 OGG 的自我保护机制防止下游断了以后数据丢失。手动删除是危险的因为 Extract 需要基于 trail 文件序号来决定续读位置删了就得全链路重建。解决正确做法是在 MGR.prm 里调整PURGEOLDEXTRACTS的保留策略PURGEOLDEXTRACTS ./dirdat/*, USEHOURS 24, MINKEEP 10这句意思是保留最近 24 小时的文件且最少保留 10 个两个条件同时满足才清理。如果磁盘还是撑不住优先排查下游为什么不消费目标端 Manager 是否还活着Replicat 是否处于 running。如果只是暂时断连等追平后 Manager 会自动把过期文件清掉。不要亲手删 trail否则你会收获一个无法启动的 Extract。5.5 Replicat 报 ORA-01403 或 ORA-26990主键找不到现象stats rep1出现大量 ERRORview report rep1显示ORA-01403: no data found。原因Replicat 在目标端应用 UPDATE 时会按主键或唯一约束找到要改的行。如果目标端该行不存在或者主键列在源端被更新导致旧主键在目标表找不到对应行就会出现这个错。还有一种常见背景是初始数据没做基线同步源端有历史 update 事务Replicat 拿来直接执行时目标表还没那条数据。解决先确认源表有主键或唯一索引。没有主键的表要指定键列例如MAP HR.EMPLOYEES, TARGET HR.EMPLOYEES, KEYCOLS (EMP_ID);如果已经出现大量找不到数据的报错临时在 REPLICAT 参数里开HANDLECOLLISIONS它会让 Replicat 跳过冲突行先把流推进下去。但注意这只是一个“追进度”的后悔药数据会丢不能长期开着。正确流程是先做一次初始数据同步比如用 expdp/impdp 把源库表全量搬到目标库再启动 Replicat 追增量。很多新人上来直接配增量忽略了初始数据这一步导致一地报错。6. 更多验证与调优把延迟压到分钟级的小技巧6.1 用 lag 和 stats 建立同步健康度阈值lag rep1看到的值是秒级但它只是瞬时值。我一般会在 Windows 计划任务里放一个 5 分钟执行的检查脚本把lag输出重定向到文本然后用 Findstr 抓超过阈值的行。延迟监控的价值在于发现“悄悄变慢”的过程而不是等用户投诉才去翻报告。# 每 5 分钟执行一次记录延迟 cd C:\OGG ggsci EOF lag rep1 EOF如果延迟超过 10 分钟配合 Windows 任务计划报警。这里要注意ggsci 无法直接把命令从管道传入所以真正脚本里用echo -e lag rep1\nquit | ggsci这种方式。另外每天一次去view report rep1看有没有 ERROR 关键字已经是 DBA 的睡前仪式。6.2 Replicat 参数调优的后发制人链路稳定后再考虑调优。11.2.1.0.3 没有 12c 的集成并行复制所以调优主要靠两个点Replicat 的批处理和大事务切片。在 rep1.prm 里加上REPLICAT rep1 USERID ogg, PASSWORD ogg_password BATCHSQL MAXTRANSOPS 500 MAP HR.EMPLOYEES, TARGET HR.EMPLOYEES;BATCHSQL让 Replicat 把多条 DML 攒成批次应用显著减少事务开销但它对触发器、物化视图有影响如果目标表有触发器先别开。MAXTRANSOPS 500是把超大事务切成 500 条一个的小段提交避免目标端回滚段和 undo 撑爆。这里有一条血泪经验调优参数一次只动一个开完 BATCHSQL 后观察半小时再动MAXTRANSOPS别一次性都开上去否则出问题都不知道是哪条参数干的。结尾还有一件事希望帮到你不管调优还是排错先在测试环境把 Windows 服务和账号的坑全踩一遍再上生产。别问我怎么知道的我曾在生产环境因为服务账号密码过期半夜被业务电话打醒。希望帮到你。本文还有配套的精品资源点击获取