简介针对从Windows平台Oracle数据库向Linux平台Oracle数据库做实时数据同步的典型需求这份PDF文档完整梳理了基于Oracle GoldenGateOGG的安装部署流程。内容从源端开启归档模式、强制日志与附加日志到创建goldengate用户并授权、启用enable_goldengate_replication参数再到目标端的差异化配置与OGG子目录初始化均给出可直接照做的命令示例同时涵盖Manager、Extractor、Replicat三大核心组件的作用与配置思路以及安装后的监控、日志管理和常见故障排查方法。资源为1个PDF文件压缩包总大小约496KB篇幅精炼而步骤完整。目前已有295人学习下载适合需要快速落地跨异构环境OGG同步的DBA、运维人员参考。1. Windows到Linux的OGG同步先搞清它解决什么再决定要不要用一个常见的真实场景客户的生产库跑在 Windows Server 的 Oracle 上因为 Linux 上运维成本低、稳定性好决定迁到 Linux。停机窗口只有两三个小时全量导出导入做完剩下那点增量数据怎么追Oracle GoldenGateOGG就是为这种“准实时同步数据”设计的数据库同步软件。它从源库日志里捕获变更投递给目标端重放Windows 到 Linux 的跨平台同步是它的标准用法之一。适合谁手里有 Windows Oracle 业务库要迁到 Linux、或者要做双环境数据同步的运维和 DBA。它会涉及源端和目标端两套部署、OGG 进程的参数配置、日志排查。本篇文章不讲理论框架直接按“怎么做”走把 Windows 装好源端、Linux 装好目标端、把同步跑起来的关键步骤和踩坑记录都过一遍。2. OGG同步机制拆解捕获、投递、交付三个进程怎么配合2.1 从抽取到复制Extract、Data Pump、Replicat的职责边界OGG 的核心思路是“读日志、传文件、重放”三个进程各管一段。源端 Extract 进程读取 Oracle 的 redo/archive log把变更解析成 OGG 自定义的 trail 文件Data Pump 进程负责把本地 trail 文件通过网络投递到目标端目标端 Replicat 进程接收到远程 trail 文件后在目标库执行 SQL 完成同步。这三个进程之间的数据流就是 OGG 的同步机制主干。我刚接触 OGG 时容易犯一个错以为装好 Extract 和 Replicat 就能同步忽略了 Data Pump。如果只配了 Extracttrail 文件只会写在源端本地目标端根本收不到如果只配了 Replicat它不知道去哪里读远程 trail。实际生产环境九成以上是“Extract Data Pump Replicat”三个进程配合这也是标题里 Windows 和 Linux 两台机器之间最主流的架构。2.2 为什么这个需求要选OGG而不是DG或物化视图同样是数据同步Oracle 自身给的方案里有 Data GuardDG和物化视图但 Windows 到 Linux 这个场景下它们都有痛点。DG 是物理备库要求主备库平台和版本高度一致Windows 到 Linux 跨平台做 DG 有字节序和文件格式问题虽然能强行配但维护成本高而且 DG 同步的是整个数据库没法只同步几张业务表。物化视图则是“拉取”模式源库无感知靠刷新去查源表数据量一大就把源库查询拖垮而且做不到秒级同步对在线业务表做增量刷新还有锁竞争。OGG 走日志解析对源库只增加少量日志读取开销能精确到表级别、行级别跨平台同步就是它的强项。类似的同步工具比如 DataX、Kettle 也能做迁移但他们是批量抽取不是实时日志同步追增量时延迟会越拉越大。2.3 规划拓扑单向同步下的源端和目标端参数清单部署之前先画一张拓扑图明确哪个是源、哪个是目标、同步哪些表、网络端口放不放通。OGG 默认 Manager 进程监听 7809 端口源端与目标端之间的 trail 文件传输也用这个端口如果是走防火墙务必放通 7809。同时源端还要额外给 Extract 进程指定一个本地 trail 文件路径这个路径在 Windows 上和 Linux 上的写法不一样后面配置时会单独说。单向同步是最简拓扑Windows 源库 - Windows OGG 源端 - 网络 - Linux OGG 目标端 - Linux 目标库。如果后续要双向同步就在两边都各配一套 Extract 和 Replicat互为源和目标但初期不建议一上来就做双向先跑通单向确认延迟和丢数据的表现再扩展。目标库的版本最好是 19c 或 12cOGG 软件版本与数据库版本相差一个大版本以内比较稳妥比如 Oracle 19c 配 OGG 19.1。3. Windows源端配置建OGG用户、开补充日志、让Extract跑起来3.1 Windows上安装OGG目录规划与安装步骤OGG 的软件包分 Windows x64 和 Linux x64 两种源端 Windows 就下载 Windows 版本解压后放到一个独立目录比如D:\ogg。注意不要装在 Program Files 这种带空格和权限限制的路径下否则启动服务时容易踩权限坑。解压完成后打开 Windows 命令行进入D:\ogg目录执行 GGSCI 命令初始化子目录。cd D:\ogg ggsci GGSCI create subdirscreate subdirs会自动创建dirprm、dirrpt、dirtrail、dirchk等目录。这些目录有明确分工dirprm存参数文件dirrpt存报告和日志文件dirtrail存本地 trail 文件dirchk存检查点信息。目录建好后GGSCI 提示符下执行exit退出。此时还有一个关键步骤给 OGG 注册成 Windows 服务这样服务器重启后 OGG 能自动拉起。安装服务需要在命令行执行D:\ogg\ogg_inst.exe或者通过install命令常见做法是运行 OGG 自带的服务安装脚本。我一般在 GGSCI 里用info err检查初始化有没有报错然后用 Windows 的“服务”管理把 OGG 服务的启动类型改成“自动”。这一步虽然不起眼但省了以后机器重启后手动拉进程的麻烦。3.2 数据库侧准备归档、补充日志、OGG用户授权OGG 要读日志那源库就得开归档模式生产库一般本来就开着如果没开alter database archivelog之后需要重启数据库这个动作在迁移窗口里要提前安排。补充日志更关键OGG 要从日志里拿到更新前镜像旧值才能准确重放。执行以下 SQLalter database force logging; alter database add supplemental log data; alter system switch logfile;第一句开启强制日志保证所有操作进 redo第二句开启最小补充日志让 OGG 能拿到足够的字段信息第三句切换日志让补充日志立即生效。注意add supplemental log data之后最好在业务低峰执行在线系统上会短暂增加磁盘写量。然后是建 OGG 专用用户并授权。这个用户 Extract 进程要用它连接源库读取日志常见的授权脚本如下create user ogg identified by ogg_password default tablespace users quota unlimited on users; grant connect, resource, create session, alter session to ogg; grant select any dictionary to ogg; grant select any transaction to ogg; grant execute on dbms_logmnr to ogg; grant execute on dbms_logmnr_build to ogg; grant select on sys.v_$database to ogg; grant select on sys.v_$archived_log to ogg; grant select on sys.v_$log to ogg; grant select on sys.v_$log_history to ogg; grant select on sys.v_$transaction to ogg; grant flashback any table to ogg;授权这里我的经验是宁可多给不少给。select any transaction和dbms_logmnr相关权限缺一不可缺少某个视图权限时 Extract 启动后会在日志里报ERROR: OGG-01223这类访问字典失败的错排查起来特别费劲。授权完成后可以用sqlplus ogg/ogg_passwordorcl登录验证一下连接没问题。3.3 用GGSCI配置Manager、Extract和Data Pump参数逐行说明数据库准备好了回到 GGSCI先建全局参数文件再建 Manager 参数文件。Windows 上源端配置遵循以下顺序先edit params ./GLOBALS再edit params mgr再edit params extora。GLOBALS 文件里我一般只放一行指定 trail 文件的加密和元数据标记GGSCI edit params ./GLOBALS在文本编辑器里写入GGSCHEMA oggGGSCHEMA ogg指定 OGG 用户是 ogg后续进程连库都默认用这个账号。接着配置 Manager 参数Manager 负责启停 Extract 和 Data Pump、管理端口和 trail 文件生命周期GGSCI edit params mgrPORT 7809 DYNAMICPORTLIST 7810-7820 USERID ogg, PASSWORD ogg_password PURGEOLDEXTRACTS ./dirtrail/*, USECHECKPOINTS, MINKEEPDAYS 3 AUTOSTART ER *PORT 7809是 OGG 进程间通信的端口动态端口预留 7810 到 7820 是为了传输通道协商时备用USERID指定 Manager 用 ogg 账号连库PURGEOLDEXTRACTS是清理 trail 文件的策略保留 3 天避免磁盘撑满。如果不写PURGEOLDEXTRACTStrail 文件会一直累积我在测试环境就见过 dirtrail 目录涨到几十 GB 的惨状。写完保存回到 GGSCI 启动 ManagerGGSCI start mgr GGSCI info mgrinfo mgr输出里 Manager 状态是 RUNNING端口显示 7809就说明源端管理进程起来了。接着配置 Extract 进程名字叫 extora参数文件里要指定源库连接、日志读取方式、本地 trail 路径和要同步的表GGSCI edit params extoraEXTRACT extora USERID ogg, PASSWORD ogg_password TRANLOGOPTIONS EXCLUDETAG OGG$ GETUPDATEBEFORES DISCARDFILE ./dirrpt/extora.dsc, APPEND, MEGABYTES 100 EXTTRAIL ./dirtrail/lt DYNAMICRESOLUTION TABLE ogg.t_orders;这里每个参数都要理解清楚。EXTRACT extora定义进程名USERID指定连库账号TRANLOGOPTIONS EXCLUDETAG OGG$是跳过 OGG 自身写入的特殊日志标签避免回环捕获GETUPDATEBEFORES让日志里保留更新前的旧值方便 Replicat 端处理EXTTRAIL ./dirtrail/lt是本地 trail 文件路径lt 是文件名前缀同步流量大的情况下会生成 lt00000000、lt00000001 这样的滚动文件。TABLE ogg.t_orders;是同步的对象。写完后在 GGSCI 里添加 Extract 并注册检查点GGSCI add extract extora, tranlog, begin now GGSCI add exttrail ./dirtrail/lt, extract extoraadd extract告诉 OGG 这个进程从当前日志位置开始捕获add exttrail把 trail 文件和 Extract 关联起来。最后还要配置 Data Pump 进程名字取 pumplinux负责把本地 trail 传输到 Linux 目标端GGSCI edit params pumplinuxEXTRACT pumplinux RMTHOST 192.168.10.20, PORT 7809 RMTTRAIL /u01/ogg/dirtrail/rt PASSTHRU TABLE ogg.t_orders;这里RMTHOST指向 Linux 目标机的 IP 和 Manager 端口RMTTRAIL是目标端接收的 trail 路径注意路径写法是 Linux 风格的/u01/ogg/dirtrail/rt。PASSTHRU表示 Data Pump 只做投递、不做解析减少一次日志解析开销。加完进程后执行start extora和start pumplinux用info all查看状态。GGSCI start extora GGSCI start pumplinux GGSCI info allinfo all输出里 extora 和 pumplinux 的状态都变成 RUNNING源端就算跑通了。这时可以在测试表ogg.t_orders插入一条数据然后用stats extora查看捕获统计确认 Extract 的捕获行数在增长源端部分就算完成了。4. Linux目标端配置装好Replicat把TRAIL文件变成INSERT4.1 Linux端安装与目录约定和Windows端差异在哪目标端用 Linux 服务器OGG 的安装包是 Linux x64 版本。下载后用tar解压到/u01/ogg目录建议用ogg用户安装不要直接用 root。安装过程相比 Windows 多一步设置LD_LIBRARY_PATH环境变量指向 Oracle 客户端的 lib 目录否则 OGG 进程启动时找不到 Oracle 的共享库。useradd ogg mkdir -p /u01/ogg chown -R ogg:ogg /u01/ogg su - ogg cd /u01/ogg tar -xzf ogg_linux_x64.tar.gz解压完成后编辑.bash_profile写入环境变量export OGG_HOME/u01/ogg export LD_LIBRARY_PATH$ORACLE_HOME/lib:$OGG_HOME/lib:$LD_LIBRARY_PATH export PATH$OGG_HOME:$PATHLD_LIBRARY_PATH这个变量在 Windows 上完全不需要但在 Linux 上不配置GGSCI 启动时会报libnnz19.so: cannot open shared object file一类的错误。ORACLE_HOME要指向目标端 Oracle 数据库的安装目录这一步极易忽略具体值以目标机实际路径为准。然后同样执行 GGSCI 的初始化ggsci GGSCI create subdirs子目录结构和 Windows 端一致但要注意权限dirrpt、dirchk目录必须对运行 OGG 的用户可写否则 Replicat 启动时写检查点文件会失败。用小写用户运行还有一个好处后续配置定时清理脚本时不用跟 root 的权限纠缠。4.2 目标端建表与Replicat参数MAP语句里藏着大坑OGG 同步的是数据变更表结构要提前在目标库建好否则 Replicat 执行 INSERT 时直接报“表或视图不存在”。如果是从 Windows 端 Oracle 迁移常见做法是用 expdp 把表结构和数据先导出再导入到 Linux 目标库初始数据量不大甚至可以直接用数据库链接建表。手动建表的 DDL 要跟源端保持一致create table ogg.t_orders ( order_id number(12) primary key, customer_name varchar2(100), order_amount number(10,2), create_time date ) tablespace users;注意字段类型要显式声明尤其date和varchar2不要用默认值。一旦目标表结构和源端不一致Replicat 会在地图映射时悄悄把某些列置空而不是报错排查起来最隐蔽。表建好后用 GGSCI 配置 Manager 和 Replicat。Replicat 参数文件是目标端最核心的配置文件一个典型的单表同步参数如下GGSCI edit params repertREPLICAT repert USERID ogg, PASSWORD ogg_password REPERROR DEFAULT, DISCARD HANDLECOLLISIONS DISCARDFILE ./dirrpt/repert.dsc, APPEND, MEGABYTES 100 MAP ogg.t_orders, TARGET ogg.t_orders;这里几个参数要特别留意。USERID是目标库的 ogg 账号同样需要建用户并授权权限比源端简单connect, resource, insert/update/delete权限即可REPERROR DEFAULT, DISCARD表示遇到错误把记录写到丢弃文件、不中断进程HANDLECOLLISIONS是初始化同步阶段常用的参数它自动处理目标库已有数据的重复键冲突初始加载完成后要第一时间去掉否则单独一条重复数据会掩盖真实冲突。MAP语句是映射关系的核心源表和目标表的表名、列结构必须对应。如果两边表名不同比如源端叫t_orders、目标端叫t_order_hisMAP 就要写成MAP ogg.t_orders, TARGET ogg.t_order_his;。如果同步整个 schema 下的所有表可以写通配符MAP ogg.*, TARGET ogg.*;生产环境不建议一上来就全库通配先把核心表映射确定好再逐步扩展。4.3 启动时序与检查点先跑通数据再撤除辅助参数目标端参数写完了但 Replicat 还不能立即启动要先确认远程 trail 文件是否已经在传输。确认方式是在源端 Data Pump 启动的情况下查看目标端/u01/ogg/dirtrail目录里是否出现了rt000000000文件。如果迟迟没有多半是源端RMTHOST的 IP 或端口写错或者防火墙没放通 7809。这个文件是 Replicat 的数据来源等它出现并稳定增长后再执行添加进程。GGSCI add replicat repert, exttrail /u01/ogg/dirtrail/rt GGSCI start repert GGSCI info alladd replicat时指定exttrail路径这个路径必须和源端 Data Pump 参数里RMTTRAIL写的路径一致否则 Replicat 不知道去哪里读文件。启动后用info repert查看状态正常是 RUNNING。接着做一个完整的验证在 Windows 源库插入两条数据更新一条然后到 Linux 目标库查询select * from ogg.t_orders;如果三条变更都正确落在目标表里说明整条链路已经通了。此时再做一件事停掉 Replicat将HANDLECOLLISIONS从参数文件里注释掉然后重启。这一步是为了让同步进入纯净模式后续再有冲突不会被它吞掉。注释方式是在参数文件里那一行前面加--保存后执行GGSCI stop repert GGSCI edit params repert GGSCI start repert启动时序上有一个原则先源端 Extract再 Data Pump最后目标端 Replicat。如果目标端 Replicat 先启动了而远程 trail 还没到它会反复尝试连接但不会报 ABEND状态会显示 RUNNING 但统计为 0有经验的 DBA 看到这种“假运行”会先查 trail 文件是否存在。5. OGG部署避坑几个常见翻车现场与排查手段5.1 现象Extract进程ABEND了报告停在某个redo位置刚配好的 Extract 启动几分钟后状态变成 ABEND这是最常遇到的情况。先去dirrpt目录下看对应的报告文件比如extora.rpt末尾会有OGG-01223或OGG-00446的错误码。我遇到最多的是授权不全select any transaction没给OGG 读不了 redo 里的事务信息。原因还有另一种源库没有开补充日志或者补开之后没有切换日志。补充日志是针对数据字典的全局配置执行了 SQL 但没switch logfile当前日志里还没生成新的字典信息Extract 启动时读不到直接 ABEND。解决方法就是重新确认三件事数据库处于归档模式、supplemental log data是 YES、ogg 用户有全套日志读取权限。全部改完后用alter extract extora, begin now重置起始位置再启动。5.2 现象目标端统计数据都是0Replicat却显示RUNNING这种“假运行”状态特别坑人。Replicat 是 RUNNING但stats repert出来的 INSERT/UPDATE/DELETE 统计全是 0目标表里没有任何新数据。按我的排查经验大概率是远程 trail 文件没到原因在源端 Data Pump。在目标端执行ls -l /u01/ogg/dirtrail/如果目录里是空的或者文件大小不再增长就去源端检查pumplinux.rpt。Data Pump 的常见坑是RMTHOST写成了源端自己的 IP或者端口写成了 7809 之外未放通的端口。还有个隐蔽问题源端PASSTHRU模式下 Data Pump 不做表名解析MANAGER 参数里如果没有PORT或者端口被占用目标端就收不到任何东西。逐个检查修改后重启 Data Pump 即可。此时目标端 trail 文件会开始增长Replicat 统计立刻变化。5.3 现象同步过去了但中文乱码、date字段偏移8小时OGG 的字符集与数据库字符集强相关。Windows 源库如果是 ZHS16GBKLinux 目标库用了 AL32UTF8两边 NLS_LANG 又不一致中文字段同步过去就会显示成乱码。常见做法是在源端 Extract 参数里加SESSIONCHARSET指定源库字符集在目标端 Replicat 参数里用SOURCECHARSET指定日志里的字符编码让 OGG 在两端做转换而不是依赖数据库会话默认。EXTRACT extora SESSIONCHARSET ZHS16GBKdate 字段偏移 8 小时则多半是两端数据库时区设置不同。Windows 上 Oracle 的dbtimezone是00:00Linux 上是08:00OGG 默认按源库时区写入 trail目标端重放时跟着目标库的时区解释时间就对不上。解决方式是在源端 Extract 参数里写TRANLOGOPTIONS convertedate或统一两边数据库时区。我更倾向于统一时区因为 convertedate 参数在部分版本上会导致 date 类型和 timestamp 类型的处理不一致。5.4 现象Windows服务器重启后OGG进程起不来Windows 上最典型的坑是服务账户问题。我用sc config注册 OGG 服务时如果用的账户是普通用户而不是本地系统账户启动服务时没有权限读取 Oracle 的日志文件Manager 起了但 Extract 连库失败。解决方法是把 OGG 服务设置为“本地系统账户”登录或者给服务账户授予Log on as a service权限同时确保该账户对 Oracle 安装目录有读权限。另一个问题是环境变量OGG 服务启动时不一定继承用户级的 PATH 和 ORACLE_HOME 变量导致 GGSCI 里启动 Extract 时找不到 Oracle 客户端库。治本的办法是修改注册表里 OGG 服务的Environment字段把ORACLE_HOME和ORACLE_SID写进去。这个坑在 Windows 和 Linux 两端都有共性凡是进程由系统服务拉起的环境环境变量都要显式配置而不是依赖登录 shell。6. 验证同步与调优一张表、一批数据、一次切换链路通了之后验证要做两层才敢交给业务。第一层用统计命令确认进程状态和数据量。在源端 GGSCI 执行stats extora latest查看最近一次统计的捕获行数在目标端执行stats repert total查看累计重放行数。两者数据量之差就是当前积压量积压为 0 就说明实时性没问题。第二层做业务级验证在源库开一个事务插入 100 条订单数据后提交到目标库查询这一批数据是否完整同时对比源端和目标端count(*)总数select count(*), sum(order_amount) from ogg.t_orders;这里不光对数量还要对金额求和等业务字段防止同数量但数据错位的异常。核对通过后再把源端的插入通道停止等最后一批 trail 文件消费完观察lag值归零这时候才算真正达到切换条件。最后的调优我一般会看三个点。第一是RMTHOST后的传输中使用多个端口压力会更大如果同步量大可以在源端把 Extract 和 Data Pump 分别指定到不同网卡通过网络端口的RMTHOST提高传输并发。第二是TRAILFILE的滚动大小默认每 100MB 滚动一个文件大事务场景下建议调大到 1GB减少文件切换开销写法是在 Extract 参数里加RMTFILE或重启后调整EXTTRAIL大小。第三是REPLICAT的批处理参数BATCHSQL在目标端开启后OGG 会把多条 SQL 合并成批量执行吞吐量能提升明显但对大事务一致性有影响适合初始加载阶段用。我自己的习惯是每交付一个 OGG 同步项目都留一份进程启动顺序清单和info all的基准截图放在部署文档第一页。这样下次服务器重启或进程异常拿着清单就能十分钟内恢复不用临场翻报告。说到底OGG 最怕的不是配置复杂而是日志和状态看得不够细。希望这篇从 Windows 源端到 Linux 目标端的完整操作记录能帮你在做数据库同步时少走几步冤枉路。本文还有配套的精品资源点击获取