简介这份PDF面向需要在异构Oracle环境间做实时数据同步的DBA与运维人员聚焦Oracle GoldenGate 12.2.0.2从Windows源库到Linux目标库的部署实操重点解决归档模式、强制日志、附加日志、goldengate用户授权及目标库写权限等前置配置问题。内容按安装、配置、组件、监控维护展开涵盖解压与可视化安装、ggsci创建子目录、GLOBALS与checkpoint表设置、MGR及抽取/复制进程配置要点并给出日志检查与故障排查思路便于按步骤搭建同步链路、对照关键参数查漏补缺。资源包共1个PDF文件约496KB轻量便于随查随用。目前已有297人学习适合刚接触OGG跨平台同步、需要一份可落地配置清单的中级读者参考。1. 源端 Windows、目标端 Linux 的 OGG 链路卡人的从来不是安装包这条链路跑通的标志不是 ggsci 里显示 RUNNING而是源端一条 insert 提交后目标端 select 立刻读得到同一行。标题写的是 Windows 同步到 Linux资料里给的却是一整套 Linux 侧的 ggsci 命令原因很实在——OGG 的参数文件、trail 文件命名、进程编排在两端几乎一模一样真正随操作系统变的是安装方式、目录结构和环境变量。这份 Oracle GoldenGate 12.2.0.2 的部署记录从 runInstaller 一路写到 truncate 验证把数据同步链路上必须打开的归档、附加日志、checkpoint 表、SCN 对齐都点到了。适合手上正有一台 11g 源库要往 Linux 侧搬数据、又不想上重型同步工具的 DBA也适合第一次接手 OGG 运维、被 MGR 和 Extract 绕晕的人。2. 装包与环境核对12.2.0.2 在 Linux 侧的落地路径装 OGG 这件事图形化安装器本身十分钟能点完翻车的往往在前后两头装之前没核对 ORACLE_HOME 和字符集装之后目录权限给错、MGR 起不来。所以这一章按「解压 → 检查环境 → 跑安装器 → 规划目录」的顺序走Windows 侧的差异单独拆一节说。2.1 解压安装包与确认 shiphome 结构OGG 12.2.0.2 的 Linux x64 安装包是一个压缩包解出来是标准 OUI 目录树Disk1 下面才是 runInstaller。这一步用 oracle 用户做别用 root 解压再 chown容易漏掉隐藏文件。# 切到 oracle 用户OGG 必须以数据库软件属主身份安装 su - oracle # 解压 shiphome得到 fbo_ggs_Linux_x64_shiphome 目录 unzip 122022_fbo_ggs_Linux_x64_shiphome.zip # 进入 OUI 目录 cd fbo_ggs_Linux_x64_shiphome/Disk1解压完先别急着跑安装器确认一下目录里有没有runInstaller和response两个东西。前者是图形安装入口后者是静默安装模板。如果服务器没有图形环境用 response 文件静默装更省事参数含义和图形界面里的选项一一对应。我一般会先把 response 文件复制一份再改原始文件留着当参照。2.2 安装前的环境核对三个变量决定后面顺不顺OGG 的进程是挂在数据库会话上的环境变量错一个后面 Extract 起来就会报连不上实例。装之前把这三项确认掉# 确认数据库软件属主和实例名 echo $ORACLE_HOME echo $ORACLE_SID # 确认客户端字符集源目标和 OGG 进程三处必须一致 echo $NLS_LANGNLS_LANG是重灾区。源库如果是AMERICAN_AMERICA.AL32UTF8目标库是ZHS16GBK同步过去的汉字就会变成问号而且不报错。这种情况只能靠建库时统一字符集解决事后改库成本极高。安装前把两端select * from nls_database_parameters where parameterNLS_CHARACTERSET;的输出对一遍比什么都强。2.3 runInstaller 里选数据库版本这一步进入 Disk1 执行./runInstallerOUI 会先问你要给哪个版本的数据库装 OGG。这一步不能随便选选 11g 就只会装 11g 的库接口后面连 12c 实例会直接失败。# 图形化安装入口 ./runInstaller界面上依次是选择数据库版本Oracle Database 11g / 12c、指定 OGG 安装目录、指定 inventory 目录、执行安装。安装目录我一般放在/u01/app/ogg刻意避开ORACLE_HOME原因是 OGG 升级频繁放在数据库 home 下面哪天数据库打补丁把目录清了OGG 的参数文件跟着一起没。2.4 安装后的目录规划与权限装完只是有了二进制真正的参数、报告、trail 文件都在子目录里。这些子目录不是安装器建的要进 ggsci 手动create subdirs这一点第 4 章会展开。这里先把权限理顺# 安装目录属主必须是 oracle否则 ggsci 写不了 dirrpt chown -R oracle:oinstall /u01/app/ogg chmod -R 775 /u01/app/ogg权限给错的典型症状是ggsci 能进start mgr也能执行但dirrpt下死活没有报告文件ggserr.log里全是 Permission denied。这类问题排查起来很费时间因为 ggsci 不报错只是默默不写。2.5 Windows 源端和 Linux 目标端的差异对照标题里的跨平台场景实际差异集中在这几处配置逻辑本身是同一套项目Linux 侧Windows 侧安装入口./runInstallersetup.exe或 OUI 图形界面命令解释器./ggsciggsci.exe目录写法/u01/app/oggD:\ogg参数文件里用正斜杠或双反斜杠MGR 自启无系统服务靠脚本或AUTOSTART可注册为 Windows 服务大小写文件名敏感不敏感但参数里的表名仍按数据库规则跨平台最容易忽略的是 trail 文件路径。Windows 侧RMTTRAIL如果写成D:\ogg\dirdat\gs传到 Linux 目标端时Replicat 的exttrail必须写成./dirdat/gs两边路径不要求字面一致只要求指向各自本地的同一个相对位置。搞混了就会出现 DataPump 显示写入成功、Replicat 却报 Unable to open trail file 的场面。3. 数据库侧的前置开关归档、强制日志、附加日志三件套OGG 的 Extract 是从 redo 日志里挖变更的所以数据库必须先把「日志写得足够详细」这件事保证好。这一章按源库、账号、目标库三段走每一段都有可以直接粘贴的 SQL也有容易漏掉的顺序问题。3.1 源库归档模式与强制日志归档是前提没开归档redo 被覆盖Extract 就无从谈起。强制日志的作用是让所有操作都记 redo包括 nologging 的批量加载不然大批量插入在目标端会缺行。-- 切到 mount 状态改归档模式 SQL shutdown immediate; SQL startup mount; SQL alter database archivelog; SQL alter database open; -- 强制所有操作写 redonologging 也不例外 SQL alter database force logging; -- 打开最小附加日志OGG 需要它来定位行 SQL alter database add supplemental log data; -- 切换一次日志让附加日志立刻生效 SQL alter system switch logfile;最后那句alter system switch logfile别省。附加日志是写在日志头里的标记当前正在写的那个日志组不会立刻带上切一次才生效。很多人配完就去做 trandata结果 Extract 起来报附加日志未启用回头查半天其实就是少切了一下。验证用一条 SQL 就够-- SUPPLEME 应为 YESFOR 应为 YES SQL select SUPPLEMENTAL_LOG_DATA_MIN, FORCE_LOGGING from v$database;3.2 OGG 专用账号表空间、权限与管理员授权不建议用 sys 或业务账号跑 OGG。专用账号的好处是权限边界清晰出问题好定位也方便审计。-- 建独立表空间checkpoint 表会放这里 SQL create tablespace goldengate 2 datafile /u01/app/oracle/oradata/test1/ogg01.dbf 3 size 300m autoextend on; -- 建账号 SQL create user goldengate identified by goldengate 2 default tablespace goldengate; -- 基础权限 SQL grant connect, resource, create session, alter session to goldengate; -- 闪回查询权限日志信息不足时 Extract 会回查数据库 SQL grant flashback any table to goldengate; -- 关键一步授予 OGG 管理员权限内部会打包一堆系统权限 SQL exec dbms_goldengate_auth.grant_admin_privilege(GOLDENGATE);grant_admin_privilege这个包调用是 11.2.0.4 之后的标准做法它会一次性授予 OGG 需要的全部系统权限包括select any table、lock any table、execute on dbms_flashback等。手工一条条 grant 也能凑出来但漏一条就要在运行期炸一次没必要。3.3 目标库日志可以少开DML 权限必须多给目标库只做应用不做抽取所以不需要附加日志和强制日志。但 Replicat 要往业务表里写数据权限反而更宽。-- 表空间和账号与源库保持一致 SQL create tablespace goldengate 2 datafile /u01/app/oracle/oradata/test1/ogg01.dbf 3 size 300m autoextend on; SQL create user goldengate identified by goldengate 2 default tablespace goldengate; SQL grant connect, resource, create session, alter session to goldengate; SQL grant flashback any table to goldengate; SQL exec dbms_goldengate_auth.grant_admin_privilege(GOLDENGATE); -- 目标端额外需要跨表 DML 权限 SQL grant insert any table, update any table, delete any table to goldengate;insert/update/delete any table这三条是 Replicat 应用的底气。少了任何一条同步会在第一次遇到该类型 DML 时抛ORA-01031: insufficient privileges而且 Replicat 默认出错就 ABEND进程直接停。3.4 enable_goldengate_replication 参数两端都要打开这个实例级参数否则 OGG 进程连上来会被拒绝。-- scopeboth 表示立即生效并写入 spfile SQL alter system set enable_goldengate_replication true scopeboth;这个参数在 11.2.0.4 及以上才有11.2.0.3 之前的库只能靠打补丁或者手工授权绕过。执行完用show parameter enable_goldengate确认值是 TRUE 才算数。我见过有人执行了但忘了scopeboth重启库之后同步全线中断查了半天才发现参数回到 FALSE。4. 进程编排MGR、Extract、DataPump、Replicat 的配置顺序OGG 的运行模型是四个进程接力Extract 从源库 redo 里抓变更写本地 trailDataPump 把本地 trail 通过网络投递到目标端Replicat 读目标端 trail 应用到数据库MGR 是这三位的主管负责端口分配、进程拉起和日志汇总。顺序不能乱MGR 必须最先起。4.1 create subdirs 与 GLOBALS 全局参数第一次进 ggsci先建目录结构。这一步在源端和目标端都要做。# 进入 OGG 安装目录 cd /u01/app/ogg # 进入命令行解释器 ./ggsciGGSCI (test1) 1 create subdirs执行完会看到dirprm、dirrpt、dirchk、dirdat、dirdef等一长串目录被创建。其中dirprm放参数文件dirdat放 trail 文件dirrpt放进程报告dirchk放检查点。接着配全局参数文件GLOBALS源端目标端内容一致GGSCI (test1) 2 edit params ./GLOBALS GGSCHEMA goldengate CHECKPOINTTABLE goldengate.ggschkpt SYSLOG NONEGGSCHEMA指定 OGG 的 schema 名CHECKPOINTTABLE指定检查点表全名。SYSLOG NONE表示不往系统日志写避免日志爆掉。4.2 checkpoint 表Replicat 的记账本checkpoint 表记录 Replicat 处理到哪个位置是断点续传的依据。丢了这张表重启后要么重复应用要么从头再来。GGSCI (test1) 4 dblogin userid goldengate password goldengate Successfully logged into database. GGSCI (test1 as goldengatetest1) 6 add CHECKPOINTTABLE goldengate.ggschkpt Successfully created checkpoint table goldengate.ggschkpt.注意add CHECKPOINTTABLE必须在dblogin之后执行因为它要连库建表。建完可以在 sqlplus 里desc goldengate.ggschkpt看一眼正常应该有七八个字段包括group_name、group_key、seqno、rba等。4.3 MGR 参数逐条说明MGR 是两个端口在干活PORT是管理端口DataPump 连它做握手DYNAMICPORTLIST是数据端口范围实际传输走这里。GGSCI (test1) 7 edit params mgr PORT 7809 DYNAMICPORTLIST 7800-7810 USERID goldengate, PASSWORD goldengate AUTORESTART ER *, RETRIES 3, WAITMINUTES 5, RESETMINUTES 60 LAGREPORTMINUTES 10 LAGCRITICALMINUTES 10 PURGEOLDEXTRACTS ./dirdat/*, USECHECKPOINTS, MINKEEPHOURS 12 PURGEDDLHISTORY MINKEEPDAYS 7, MAXKEEPDAYS 14, FREQUENCYHOURS 3 PURGEMARKERHISTORY MINKEEPDAYS 7, MAXKEEPDAYS 14, FREQUENCYHOURS 3几个参数的意义值得单独拎出来AUTORESTART ER *, RETRIES 3, WAITMINUTES 5, RESETMINUTES 60任何进程挂了自动重试 3 次每次间隔 5 分钟如果 60 分钟内没再挂重试计数清零。PURGEOLDEXTRACTS ... MINKEEPHOURS 12trail 文件保留 12 小时超期且已被 checkpoint 消费的会被清理。磁盘小的话这个值别设太大。LAGCRITICALMINUTES 10延迟超过 10 分钟就写告警日志配合监控脚本能提前发现积压。防火墙要放通7809和7800-7810两段只开 7809 会出现 DataPump 握手成功但传数据超时的怪现象。4.4 Extract 进程从 redo 抓变更Extract 是最吃配置的一环参数写少了跑不稳写多了白占资源。GGSCI (test1) 1 edit param extgsxf EXTRACT extgsxf SETENV (ORACLE_HOME/u01/app/oracle/product/11.2.0/db_1) SETENV (ORACLE_SIDtest1) SETENV (NLS_LANGAMERICAN_AMERICA.AL32UTF8) USERID goldengate, PASSWORD goldengate EXTTRAIL ./dirdat/gs TRANLOGOPTIONS LOGRETENTION DISABLED BR , BRINTERVAL 20M TRANLOGOPTIONS BUFSIZE 2048000 GETREPLICATES CACHEMGR CACHESIZE 2GB GETTRUNCATES DDL INCLUDE MAPPED, OBJTYPE TABLE INCLUDE MAPPED OBJTYPE INDEX DDLOPTIONS ADDTRANDATA RETRYOP RETRYDELAY 10 MAXRETRIES 10 DDLOPTIONS REPORT DISCARDFILE ./dirrpt/extgsxf.dsc, APPEND, MEGABYTES 1000 DISCARDROLLOVER AT 6:00 REPORTROLLOVER AT 6:00 REPORTCOUNT EVERY 1 HOURS, RATE FETCHOPTIONS FETCHPKUPDATECOLS FETCHOPTIONS MISSINGROW ABEND STATOPTIONS REPORT FETCHWARN LONGTRANS 1H, CHECKINTERVAL 10m DYNAMICRESOLUTION TABLE test.*;逐段解释SETENV三行把数据库环境带进进程漏了NLS_LANG会出现中文乱码TRANLOGOPTIONS LOGRETENTION DISABLED表示不依赖数据库的归档保留策略由 OGG 自己管理BR , BRINTERVAL 20M是 Bounded Recovery每 20 分钟存一次中间态防止长事务导致 Extract 内存爆掉CACHEMGR CACHESIZE 2GB是长事务缓存上限LONGTRANS 1H表示超过 1 小时的事务会被单独记录并告警。GETTRUNCATES这一行必须有否则源端 truncate 不会同步到目标端这是很多人同步完发现目标表数据多出来的根源。建好参数后注册进程并绑定 trailGGSCI (test1) 2 add extract extgsxf tranlog, begin now GGSCI (test1) 3 add exttrail ./dirdat/gs, extract extgsxf, megabytes 1024 GGSCI (test1) 4 start extgsxfbegin now表示从当前时刻开始抓如果要做历史数据初始化这里要换成begin now配合后面的 SCN 对齐。4.5 DataPump 进程跨网络的搬运工DataPump 只做一件事——把本地 trail 通过网络送到目标端。它不解析数据所以配置比 Extract 简单得多。GGSCI (test1) 60 edit param dpgskf EXTRACT dpgskf PASSTHRU DYNAMICRESOLUTION RMTHOST 10.0.100.141, MGRPORT 7809 RMTTRAIL ./dirdat/gs DISCARDFILE ./dirrpt/dpgskf.dsc, APPEND, MEGABYTES 100 DISCARDROLLOVER AT 6:00 REPORTROLLOVER AT 6:00 REPORTCOUNT EVERY 1 HOURS, RATE TABLE test.*;PASSTHRU是关键表示不做任何转换直接透传性能最好。RMTHOST填目标端 IPMGRPORT必须和目标端 MGR 的PORT一致。RMTTRAIL是目标端的相对路径不是源端路径写错会报 Remote trail not found。GGSCI (test1) 61 add extract dpgskf, exttrailsource ./dirdat/gs GGSCI (test1) 62 add RMTTRAIL ./dirdat/gs, extract dpgskf, megabytes 1024 GGSCI (test1) 63 start dpgskf4.6 Replicat 进程把变更写进目标库GGSCI (test2) 13 edit param repgs1 REPLICAT repgs1 SETENV (ORACLE_HOME /u01/app/oracle/product/11.2.0/db_1) SETENV (ORACLE_SID test1) SETENV (NLS_LANG AMERICAN_AMERICA.AL32UTF8) USERID goldengate password goldengate ASSUMETARGETDEFS DBOPTIONS DEFERREFCONST DBOPTIONS SUPPRESSTRIGGERS DISCARDFILE ./dirrpt/repgs1.dsc, APPEND, MEGABYTES 1000 DISCARDROLLOVER AT 6:00 REPERROR (DEFAULT, ABEND) DDL INCLUDE MAPPED, OBJTYPE TABLE INCLUDE MAPPED OBJTYPE INDEX DDLOPTIONS REPORT REPORTROLLOVER AT 6:00 REPORTCOUNT EVERY 30 MINUTES, RATE STATOPTIONS RESETREPORTSTATS NUMFILES 150 GETTRUNCATES DYNAMICRESOLUTION ALLOWNOOPUPDATES GROUPTRANSOPS 1000 MAP test.*, TARGET test.*;ASSUMETARGETDEFS表示源目标表结构完全一致不需要生成定义文件异构场景结构不同才需要SOURCEDEFS。SUPPRESSTRIGGERS抑制目标端触发器防止同步写入再触发一遍业务逻辑。GROUPTRANSOPS 1000把 1000 条小事务合成一批提交对目标库压力小很多但会牺牲一点实时性。GGSCI (test2) 20 add replicat repgs1, exttrail ./dirdat/gs, checkpointtable goldengate.ggschkpt4.7 初始化数据与 SCN 对齐存量数据不能靠 OGG 追要先导一份再从指定 SCN 开始增量。顺序是先在源端查当前 SCN用这个 SCN 导出导入目标端然后 Replicat 从这个 SCN 之后开始应用。-- 源端记录当前 SCN SQL select to_char(current_scn) from v$database; -- 假设输出 1085057# 源端按 SCN 一致性导出 expdp test/test TABLEStest.t1 DUMPFILEt1.dmp flashback_scn1085057 # 拷贝到目标端后导入 impdp test/test dumpfilet1.dmpGGSCI (test2) 21 start replicat repgs1, aftercsn 1085057aftercsn是这套流程的安全阀。它告诉 Replicat 只应用这个 SCN 之后的变更导出时刻之前的数据已经在 dump 里了不会重复。这个值填错要么数据重复值取小了要么中间丢一段值取大了所以查 SCN 和导出之间不要做任何 DDL。5. 避坑五个让链路装死或数据错位的典型场景5.1 add trandata 报没有主键现象执行add trandata test.t1返回 No primary key or unique index found附加日志加不上Extract 起来后该表不同步。原因OGG 靠主键或唯一索引定位行没有键的表无法做行级同步。解决优先给表补主键。实在改不了表结构就指定列作为逻辑主键GGSCI (test1) 13 add trandata test.t1, COLS (object_id, created)COLS里的列组合必须能唯一确定一行否则同步会产生重复数据。5.2 Replicat 起来就 ABEND报找不到 checkpoint 表现象start replicat后立刻停止ggserr.log里是 Checkpoint table goldengate.ggschkpt does not exist。原因add replicat时没带checkpointtable参数或者GLOBALS里的CHECKPOINTTABLE写错了 schema。解决先确认表真的存在select * from dba_tables where table_nameGGSCHKPT;不存在就重新add CHECKPOINTTABLE存在的话核对GLOBALS拼写注意大小写。修正后删除 Replicat 重新添加不要试图原地改。5.3 数据传过去了但字符是乱码或问号现象目标端查出来中文全是???库本身能存中文。原因源端NLS_LANG、OGG 进程SETENV里的NLS_LANG、目标库字符集三者不一致。解决三处统一。Extract 和 Replicat 参数文件里的SETENV (NLS_LANG...)必须和源库、目标库的实际字符集对得上。如果库字符集本身就不支持中文只能重建库这个没有后悔药。5.4 同步后目标端业务触发器重复执行现象业务方反馈一条订单在目标端被处理了两次。原因Replicat 应用 DML 时默认会触发目标表的触发器业务逻辑又跑了一遍。解决Replicat 参数里加DBOPTIONS SUPPRESSTRIGGERS让会话级触发器失效。加完重启 Replicat 生效。注意这个参数只对普通触发器有效系统触发器不受影响。5.5 大事务导致 Extract 延迟飙升甚至卡死现象info extract extgsxf显示 lag 从几秒涨到几十分钟ggserr.log里有 Long transaction 告警。原因源端跑了一个几百万行的大事务Extract 必须等事务提交才能开始写 trail内存和磁盘缓存被撑满。解决参数里加LONGTRANS 1H, CHECKINTERVAL 10m让 Extract 每小时检查一次长事务并单独落盘同时把CACHEMGR CACHESIZE调到 2GB 以上给足缓冲。根治办法是和业务方约定大事务拆批提交OGG 侧只能缓解。6. 收尾验证别只看 RUNNING用三条 SQL 确认链路真的活了进程状态是 RUNNING 只说明它没死不代表数据在流动。我一般会走一遍「插入 → 删除 → 截断」三段验证每一步都在源端执行、目标端确认中间不看报告只看数据。先验证增量插入。源端记下当前最大 ID插一行新数据提交-- 源端 SQL select max(object_id) from t1; -- 假设是 87365 SQL insert into t1 (object_id) values (87366); SQL commit;-- 目标端几秒内应该查得到 SQL select max(object_id) from test.t1; -- 期望 87366再验证删除。这一步能暴露REPERROR配置是否合理因为删除找不到行是最常见的应用错误-- 源端 SQL delete from t1 where object_id 87366; SQL commit; -- 目标端期望回到 87365 SQL select max(object_id) from test.t1;最后验证 truncate。这条能不能过取决于 Extract 和 Replicat 参数里有没有GETTRUNCATES-- 源端 SQL truncate table t1; -- 目标端期望是 0 SQL select count(*) from test.t1;三段都过了链路才算真正可用。中间任何一步对不上先看ggserr.log和时间最近的dirrpt报告再看info extract和info replicat的 lag 值基本能定位到是抽取、传输还是应用环节。日常巡检我还会顺手跑两个命令stats extract extgsxf看处理速率lag replicat repgs1看延迟配合 MGR 参数里的LAGCRITICALMINUTES 10超过阈值会自己写日志。那之后我每次交付一条新的 OGG 链路都强制走一遍这三条 SQL 和两个巡检命令一次都没省过因为省下的那十分钟通常会在半夜三点以两倍的时长还回来。希望帮到你。本文还有配套的精品资源点击获取
