Oracle OGG跨平台实时同步:Windows到Linux部署与避坑指南
发布时间:2026/10/2 6:56:28来源:尧图网络
简介一份面向Oracle DBA及数据同步实施人员的OGG部署实战文档聚焦如何利用Oracle GoldenGate 12.2.0.2将Windows上的Oracle数据库实时同步至Linux环境。资源定位明确适合正在规划跨平台数据迁移、灾备同步或需要快速掌握OGG核心配置的运维和数据库工程师。文档完整覆盖源库与目标库的前置准备详细说明开启归档模式、强制日志、附加日志创建goldengate用户并授权以及enable_goldengate_replication参数设置同时给出目标库额外授权、checkpoint表与全局参数文件配置等关键细节。接着讲解OGG子目录初始化、Manager端口与参数、Extractor、Replicat等核心组件配置并补充监控日志、常见故障排查等维护要点。具体SQL、GGSCI命令和安装步骤均以清晰的命令片段呈现方便读者直接对照操作。文档共1个PDF文件压缩包大小496KB内容紧凑、步骤完整。资源发布以来已有295人学习可用于OGG快速落地、跨平台同步实施及后续问题定位。1. Oracle OGG安装部署细说Windows同步到Linux接到过这样一个需求客户有一套老业务库跑在Windows Server上Oracle 11g硬件要退役新机器是Linux业务不能长时间停。数据库同步软件翻了一圈最后还是用Oracle GoldenGateOGG做实时同步——源端Windows抓日志目标端Linux投递停机窗口压到分钟级。这篇文章就是把这个过程完整拆开OGG的同步机制怎么理解、Windows源端怎么装、Linux目标端怎么配置、初始化数据怎么做以及我实际部署中踩过的一堆坑。适合正在做Oracle跨平台迁移、灾备、读写分离或数据中心汇聚的DBA和运维工程师。你要的是一套能照抄的落地路径不是概念科普。2. 同步机制与部署选型先搞懂Capture、Transport和Replicat再动手OGG不是触发器、不是物化视图、更不是定期导数据它从Oracle的redo/archive log里解析变化再以自定义的trail文件格式投递到目标库整个过程对源库业务几乎无侵入。很多人第一次部署时一头扎进命令里结果进程起来又abend反复摸不着头脑。我建议先花半小时把链路模型理清楚后面配参数全是顺水推舟的事。2.1 OGG同步链路三个进程加一个中转文件OGG一条完整的同步链路在标准配置下由三部分构成源端主抽取进程Extract、源端数据泵进程Data Pump、目标端复制进程Replicat中间靠trail文件接力。主抽取进程直接连源库读取redo/archive log把变化解析成OGG内部格式写到源端的本地trail文件。数据泵进程读本地trail通过TCP/IP传给目标端Manager进程拉起的Collector接收器落地成目标端的远程trail文件。Replicat进程读远程trail把事务在目标库回放。这套设计的核心价值在于两级trail形成了天然的缓冲和解耦源端主抽取不受网络抖动影响数据泵失败不会污染主抽取目标端Replicat进度落后也不会反压源端。生产环境我从不省掉数据泵这一跳哪怕源和目标都是同一台机器也按标准链路搭。原因很简单——一旦源端主抽取直接跨公网传网络闪断会直接拖垮日志抓取进度恢复起来极其痛苦。每个进程都有独立的checkpoint机制。Extract的checkpoint记录读日志的位置Replicat的checkpoint记录已提交到目标库的事务位置。正因为有checkpoint进程重启后能精确续传不会丢事务也不会重复应用。这也是OGG敢叫“实时同步”的底气。2.2 为什么Windows源到Linux目标要单独规划字符集和时区同构平台Linux到Linux的OGG部署相对省心一旦跨Windows和Linux几个隐藏差异就会冒出来。先看字符集。源库字符集可能是ZHS16GBK目标库可能是AL32UTF8。OGG传输trail文件时按字节搬运不做转码到了目标端由Replicat负责按目标库字符集解释。如果两边NLS_LANG设置不一致中文同步过去就变成问号或乱码。部署前必须确认三处字符集对齐源端数据库字符集、源端OGG进程的NLS_LANG、目标端Replicat进程的NLS_LANG。我在后面第4章会给出具体配置方法。再看时区。Oracle的DATE类型不带时区OGG解析日志时按源端会话时区写入trail。如果源端Windows是东八区目标端Linux也设了东八区问题不大但很多Linux服务器习惯设成UTC结果就是目标库数据比源库慢8小时。这不是同步丢数据是时区解释不一致。解决方案是源端和目标端的数据库、操作系统、OGG进程统一用同一个时区基准并在Replicat参数里显式声明时区相关列的处理方式。还有两个容易被忽略的点路径风格完全不同GGSCI里所有目录参数注意别把Windows的C:\OGG\...习惯带到目标端trail文件是二进制跨平台格式OGG从12c开始统一了跨平台trail格式低版本11g之前Windows和Linux的trail文件不能互读所以版本选型尤为重要。2.3 版本选型与部署形态先对参数再动手OGG版本必须跟Oracle数据库版本匹配。Oracle 11g配OGG 11.x/12.1Oracle 12c配OGG 12.2/18cOracle 19c配OGG 19.x。跨大版本用新OGG连老库一般可以反过来老OGG连新库基本不行。我的原则是源库和目标库都看选两者都支持的最高OGG版本并且同一链路两端用完全相同的OGG版本号避免小版本行为差异。部署形态上源端Windows安装包和目标端Linux安装包是分开的下载时要分别选对应操作系统版本。Windows端建议安装在纯英文路径下比如C:\OGG不要带空格和中文Linux端一般装在oracle用户的/u01/ogg之类的位置属主设为oracle:oinstall权限750就行。网络规划方面OGG默认Manager监听端口我用7809再加一组动态端口给Collector接收数据。源端防火墙要放行目标端到源端这些端口的TCP入站规则很多部署失败根本不是配置问题是防火墙把Collector的握手包丢了。整个过程可以先在两端各启动Manager用telnet验证端口连通再进行后续配置。3. Windows源端部署MGR、抽取进程与trail文件的三个核心配置源端是所有同步数据的发源地一旦这边配置错目标端再折腾也是白费。我的落地顺序是先做数据库层准备再装OGG软件然后依次配置Manager、主抽取进程和数据泵进程。每一步验证通过再做下一步绝不跳步。3.1 数据库准备补充日志和归档模式检查OGG抓取日志的前提是源库开启了归档模式ARCHIVELOG并且开了补充日志Supplemental Logging。很多同步数据丢失的案例根源都在这步没做扎实。-- 检查源库关键日志属性 SELECT log_mode, supplemental_log_data_min, force_logging FROM v$database; -- 开启最小补充日志如果未开启 ALTER DATABASE ADD SUPPLEMENTAL LOG DATA; -- 开启强制日志避免NOLOGGING操作导致日志缺失 ALTER DATABASE FORCE LOGGING;逻辑说明log_mode必须是ARCHIVELOGsupplemental_log_data_min为YES才表示OGG能识别主键列的变化force_logging为YES能确保直接路径加载等NOLOGGING操作也写入日志。第1条查询语句用来确认现状第2、3条是开启命令执行后最好再查一次确认。参数说明只开最小补充日志时OGG能同步DML如果要同步主键更新或被更新列的旧值还要加上ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS。显卡的update操作默认不会带出旧值后面Replicat映射会拿不到更新前内容这是一个高频坑建议部署时直接加上。另外开启补充日志会让redo量增加约5%~15%对写密集系统要提前评估磁盘空间。3.2 安装OGG源端并配置Manager进程OGG的Windows版安装包解压或安装完成后目录结构是固定的。关键子目录有dirprm参数文件、dirrpt报告与异常日志、dirtrailtrail文件、dirdef定义文件、dirchkcheckpoint文件。这些目录在第一次用GGSCI命令启动时会自动创建不用手工建。环境变量方面确保系统PATH里能找到OGG安装目录并设置NLS_LANG与源库字符集一致。比如源库是ZHS16GBK就设NLS_LANGSIMPLIFIED CHINESE_CHINA.ZHS16GBK。这一步漏了后续所有中文数据同步出去就会变成乱码。打开命令行进入OGG目录启动GGSCIggsci GGSCI CREATE SUBDIRSCREATE SUBDIRS会自动创建OGG标准目录结构。然后编辑Manager参数GGSCI EDIT PARAMS MGR写入以下内容PORT 7809 DYNAMICPORT 7810-7820 AUTOSTART EXTRACT * AUTORESTART EXTRACT *, RETRIES 3, WAITMINUTES 5 PURGEOLDEXTRACTS ./dirtrail/*, USECHECKPOINTS, MINKEEPHOURS 24逻辑说明PORT 7809是Manager监听端口DYNAMICPORT 7810-7820是Data Pump向目标端传输时使用的动态端口范围AUTOSTART和AUTORESTART让抽取进程随Manager自动拉起并在异常退出后自动重启PURGEOLDEXTRACTS防止trail文件无限堆积。参数配置完启动ManagerGGSCI START MGR GGSCI INFO MGR3.3 抽取进程与数据泵的参数落地主抽取进程负责抓日志数据泵负责传数据。生产环境我把它们拆成两个进程这样主抽取的checkpoint不受网络影响。先建立主抽取进程GGSCI EDIT PARAMS EXTORAEXTRACT EXTORA USERID oggpdb1, PASSWORD ogg TRANLOGOPTIONS EXCLUDEUSER ogg EXTRAIL ./dirtrail/lt TABLE ogg.T_ORDER; TABLE ogg.T_USER;逻辑说明EXTRACT EXTORA声明进程名必须与EDIT PARAMS的文件名一致USERID指定OGG连接源库的数据库账号提前在源库创建好并授予DBA或SELECT ANY TRANSACTION等最小权限TRANLOGOPTIONS EXCLUDEUSER ogg让OGG不去抽取自己的同步数据防止循环陷阱EXTRAIL定义本地trail文件路径TABLE定义要同步的表可以用TABLE ogg.*;匹配全部表。注意Windows系统里trail文件路径用./dirtrail/lt相对路径最稳妥绝对路径要注意反斜杠转义。trail文件名是两字符前缀OGG会自动补6位序列号。然后在GGSCI中注册主抽取进程GGSCI ADD EXTRACT EXTORA, TRANLOG, BEGIN NOW GGSCI ADD EXTTRAIL ./dirtrail/lt, EXTRACT EXTORA参数说明TRANLOG表示从日志抓取BEGIN NOW表示从当前时间点开始记录。ADD EXTTRAIL把trail文件和抽取进程绑定。这样主抽取进程每抓一段日志就把数据写入lt开头的trail文件。数据泵进程配置GGSCI EDIT PARAMS PUMPEXTRACT PUMP USERID oggpdb1, PASSWORD ogg RMTHOST 192.168.1.100, PORT 7809 RMTTRAIL /u01/ogg/dirtrail/rt TABLE ogg.T_ORDER; TABLE ogg.T_USER;逻辑说明RMTHOST指定目标端Linux机器的IP和Manager端口RMTTRAIL是落地到目标端的trail文件路径这里必须写Linux路径格式TABLE列表与主抽取进程保持一致。注意源端主抽取和目标端Replicat都只需配TABLE中间的数据泵只搬运不选型。注册并启动GGSCI ADD EXTRACT PUMP, EXTTRAILSOURCE ./dirtrail/lt GGSCI ADD RMTTRAIL /u01/ogg/dirtrail/rt, EXTRACT PUMP GGSCI START EXTRACT * GGSCI INFO ALLEXTTRAILSOURCE告诉数据泵读哪个本地trailADD RMTTRAIL建立远程trail映射。全启动后INFO ALL应该看到EXTRACT EXTORA和PUMP都处于RUNNING状态。4. Linux目标端部署从安装依赖到Replicat参数落地目标端是数据最终落地的位置配置比源端稍简单但它管着应用侧入口和初始加载复杂度一点不少。我习惯把目标端的MGR、Replicat、checkpoint表和初始化装载放在一个流程里做减少反复切换上下文。4.1 目标端安装与依赖检查Linux上的OGG安装核心是两件事目录和权限。用oracle用户操作mkdir -p /u01/ogg chown oracle:oinstall /u01/ogg chmod 750 /u01/ogg cd /u01/ogg # 假设安装包已上传至/home/oracle/ unzip -q /home/oracle/ggs_linux_19c.zip逻辑说明只要目录权限正确、安装包版本匹配解压即可完成安装不需要configure或make。解压后依然要CREATE SUBDIRS初始化目录。验证动态库依赖ldd /u01/ogg/extract | grep not found参数说明Oracle 19c的OGG依赖libjvm.so、libnnz19.so等Oracle客户端库。ldd如果输出not found需要把Oracle环境变量指过去。我一般会在/u01/ogg/.bash_profile里导出export ORACLE_HOME/u01/app/oracle/product/19.0.0/dbhome_1 export LD_LIBRARY_PATH$ORACLE_HOME/lib:$ORACLE_HOME/rdbms/lib export NLS_LANGAMERICAN_AMERICA.AL32UTF8NLS_LANG这里必须与目标库字符集一致否则Replicat按错误字符集解释trail中文数据直接乱码。如果你的源库是ZHS16GBK这里就要写AMERICAN_AMERICA.ZHS16GBK或者让目标库也建为GBK。跨字符集最佳实践是两端都用AL32UTF8源OGG进程的NLS_LANG也设置成AL32UTF8让Oracle在日志解析阶段完成转换。4.2 Replicat与checkpoint表的配置Replicat进程在目标库回放数据它的checkpoint信息需要落到一张表中这张表叫做checkpoint表。先执行OGG自带的建表脚本cd /u01/ogg sqlplus ogg/ogg /u01/ogg/sql/OGGcore.sql脚本会在目标库创建类似OGG.ggs_checkpoint的系列表。然后在GGSCI里注册GGSCI DBLOGIN USERID oggtdb1, PASSWORD ogg GGSCI ADD CHECKPOINTTABLE OGG.ggs_checkpoint参数说明DBLOGIN让GGSCI能连上目标库执行DDLADD CHECKPOINTTABLE把checkpoint表绑定给OGG。没有checkpoint表Replicat进程也能跑但每次重启都要人工确认位点容易出错。我每次都建。接着编辑Replicat参数GGSCI EDIT PARAMS REPORAREPLICAT REPORA USERID oggtdb1, PASSWORD ogg SOURCECHARSET ZHS16GBK TARGETCHARSET AL32UTF8 DISCARDFILE ./dirrpt/repora.dsc, APPEND, MEGABYTES 50 REPERROR DEFAULT, DISCARD HANDLECOLLISIONS MAP ogg.T_ORDER, TARGET ogg.T_ORDER; MAP ogg.T_USER, TARGET ogg.T_USER;逻辑说明SOURCECHARSET和TARGETCHARSET声明源端trail字符集与目标库字符集源库是GBK、目标库是UTF8时必须显式配置DISCARDFILE指定错误数据落盘位置REPERROR DEFAULT, DISCARD让无法回放的事务记入discard文件而不终止进程HANDLECOLLISIONS处理初始化阶段可能出现的重复主键或缺失行MAP语句完成源表到目标表的映射这里同名同构所以两遍写一样。注意HANDLECOLLISIONS只应在初始化加载期间使用日常增量同步必须去掉否则真正的数据冲突会被静默吞掉。生产上见过团队一年多没去掉这个参数某天源端漏发了一批变更目标端全部自动忽略账都对不上。注册Replicat并启动GGSCI ADD REPLICAT REPORA, EXTTRAIL ./dirtrail/rt, CHECKPOINTTABLE OGG.ggs_checkpoint GGSCI START REPLICAT REPORA GGSCI INFO ALL4.3 初始化数据装载先追平基线再开增量OGG同步是逻辑复制只同步日志产生的变更不会自动拷贝存量数据。所以部署一个新同步链路时必须先做一次全量初始化把存量数据搬到目标库然后让OGG从初始化开始时刻的日志位点继续补增量。常见做法是用Oracle自带的EXPDP/IMPDP做基线。顺序是先完成OGG所有进程配置但暂不启动Replicat源端启动抽取进程和数据泵用TRANSACTIONS对齐方式确定同步起点后在源端导出数据目标端导入完成最后启动Replicat。导出导入命令示例expdp ogg/oggsrc_db directoryDATA_PUMP_DIR dumpfilebase_%U.dmp parallel4 tablesogg.T_ORDER,ogg.T_USER impdp ogg/oggdst_db directoryDATA_PUMP_DIR dumpfilebase_%U.dmp parallel4 table_exists_actiontruncate逻辑说明导出用expdp并行参数减少总耗时导入用table_exists_actiontruncate清掉目标端可能存在的测试数据避免主键冲突。导出期间业务继续写入导入完成后目标库落后一部分增量这部分由Replicat追上。参数说明更稳妥的做法是用OGG的Initial Load模式即ADD REPLICAT REPORA, SPECIALRUN让Replicat以一次性任务的方式追完整段trail。但SPECIALRUN方式下不会更新目标端checkpoint表追完要重启进程切换为正常模式步骤繁琐。我实际生产首选EXPDP/IMPDP配合CDC式追平导入完成后启动Replicat它会自动从远程trail的最早未应用位置开始补数据。前提是目标端导入期间源端的trail文件没有被purge掉所以初始化期间要把MGR参数里PURGEOLDEXTRACTS的MINKEEPHOURS临时调大比如改成48小时。5. 初始化加载与增量同步避坑5个高频故障定位记录OGG部署最磨人的是故障排查。我把这些年见过的高频坑整理成5条每条的写法都是“现象→原因→解决”方便你真遇到时按图索骥。5.1 源库没开补充日志同步第一天就abend现象源端EXTRACT进程启动后几秒到几分钟内变成ABEND查看dirrpt/extora.rpt日志提示ORA-01291: missing log或Supplemental logging not enabled。原因源库只开了归档模式没开补充日志。OGG从在线日志中解析主键列时找不到足够的列信息直接报错退出。解决登录源库执行前面第3.1节的两条ALTER DATABASE命令开启最小补充日志和强制日志然后重启EXTRACT进程。注意开启补充日志后必须推送一次新的归档才能让OGG从新日志中读取完整信息所以我一般会执行一次ALTER SYSTEM SWITCH LOGFILE再重启进程。5.2 目标表已有历史数据主键冲突刷爆discard现象Replicat进程一直RUNNING但目标表数据不增长discard文件以MB级速度膨胀里面全是ORA-00001: unique constraint violated。原因目标表里本来就有存量测试数据或历史数据Replicat回放源端INSERT时主键冲突。这种情况常见于初始化导入没做truncate或者初始化期间有人手动往目标表插了数据。解决先停止Replicat把涉及的目标表数据清掉用TRUNCATE TABLE而不是DELETE避免redo暴涨再启动Replicat让其重新追放。如果业务上目标表不能清就得做数据比对、制定合并规则或者映射时用COLMAP重写目标主键。简单场景就用HANDLECOLLISIONS先撑住同步稳定后再慢慢排查冲突数据。5.3 中文变问号字符集不对齐的老问题现象源端表里的中文同步到目标库变成了??数字英文正常。原因源库ZHS16GBK、目标库AL32UTF8两边的OGG进程NLS_LANG都没显式设置各自按操作系统默认字符集解析中文在字节转码时丢失。解决三层对齐。源库OGG进程设置NLS_LANGSIMPLIFIED CHINESE_CHINA.ZHS16GBK目标端Replicat进程设置NLS_LANGAMERICAN_AMERICA.AL32UTF8在Replicat参数里加上SOURCECHARSET ZHS16GBK和TARGETCHARSET AL32UTF8。改完重启Replicat它会从trail重新解析已经乱码的历史数据需要从初始化阶段重新同步。5.4 时区不一致引起的8小时漂移看起来像同步丢了现象目标库最新一条数据的CREATE_TIME比源库慢8小时且实时延迟一直存在但进程状态正常。原因两边操作系统时区不一致源端东八区、目标端UTCReplicat按目标会话时区解释trail里的时间型数据。解决把两端操作系统时区统一为Asia/Shanghai数据库层确认目标库DBTIMEZONE为08:00在Replicat参数中给时间列做显式映射例如COLMAP (create_time create_time AT TIME ZONE Asia/Shanghai)。改完重启Replicat先用一条测试数据验证时间一致再放量同步。5.5 trail文件占满磁盘同步进程集体罢工现象源端磁盘使用率飙升到100%EXTRACT进程ABEND报错Trail file is full或Unable to write to trail file目标端同样出现磁盘满。原因MGR参数里没配PURGEOLDEXTRACTS或者初始化期间手动把MINKEEPHOURS调大后忘了调回去。trail文件按照每个约10MB持续增长3天不清理就能吃掉几十GB。解决在两端MGR参数中配置自动清理PURGEOLDEXTRACTS ./dirtrail/*, USECHECKPOINTS, MINKEEPHOURS 12USECHECKPOINTS确保只删除所有进程都不再读取的trail不会误删未消费数据。清完磁盘后重启Manager它会立即执行一次purge。经验上说trail文件所在分区至少预留同步峰值日志量的3倍空间我在生产环境统一按单日redo量的5倍规划。6. 同步质量验证与日常运维技巧用一张表盯住延迟和断点部署完不等于交付真正决定这套OGG能不能长期扛住的是日常验证手段。我自己的做法是配一个监控SQL每10分钟查一次两端延迟超过阈值就告警。6.1 一条命令盯住交付延迟GGSCI INFO ALL GGSCI STATS REPLICAT REPORA, LATEST逻辑说明INFO ALL能看到每个进程的状态和Lag值Lag的单位是秒表示源端事务写入trail与目标端应用之间的时间差。正常情况下应该是个位数秒超过30秒就要关注。LATEST输出最近一次事务的时间戳判断进程是不是卡住了。很多团队只看进程RUNNING就认为没事这是最大的误区。REPLICAT长期RUNNING但Lag持续增大说明它在缓慢追数据而不是实时同步。我会把INFO ALL的Lag抓到监控脚本里超过60秒就报警。6.2 进程状态巡检与异常恢复每天定时巡检除了看进程状态还要看两端dirrpt目录下的*.rpt文件有没有新增ERROR字样。grep -i ERROR /u01/ogg/dirrpt/*.rpt一旦发现REPLICAT因某个事务报错可以跳过坏事务避免整个链路停摆GGSCI SEND REPLICAT REPORA, SKIP这条命令跳过当前正在报错的事务并继续处理后续数据。注意SKIP等同于丢弃一个事务必须在核对日志确认跳过的是脏数据或无法回放的历史数据后才执行。真实业务数据不能用SKIP硬跳要先去源库查清数据手动补偿。6.3 日常养护purge、归档与重启顺序日常保养三件事磁盘空间、MGR自动重启、重启顺序。重启OGG时我严格按照“先目标端后源端、先数据泵后主抽取”的顺序执行目标端MGR、目标端REPLICAT、源端MGR、源端PUMP、源端EXTRACT。顺序错乱的典型后果是数据泵先起、主抽取未起远程trail没有新数据Replicat等待后无异常但只要顺序反过来就可能出现源端主抽取持续写trail、目标端还没启Replicat导致远程trail堆积磁盘提前占满。另外OGG账号密码变更后参数文件里的USERID和PASSWORD要同步更新。从OGG 19c开始支持USERIDALIAS方式连接Oracle Wallet能避免密码明文写在dirprm下的参数文件里。生产环境我建议尽早切到USERIDALIAS配合钱包管理安全性高很多也省去每次改数据库密码要同步改OGG配置的麻烦。最后说一个我自己吃过亏的习惯无论同步链路多稳定每个月必须做一次真实故障演练——手动停掉目标端REPLICAT让它落后10分钟再手动启验证能否自动追平。这一步能暴露大量平时发现不了的问题比如trail被purge过早、checkpoint表损坏、目标表索引失效。一套同步系统如果连续三个月不验证断点恢复关键时刻基本靠不住。希望这些细节点能帮你在部署OGG时少走几趟弯路。本文还有配套的精品资源点击获取
网站建设高端定制企业官网