简介需要将Oracle数据库从Windows环境实时同步到Linux环境的数据库管理员或运维工程师往往会被OGG跨平台部署的诸多细节问题困扰这份PDF文档正是基于OGG给出的端到端安装部署参考。文档先从整体上梳理源库与目标库的预配置环节包括开启归档模式、强制日志、附加日志创建专用管理用户并授权开启OGG复制参数随后讲解软件解压与可视化安装、子目录初始化以及管理器、抽取进程、应用进程三类核心组件的配置方法最后还给出监控检查、日志查看与常见故障排查思路整个过程按实际运维场景组织便于查阅。文中保留了大量可直接套用的命令示例适合以Oracle为典型环境按步骤对照实施也能帮助初次接触OGG的读者建立跨平台同步的整体认知。资源仅包含1个PDF文件压缩体积约496KB轻量易用已有295人学习对于需要快速上手部署和自主排错的读者尤其具有实际参考价值。1. 为什么 Windows 的 Oracle 要往 Linux 同步OGG 和传统容灾方案的取舍做 Oracle 数据同步这件事一提到跨平台Windows 源库 Linux 目标库很多人第一反应是搭 DataGuard。但 DataGuard 对主备库的版本、平台和架构要求几乎一致现实里源库是 Windows 上跑了好多年的 Oracle 11g目标库是 Linux 上的 Oracle 12c这种组合用 DataGuard 基本走不通。Oracle OGGGoldenGate恰好是这种场景下更顺手的方案它按事务在日志层面抓取变更不关心两端操作系统是否一致只要 OGG 版本和两边数据库兼容就能跑。这篇部署记录是测试环境完整走通的一整套流程覆盖源库归档与附加日志、两端用户权限、Extract / DataPump / Replicat 三个进程配置以及两种不丢数据的初始化方法。适合想用 OGG 做异构同步的 DBA 和数据运维照着搭一次能避掉大部分绊脚的坑。2. 源库与目标库准备归档、附加日志与 OGG 管理账号一次配齐2.1 源库为什么必须开归档和附加日志三个开关的作用边界OGG 的 Extract 进程本质上是读日志的进程它从在线重做日志和归档日志里解析出事务变更。如果数据库没开归档模式日志一切换被覆盖OGG 追不上就会断链。所以源库的第一件事就是把数据库切到归档模式这步不做后面 Extract 启动都困难。我在测试环境用的是 Oracle 11.2.0.4操作顺序如下SQL startup mount SQL alter database archivelog; SQL alter database open; SQL alter database force logging; SQL alter database add supplemental log data; SQL Select SUPPLEMENTAL_LOG_DATA_MIN, FORCE_LOGGING from v$database; SQL alter system switch logfile;force logging 和 supplemental log data 是两个容易被忽略的开关。force logging 保证连 nologging 操作比如某些直接路径加载也会写 redo避免日志链条出现空洞supplemental log data 是给日志补上最小补充日志让 OGG 能从日志里还原出完整的主键和列信息。切换一次日志文件是为了让新生成的日志从一开始就带上附加日志标记否则要等下一次切换才生效。实际观察结果里SUPPLEMENTAL_LOG_DATA_MIN和FORCE_LOGGING都应该是YES我之前见过只开了归档忘了开附加日志的情况Extract 进程能启动但同步出来的数据在目标端报主键冲突排查一圈才发现日志里根本没有完整的键信息。2.2 目标库配置哪些照抄、哪些可以省目标库不需要开附加日志因为它只负责接收并应用 Trail 文件里的变更写入操作由 Replicat 进程自己执行不再走日志解析。这一点新手容易误解把源库的配置原封不动搬到目标库结果数据库多了一堆无用的日志负担。目标库要做的核心事情是建用户、授权、开enable_goldengate_replication。以下是完整代码块SQL create tablespace goldengate datafile /u01/app/oracle/oradata/test1/ogg01.dbf size 300m autoextend on ; SQL create user goldengate identified by goldengate 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); SQL grant insert any table,update any table,delete any table to goldengate; SQL alter system set enable_goldengate_replication true scopeboth;目标端比源端多出来的权限是insert any table / update any table / delete any table。原因很直接Replicat 进程要以 goldengate 用户身份往任意业务表写数据没有这三个 any 权限同步一到目标端就会因为 ORA-01031 权限不足而 abend。enable_goldengate_replication这个参数在 11g 和 12c 里都要设成 true它是数据库允许 GoldenGate 以管理员方式复制数据的开关。注意拼写是goldengate不是golden_gate我在 12c 环境里因为拼错参数名被数据库直接拒绝过。2.3 OGG 管理账号权限grant_admin_privilege 与常见缺权限排查dbms_goldengate_auth.grant_admin_privilege这条命令值得单独说。它的作用是让 goldengate 用户获得 OGG 管理所需的底层权限包括访问数据字典视图、读取在线日志等。实际执行时如果漏掉这条Extract 启动后大概率报 ORA-01031。SQL exec dbms_goldengate_auth.grant_admin_privilege(GOLDENGATE);执行完成后建议顺手验证一下权限是否到位SQL select * from dba_role_privs where granteeGOLDENGATE;常见缺权限场景有两种第一种是只给了 connect / resource没执行 grant_admin_privilegeExtract 报ERROR: OGG-01161或者ORA-01031第二种是目标端漏了 insert any table 这类 DML 权限Replicat 一应用就 abenddiscard 文件里全是权限不足的记录。排查思路是先看 ggserr.log 里有没有 ORA- 开头的错再对照第 2 章这段授权清单逐条核对权限问题占了 OGG 部署早期故障的一大半。3. 安装与初始化Windows 端和 Linux 端的 OGG 环境搭法3.1 安装差异Windows 解压 setup.exeLinux 用 runInstallerOGG 12.2.0.2 的安装包是按平台分开发的Windows 端和 Linux 端要分别下载对应平台的包。Windows 端的包解压后以管理员身份运行 setup.exe安装路径尽量不要带空格和中文我习惯装在C:\OGG装完目录结构是经典的 dirprm / dirrpt / dirdat 这一套。Linux 端我这次用的方式是su - oracle unzip 122022_fbo_ggs_Linux_x64_shiphome.zip cd fbo_ggs_Linux_x64_shiphome/Disk1 ./runInstallerrunInstaller 是图形界面选择 OGG 安装目录和对应的数据库版本。这里有个容易踩的细节OGG 12.2 的安装程序会让你选数据库版本实测环境里源库是 11.2.0.4、目标库是 12.2.0.1但 OGG 软件本身是同一个 12.2.0.2.2 包选择数据库版本只是为了生成对应的环境脚本不影响两边的 OGG 进程通信。装完以后还有个习惯性动作把 OGG 目录的所有者改成 oracle 用户并确认 PATH 里能找到$ORACLE_HOME/bin。OGG 的 Extract 进程启动时要调用数据库的库文件如果 ORACLE_HOME 没设置对启动会报找不到 libclntsh.so。3.2 create subdirs 与 GLOBALS先立骨架再配进程OGG 安装完成后第一件事不是急着配进程而是进入 ggsci 命令行初始化目录结构。源库和目标库都要执行这一套GGSCI (test1) 1 create subdirs Creating subdirectories under current directory /u01/app/ogg Parameter files /u01/app/ogg/dirprm: already exists Report files /u01/app/ogg/dirrpt: already exists Checkpoint files /u01/app/ogg/dirchk: already exists ...create subdirs 会自动建好参数文件目录、报告目录、checkpoint 目录、trail 数据目录等。这一步看起来简单但如果在没创建子目录的情况下直接 edit paramsOGG 会报找不到 dirprm 目录新手容易卡在这。接下来是配置 GLOBALS 文件这个文件存的是 OGG 的全局参数不是某个进程的参数GGSCI (test1) 2 edit params ./GLOBALS GGSCHEMA goldengate CHECKPOINTTABLE goldengate.ggschkpt SYSLOG NONEGGSCHEMA指定 OGG 管理 schema也就是后面建的 goldengate 用户对应的 schemaDDL 同步的辅助表会建在这个 schema 下。CHECKPOINTTABLE指定 checkpoint 表的名字它必须和后面add checkpointtable建出来的表完全一致。SYSLOG NONE是关掉 OGG 往操作系统 syslog 写日志避免日志刷屏。需要注意 GLOBALS 是修改后立即生效的不需要重启任何进程但 checkpoint 表的实际创建要等下一步操作。3.3 checkpoint 表断点续传的地基checkpoint 表是 OGG 容错机制的核心。它记录每个进程当前处理到的日志位置进程异常退出后重启能从上次的位置继续而不是从头重放。没有这张表进程每次重启都可能造成数据重复或丢失。创建步骤在源端和目标端都要做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.dblogin 是让 OGG 用 goldengate 用户连接数据库这一步必须在add CHECKPOINTTABLE之前执行否则 OGG 不知道往哪个数据库建表。如果漏了 dbloginadd 命令会直接报ERROR: Not logged in。checkpoint 表建好后可以在数据库里查这张表的数据里面会记录 extract / replicat 的位置信息。这张表对 OGG 是不可或缺的我遇到过有人为了省空间把它放到临时表空间结果进程启动直接失败所以务必让它待在 goldengate 自己的表空间里。3.4 MGR 参数逐行拆解端口、重启与清理策略MGR 是 OGG 的管家进程负责启动、监控其他进程也是 DataPump 连接目标端的入口。MGR 参数文件虽然不长但每行参数都对应一类运维场景。以下是我测试环境的完整 MGR 配置GGSCI (test1 as goldengatetest1) 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逐个说几个关键参数参数作用我的建议PORT 7809MGR 监听端口DataPump 投递数据时连接这个端口避开常用端口防火墙要放行DYNAMICPORTLIST 7800-7810动态端口范围MGR 会在这个区间分配额外连接端口区间别太小至少 10 个端口AUTORESTART ER *Extract/Replicat 异常退出后自动重启配合 RETRIES 3、WAITMINUTES 5 使用LAGREPORTMINUTES 10每 10 分钟报告一次延迟监控用值设太小日志会很多LAGCRITICALMINUTES 10延迟超过 10 分钟视为严重告警对应业务容忍度调整PURGEOLDEXTRACTS清理过期 trail 文件USECHECKPOINTS 按 checkpoint 决定删哪些USERID goldengate,PASSWORD goldengate这行让我想起一个教训MGR 访问数据库的账号在 12.2 里如果没配好MGR 能启动但进程状态全是STOPPED。检查顺序是先看 MGR 是否正常再用info all看子进程状态。配置完成后源库和目标库分别执行GGSCI (test1 as goldengatetest1) 8 start mgr Manager started.注意两台机器的 MGR 端口要一致DataPump 的RMTHOST配置里写的就是目标端 MGR 的 IP 和 PORT。4. 源端配置DDL 同步脚本、Extract 与 DataPump4.1 DDL 同步脚本执行顺序每步脚本的输入提示如果业务里会做表结构变更DDL 同步是刚需。OGG 12.2 的 DDL 支持不是装完就能用的需要按顺序在源库执行一套脚本顺序错了后面全白搭。以下是在源库以 sysdba 执行SQL conn / as sysdba SQL grant execute on utl_file to goldengate; SQL /u01/app/ogg/marker_setup.sql SQL /u01/app/ogg/ddl_setup.sql SQL /u01/app/ogg/role_setup.sql SQL GRANT GGS_GGSUSER_ROLE TO goldengate; SQL /u01/app/ogg/ddl_enable.sqlmarker_setup.sql是第一步它会在 goldengate schema 下创建 DDL 复制所需的 marker 表ddl_setup.sql创建 DDL 同步的核心对象role_setup.sql生成一个角色脚本跑完会提示你记下角色名通常是GGS_GGSUSER_ROLE然后用 GRANT 授权给 goldengate最后ddl_enable.sql打开 DDL 捕获。执行时注意每个脚本都会提示输入 schema 名称比如让你输入GOLDENGATE或带分号照着提示输入就行。很多人卡在这一步是因为脚本要求输入 schema 后必须额外输入一个斜杠或回车交互方式比较老旧看到光标不动别以为是死机。可选优化还有两个SQL ?/rdbms/admin/dbmspool.sql SQL /u01/app/ogg/ddl_pin goldengateddl_pin的作用是把 DDL 复制相关的对象常驻内存减少硬解析对高频率 DDL 场景有明显的性能提升。执行时需要指定 goldengate schema 名称。4.2 Extract 参数日志抓取的十几个关键开关Extract 是源端的抽取进程从数据库日志里读取变更写到本地 trail 文件。它的参数文件是所有 OGG 配置里最复杂的一份我常用的模板如下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 REPORT AT0:01 FETCHOPTIONS MISSINGROW ABEND STATOPTIONS REPORTFETCHWARN LONGTRANS 1H,CHECKINTERVAL 10m DYNAMICRESOLUTION TABLE test.*;这里挑几个高频调整的参数说明参数作用我会怎么改SETENV设置进程运行时的环境变量ORACLE_HOME 和 ORACLE_SID 必填和数据库实际环境严格一致EXTTRAIL ./dirdat/gs本地 trail 文件路径和前缀前缀建议用两个字符比如 gs方便多进程区分TRANLOGOPTIONS LOGRETENTION DISABLED不让 OGG 参与日志保留管理归档清理交给 RMAN避免两边冲突GETREPLICATES允许捕获由 Replicat 产生的变更双向同步时必开单向同步可关GETTRUNCATES同步 TRUNCATE 操作不开的话源端 truncate 表目标端不会执行DDL INCLUDE MAPPED只捕获映射表范围内的 DDL过滤掉系统表和其他 schema 的 DDLFETCHOPTIONS FETCHPKUPDATECOLS主键列更新时通过 fetch 获取新值保持默认测试环境很少需要改LONGTRANS 1H,CHECKINTERVAL 10m超过 1 小时的长事务每 10 分钟检查一次长事务多的业务建议把 1H 改小以TABLE test.*开头的映射表示抽取 test schema 下的所有表。如果是生产环境建议显式写出表名避免 OGG 去动态解析一堆不必要的对象。添加并启动 Extract 的命令GGSCI (test1) 2 add extract extgsxf tranlog, begin now EXTRACT added. GGSCI (test1) 3 add exttrail ./dirdat/gs, extract extgsxf, megabytes 1024 GGSCI (test1 as goldengatetest1) 56 start extgsxfbegin now表示从现在这个时间点开始抽取megabytes 1024表示单个 trail 文件最大 1024MB满了自动滚动生成下一个。4.3 DataPumpPASSTHRU 与两台机器之间投递DataPump 可以理解为 Extract 的投递员它读本地 trail 文件通过网络把数据送到目标端。之所以单独拆一个进程是为了把抓取和传输解耦Extract 只负责写本地DataPump 只负责传网络两者可以独立启停。配置如下GGSCI (test1 as goldengatetest1) 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是 DataPump 最常用的模式意思是投递进程不做任何数据处理原样搬运性能最好。如果需要在投递过程中做数据过滤或列映射就不能用 PASSTHRU而要改成完整模式并把 TABLE 映射写完整。添加 DataPump 进程的命令有三条顺序不能乱GGSCI (test1 as goldengatetest1) 61 add extract dpgskf, exttrailsource ./dirdat/gs GGSCI (test1 as goldengatetest1) 62 add RMTTRAIL ./dirdat/gs, extract dpgskf, megabytes 1024 GGSCI (test1 as goldengatetest1) 63 start dpgskfexttrailsource ./dirdat/gs指定 DataPump 从哪个本地 trail 读数据这里要和 Extract 的EXTTRAIL ./dirdat/gs完全对应。add RMTTRAIL设置的是目标端的 trail 文件路径路径保持同名可以简化后面 Replicat 的配置。4.4 启动顺序与状态检查从 GGSCI 观察进程源端进程的启动顺序有讲究先启 MGR再启 Extract最后启 DataPump。反着来的话DataPump 会因为没有数据可读而报错。启动后我用 info all 看整体状态GGSCI (test1 as goldengatetest1) 70 info all Program Status Group Lag at Chkpt Time since Chkpt MANAGER RUNNING EXTRACT RUNNING EXTGSXF 00:00:00 00:00:04 EXTRACT RUNNING DPGSKF 00:00:00 00:00:02两个 Extract 进程的名字分别是 EXTGSXF 和 DPGSKF第一个是抓取进程第二个是投递进程。状态都应该是 RUNNINGLag at Chkpt 表示当前延迟正常情况下是 00:00:00。如果状态是 STOPPED 或 ABENDED先看 ggserr.log 最后几十行再决定怎么处理。大部分 Extract 启动失败都能在 ggserr.log 里找到 ORA- 或 OGG- 开头的直接原因。5. 目标端 Replicat 与两种初始化方式从 SCN 续传和 sourceistable5.1 Replicat 参数逐段拆解Replicat 是目标端的应用进程它读 trail 文件并把变更写入目标库。参数文件里有几行是纯为性能和安全考虑的直接抄容易翻车。我的目标端配置如下GGSCI (test2 as goldengatetest1) 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 REPORT AT0:01 STATOPTIONS RESETREPORTSTATS NUMFILES 150 GETTRUNCATES DYNAMICRESOLUTION ALLOWNOOPUPDATES GROUPTRANSOPS 1000 MAP test.* , TARGET test.* ;参数作用踩坑提示ASSUMETARGETDEFS假定两端表结构一致按目标端定义应用两端列不一致时必须改用 defgen 生成的定义文件DBOPTIONS DEFERREFCONST延迟外键约束检查多表加载顺序不一致时避免外键报错DBOPTIONS SUPPRESSTRIGGERS同步时不触发目标端触发器如果业务依赖触发器做审计这个开关要慎重REPERROR (DEFAULT, ABEND)默认错误直接终止复制保证不丢数据想跳过错误改 SKIP 并加 DISCARDGETTRUNCATES允许 TRUNCATE 同步和目标端用户 TRUNCATE 权限一起检查ALLOWNOOPUPDATES允许更新前后值相同的 UPDATE 也执行防止因 ROWID 变化导致目标端数据不一致GROUPTRANSOPS 1000每 1000 个操作提交一次事务值越大提交越频繁性能越好但事务边界会被拆散添加 Replicat 进程时要带上 checkpoint 表GGSCI (test2 as goldengatetest1) 20 add replicat repgs1, exttrail ./dirdat/gs, checkpointtable goldengate.ggschkpt这行命令把 Replicat 和 checkpoint 表绑定进程才能断点续跑。5.2 初始化方式一expdp flashback_scn aftercsn这是我在测试环境主推的初始化方式核心思路先用数据泵导出一份一致性快照再把这份快照导入目标端最后让 Replicat 从对应的 SCN 开始追增量。好处是完全不打断业务适合在线初始化。源库先查当前 SCNSQL select to_char(current_scn) from v$database; CURRENT_SCN ----------- 1085057然后导出注意用 flashback_scn 指定一致性点SQL expdp test/test TABLEStest.t1 DUMPFILEt1.dmp flashback_scn1085057导出期间业务可以继续写OGG 的 Extract 也在持续抓取。因为 flashback_scn 指定了一个历史时刻整个导出是那个时刻的一致性快照。dump 文件传到目标端后导入impdp test/test dumpfilet1.dmp数据导入完成后关键一步来了——用 aftercsn 启动 ReplicatGGSCI (test2 as goldengatetest1) 20 start replicat repgs1, aftercsn 1085057aftercsn 的含义是从 1085057 这个 SCN 之后的 trail 数据开始应用。1085057 之前的数据已经通过 expdp/impdp 到了目标端如果 Replicat 从头应用就会主键冲突不指定 aftercsn 则可能漏掉导出窗口内的增量。这里有个细节源库查询 current_scn 和 expdp 的 flashback_scn 必须是同一个数字手抖写错一位结果就是重复数据或丢数据。5.3 初始化方式二sourceistable specialrun 一次性初载除了 expdpOGG 自带的初始化方式是 sourceistable 模式。这个模式不走日志Extract 直接扫表并生成 trail 文件适合数据量不大的场景。我另外搭的一套小环境演示过这个流程表是 TEST1.TEST1SCN 是 2497559。源端配置初载 ExtractGGSCI (test1) 1 add extract init_t1, sourceistable GGSCI (test1) 2 edit params init_t1 EXTRACT init_t1 USERID ogg,PASSWORD ogg RMTHOST 10.1.200.99, MGRPORT 7809 RMTFILE ./dirdat/i1, maxfiles 999, megabytes 500 TABLE TEST1.TEST1, SQLPREDICATE AS OF SCN 2497559;sourceistable是初载专用模式SQLPREDICATE AS OF SCN表示用闪回查询来读取指定 SCN 时刻的数据保证导出的是一致性快照。RMTFILE直接把数据写到目标端的 trail 文件不走 DataPump。目标端配置一次性 ReplicatGGSCI (localhost) 1 add replicat ri1, specialrun GGSCI (localhost) 2 edit params ri1 REPLICAT ri1 SPECIALRUN END RUNTIME USERID goldengate, PASSWORD oggpwd EXTFILE ./dirdat/i1 MAP TEST1.TEST1, TARGET TEST1.TEST1;SPECIALRUN表示这次运行结束后进程自动退出不占用常驻进程名额END RUNTIME是配套参数。执行方式是先启动源端 ExtractGGSCI (test1) 3 start extract init_t1然后在目标端命令行直接调 replicat 程序./replicat paramfile dirprm/ri1.prm初载完成后把正式 Replicat 也用 aftercsn 接上GGSCI (test2 as goldengatetest1) 20 start replicat rp1, aftercsn 2497559sourceistable 的好处是全程由 OGG 自己管理不需要 expdp/impdp 的额外操作适合表少、数据量小的场景但初载完成后要记得清理临时进程否则它会一直挂在进程列表里。5.4 增量验证insert、delete、truncate 三连测初始化完成后我用最粗暴的方式验证同步链路是否真的通了源端做三类典型操作目标端对比数据。源端插入一条数据SQL select count(*) from t1; COUNT(*) ---------- 86264 SQL select max(object_id) from t1; MAX(OBJECT_ID) -------------- 87365 SQL insert into t1 (object_id) values(87366); SQL commit;目标端查询SQL select max(object_id) from test.t1; MAX(OBJECT_ID) -------------- 87366插入同步成功。接着测删除SQL delete from t1 where object_id87366; SQL commit;目标端select max(object_id) from test.t1回到 87365删除链路正常。最后测 truncateSQL truncate table t1;目标端select count(*) from test.t1结果是 0。注意这里如果 Extract 和 Replicat 任何一个没配GETTRUNCATEStruncate 不会同步目标端表还是 86264 行。三连测都通过说明整条链路从日志抓取到网络投递再到目标端应用是通的。6. 日志定位与高频踩坑四类故障一次说清6.1 日志三件套怎么配合看OGG 出问题时我一般按顺序看三个文件根目录的ggserr.log、dirrpt下的 report 文件、以及各进程自己配置的 discard 文件。ggserr.log 记录所有进程的启动、停机和报错信息是排障第一站report 文件按天滚动记录每个进程的统计和执行细节discard 文件里是应用失败的具体 SQL 和数据行。一个典型场景Replicat 状态变成 ABENDED先开 ggserr.log 看 ORA- 错误再翻 dirrpt 下的 repgs1.rpt 看停在哪个事务最后去 repgs1.dsc 里看具体哪行数据应用失败。用这套顺序定位大部分问题十分钟内能锁定。6.2 四条高频故障现象、原因、解决现象原因解决Extract 启动后报 ORA-01031 权限不足状态 STOPPEDgoldengate 用户缺少 OGG 管理员权限漏执行 grant_admin_privilege补执行 dbms_goldengate_auth.grant_admin_privilege然后重启 Extractadd trandata 时报无主键无法添加表级附加日志目标表没有主键或唯一索引OGG 不知道拿什么做键建主键或执行 add trandata 时用 KEYS 子句指定列初始化后启动 Replicat 大量报 ORA-00001 主键冲突expdp 的 flashback_scn 和 start replicat aftercsn 用的不是同一个 SCN统一 SCN导出前查询后立刻记录启动时严格复用同一个值Replicat 应用时 ORA-00942 表不存在discard 里全是类似记录MAP 语句的 schema 名和目标端实际表名不一致OGG 区分大小写检查 MAP test.* TARGET test.* 的 schema 拼写必要时加双引号另外还有一条环境相关的经验Windows 上安装 OGG 时路径带空格或中文会导致 create subdirs 创建的目录层级错乱后续 edit params 经常报找不到文件安装时直接避开。从那以后我每次搭 OGG 环境都会强制走一遍同样的检查顺序先确认数据库层的归档、附加日志和 enable_goldengate_replication再配用户权限最后才碰进程参数所有进程 start 完后再统一 info all 看一眼状态确认没有 STOPPED 才继续下一步。这套习惯帮我少踩了很多坑希望帮到你。本文还有配套的精品资源点击获取