简介：面向 Oracle DBA 与数据同步实施人员的一份 OGG 部署实操文档，聚焦 Oracle GoldenGate 12.2 在 Windows 源库与 Linux 目标库之间的异构同步落地，从环境准备到进程配置形成完整链路。内容围绕源库开启归档、强制日志与附加日志，创建 goldengate 用户并用 dbms_goldengate_auth 授权，目标库补授 DML 权限，再到解压安装包、runInstaller 可视化安装、create subdirs 初始化、GLOBALS 与 checkpoint 表配置，以及 Manager、Extract、Replicat 三类组件的配置要点与日常监控、日志排查思路逐节展开，适合需要照单复现环境或定位同步异常的中级读者对照使用。压缩包内共 1 个文件，为 496KB 的 PDF，按安装、配置、组件、监控分节排版，便于逐节查阅与随查随用。目前已有 297 人学习。
1. 一次 Windows 到 Linux 的 Oracle OGG 同步，卡住的往往不是安装包
Oracle OGG 安装部署这件事，纸面上看很轻：解压一个 zip、以 oracle 用户跑一遍 runInstaller、建几个子目录、敲几条 add extract。可真到 Windows 源库同步到 Linux 目标库这种跨平台场景，翻车点几乎全在安装包之外——源库归档没开、附加日志只开了库级没加表级、Windows 那边 trail 路径写了反斜杠、两端 NLS_LANG 对不上导致中文变问号。我见过装完三天没跑通一行的环境，最后查出来是 force logging 忘了开。这套环境适合正在做异构库实时同步、跨操作系统迁移、报表库拉数的人；下面按我实际走一遍的顺序，从数据库端配置写到进程启动，中间该抄的命令、该改的参数、起不来先看哪儿，都摊开讲。
2. 数据库端先配到位：归档、强制日志、附加日志和 goldengate 用户
OGG 装不上是小事，装上了抽不出数据才是大事。源库这一侧的四个开关，顺序错了会互相打架：必须先切归档，再开 force logging，最后加 supplemental log，中间还要 switch logfile 让附加日志真正生效。目标库那边简单得多，不需要附加日志，但要多给三个 any table 权限，否则 replicat 一跑就报权限不足。这一章把两端该执行的 SQL 全部列出来，写完就能对照检查。
2.1 源库三件套：归档模式、force logging、supplemental log data
源库必须是归档模式，这是 OGG 抽取 redo 的前提，非归档库连 extract 都注册不上。改归档要在 mount 状态做，做完再 open，中间不要省步骤。接着开强制日志，保证任何操作（包括 nologging 的批量写入）都完整记进 redo，否则抽取端会漏数据且不报错——这种静默丢数据最难查。
-- 切归档：必须在 mount 状态执行 SQL> shutdown immediate; SQL> startup mount; SQL> alter database archivelog; SQL> alter database open; -- 强制记录日志，nologging 操作也会写 redo SQL> alter database force logging; -- 开启最小附加日志（库级） SQL> alter database add supplemental log data; -- 确认两个开关都是 YES SQL> select SUPPLEMENTAL_LOG_DATA_MIN, FORCE_LOGGING from v$database;查出来SUPPLEMENTAL_LOG_DATA_MIN是 YES、FORCE_LOGGING是 YES 才算过。如果 MIN 还是 NO，说明 add supplemental log data 没提交成功，重跑一次。附加日志加完不会立刻对所有会话生效，需要切一次日志：
SQL> alter system switch logfile;我一般会连切两次，确保当前在线日志组轮换一圈。这一步不做，后面add trandata加表级日志时会提示已启用但实际抽取端读不到补充字段，update 同步过去只有主键变了、其他列还是旧值，排查起来非常费时间。
提示：
force logging会增加 redo 生成量，日志空间紧张的环境提前算一下归档保留策略，别同步一开就把归档目录撑满。
2.2 goldengate 表空间、用户与 dbms_goldengate_auth 授权
OGG 需要一个独立 schema 存 checkpoint 表、DDL 历史表、marker 表。这个用户不要图省事直接用业务用户，后面 DDL 同步要跑好几个脚本，混在一起容易把业务对象的权限搞乱。表空间 300M 起步、自动扩展，小库够用很久。
-- 独立表空间，路径按实际数据文件目录改 SQL> create tablespace goldengate datafile '/u01/app/oracle/oradata/test1/ogg01.dbf' size 300m autoextend on; -- OGG 专用用户 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; -- 授予 OGG 管理员所需的一整套权限 SQL> exec dbms_goldengate_auth.grant_admin_privilege('GOLDENGATE');grant_admin_privilege这一句是重点，它一次性把 extract 需要的 v$ 视图、闪回、锁表等权限打包授予，比手工一条条 grant 靠谱。参数里写的是 schema 名，大小写不敏感但建议全大写保持一致。少了这句，extract 启动时会报无法访问必要的数据字典视图。
最后打开实例级开关：
SQL> alter system set enable_goldengate_replication = true scope=both;scope=both让参数同时写进内存和 spfile，重启不丢。RAC 环境要每个实例都确认一遍，别只在一台节点上设。
2.3 目标库的差异：不需要附加日志，但要多三个 any table 权限
目标库的配置能抄源库的大半，唯独附加日志可以省——目标端只负责 apply，不产生补充日志。但 replicat 要往业务表里 insert/update/delete，光有 connect、resource 不够，得显式给 DML 权限：
-- 目标端：表空间、用户、基础授权同源库 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'); -- 目标端额外需要：跨表 DML 权限 SQL> grant insert any table, update any table, delete any table to goldengate; SQL> alter system set enable_goldengate_replication = true scope=both;这三个any table权限看着吓人，实际是 replicat 按 MAP 语句写目标表所必需。有些环境出于安全考虑改成逐表授权，那就要在每次新增同步表时补 grant，我倾向于先用 any table 跑通，上线前再按最小权限收敛。
2.4 两端配置对照与执行顺序
跨平台场景最容易在“以为一样”的地方出错，下面这张表建议直接贴着执行：
| 配置项 | 源库（Windows 侧） | 目标库（Linux 侧） |
|---|---|---|
| 归档模式 | 必须开启 | 不要求 |
| force logging | 必须开启 | 不要求 |
| 库级附加日志 | 必须开启 | 不要求 |
| goldengate 用户 | 需要 | 需要 |
| dbms_goldengate_auth | 需要 | 需要 |
| any table DML 权限 | 不需要 | 需要 |
| enable_goldengate_replication | true | true |
| 表级 trandata | 需要 | 不需要 |
顺序上不要颠倒：先切归档，再 force logging，然后附加日志，最后建用户。反过来的话，建完用户再改归档，中间这段时间的 redo 缺补充信息，初始化时用 SCN 一卡就会漏数据。
3. OGG 12.2.0.2 介质落地：Linux 端 runInstaller 与 Windows 端的区别
这次统一用 12.2.0.2 版本，两端主版本必须一致，小版本也建议对齐——跨版本投递 trail 文件格式不一定兼容，源端 12.2 投给目标端 11.2 的 replicat，十有八九读不了。Linux 侧用官方 zip 包加图形化 runInstaller，Windows 侧则是另一套安装介质，装法不同但目录结构和 GGSCI 命令一模一样。这一章从解压讲到 create subdirs，再到 GLOBALS、checkpoint 表和 MGR 进程，装完这一套，两边才算具备“能起进程”的条件。
3.1 解压与目录规划：Linux 用 zip 包，Windows 用 exe 介质
Linux 端我习惯把介质放/soft，解压到临时目录再安装到/u01/app/ogg，别直接装在解压出来的 Disk1 下面，那目录结构是安装器用的，不是运行目录。
# 切到 oracle 用户，安装和运行都用它 su - oracle cd /soft unzip 122022_fbo_ggs_Linux_x64_shiphome.zip # 进入安装器目录 cd fbo_ggs_Linux_x64_shiphome/Disk1 ls # 目录下应该有 runInstaller 和 response 目录解压完确认runInstaller有执行权限，没有就chmod +x runInstaller。安装目录提前建好并归 oracle 所有：
mkdir -p /u01/app/ogg chown -R oracle:oinstall /u01/app/ogg chmod 775 /u01/app/oggWindows 端用的是 Windows 版 OGG 安装介质，双击后走的是安装向导，默认目录类似D:\ogg，路径里不要有空格和中文，这是血泪经验——带空格的路径在参数文件里写起来要加引号，稍不留神就被解析成两个参数。两端装完的目录结构是一致的：dirprm放参数、dirrpt放报告、dirdat放 trail、dirchk放检查点、dirdef放定义文件。
3.2 以 oracle 用户跑 runInstaller：数据库版本选项别选错
图形界面能不能起来取决于 X11 转发或本机桌面。纯命令行服务器上常见做法是先设 DISPLAY，或者用静默安装的 response 文件。我这里按可视化安装走：
# 确认 DISPLAY 可用，否则安装器起不来 echo $DISPLAY # 执行安装器 cd /u01/app/ogg # 先切到目标父目录所在位置 cd /soft/fbo_ggs_Linux_x64_shiphome/Disk1 ./runInstaller界面里第一个关键选择是数据库版本，下拉里会列 Oracle 11g、12c 等选项。这个要选成和实际数据库一致的那个，选错了装出来的二进制连不上库，报的错还特别含糊。第二处是安装目录，填/u01/app/ogg。装完不要急着启动 GGSCI，先在两端各确认一次版本：
cd /u01/app/ogg ./ggsci进入后能看到Oracle GoldenGate Command Interpreter for Oracle和Version 12.2.0.2.2字样，说明二进制可用。Windows 端在 cmd 里进到安装目录执行ggsci.exe，输出格式一样，只是提示符变成GGSCI (hostname) 1>。
3.3 create subdirs：一次把运行目录补齐
两端进入 GGSCI 后第一件事都是建子目录。这一步不做，后面启动 MGR 会因为找不到 dirrpt、dirchk 直接退出。
GGSCI (test1) 1> create subdirs正常情况下会打印一串Creating subdirectories under current directory /u01/app/ogg，然后逐个列出 dirprm、dirrpt、dirchk、dirpcs、dirsql、dirdef、dirdat、dirtmp、dircrd、dirwlt、dirdmp。看到already exists不用管，说明之前建过，重复执行安全。
注意：源码机器上如果换过安装目录，旧的 dirprm 里可能残留老参数文件，迁移时把整个 ogg 目录打包带走之前，先清掉 dirrpt 和 dirdat 里的历史文件，否则新环境的报告会混着旧记录看。
3.4 GLOBALS、checkpoint 表：两端都要做，一个都不能少
GLOBALS 是全局参数文件，位置固定在 OGG 根目录下，文件名就叫GLOBALS，大小写敏感。里面三行就够用：
GGSCI (test1) 2> edit params ./GLOBALS内容写成：
GGSCHEMA goldengate CHECKPOINTTABLE goldengate.ggschkpt SYSLOG NONE三行的作用分别是：GGSCHEMA告诉 OGG 用哪个 schema 存 DDL 同步相关的对象；CHECKPOINTTABLE指定检查点表全名，replicat 断点续传全靠它；SYSLOG NONE关掉往系统日志写消息，避免 Linux 上 messages 被刷屏。Windows 端同理，路径前的./表示当前 OGG 目录，别写成绝对路径。
接着登录数据库并生成检查点表：
GGSCI (test1) 4> dblogin userid goldengate password goldengate Successfully logged into database. GGSCI (test1 as goldengate@test1) 6> add CHECKPOINTTABLE goldengate.ggschkpt Successfully created checkpoint table goldengate.ggschkpt.dblogin成功会明确回一句 logged into database，如果卡住或者报错，先查监听、再查密码里有没有特殊字符。add CHECKPOINTTABLE实际是在库里建一张带固定结构的表，两端都要建，且表名要和 GLOBALS 里写的一致，写错了 replicat 启动时会说自己找不到检查点。
3.5 MGR 参数逐行拆解：端口、自动重启、清理策略
MGR 是管理进程，所有 extract、replicat 都由它拉起，所以它先起、也必须最可靠。参数文件这样写：
GGSCI (test1 as goldengate@test1) 7> edit params mgrPORT 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 7809是 MGR 监听端口，两端防火墙要放通，Windows 端还要在入站规则里加例外；DYNAMICPORTLIST给投递进程动态分配端口，范围别和业务端口撞；USERID/PASSWORD让 MGR 能替子进程做数据库认证；AUTORESTART是关键一行，进程异常退出后 5 分钟重试、最多 3 次、60 分钟重置计数，没有它半夜挂了就真挂了；LAGREPORTMINUTES与LAGCRITICALMINUTES决定延迟报告的频率和告警阈值；PURGEOLDEXTRACTS按检查点清理已投递完的 trail，MINKEEPHOURS 12保留 12 小时，留出排查窗口；两条PURGE*HISTORY控制 DDL 历史和 marker 表的保留天数。
启动并确认：
GGSCI (test1 as goldengate@test1) 8> start mgr Manager started. GGSCI (test1 as goldengate@test1) 9> info mgrinfo mgr会显示端口、PID、运行状态。两端都起完之后，从源端机器上 telnet 一下目标端的 7809，通不通决定后面 datapump 能不能投递——这一步我省过，结果在 RMTHOST 上耗了一下午。
4. 抽取、投递、复制三条链路：extract、datapump、replicat 参数怎么落地
OGG 的数据流是三段式：源端 extract 读 redo 写本地 trail，datapump 把本地 trail 投到目标端，目标端 replicat 读 trail 写库。三个进程的参数文件各管一段，出问题时先定位是哪一段断了，比盲目改参数快得多。这一章按数据流顺序写参数，重点标出跨平台场景必须改的几处：SETENV 里的路径、RMTHOST 的地址、trail 名两端要对得上。
4.1 源端 DDL 支持：四个脚本和表级 trandata
要同步 DDL（建表、加列这类），源端得先跑官方脚本，并且给执行脚本的用户赋权。这些脚本都在 OGG 安装目录下：
SQL> conn / as sysdba SQL> grant execute on utl_file to goldengate; SQL> @/u01/app/ogg/marker_setup SQL> @/u01/app/ogg/ddl_setup SQL> @/u01/app/ogg/role_setup SQL> GRANT GGS_GGSUSER_ROLE TO goldengate; SQL> @/u01/app/ogg/ddl_enable四个脚本的分工：marker_setup 建 marker 表，用来标记 DDL 发生的位置；ddl_setup 建 DDL 历史表并装触发器；role_setup 建角色；ddl_enable 打开 DDL 捕获开关。跑的顺序不能乱，marker 没建就跑 ddl_setup 会报对象不存在。最后那条 GRANT 里的用户名要和 GLOBALS 里的 GGSCHEMA 对上。
然后加表级附加日志，只对有主键或唯一索引的表执行：
GGSCI (test1) 3> dblogin userid goldengate password goldengate GGSCI (test1 as goldengate@test1) 13> add trandata test.t1回显里出现Logging of supplemental redo data enabled才算成功。表上没有主键时命令会失败，常见做法是显式指定一组列当逻辑主键：
GGSCI (test1 as goldengate@test1) 14> add trandata test.t1, keys(object_id)这组列的作用是过滤重复数据、定位 update 的目标行，选错了会出现“更新了但目标端没变”或者“一行变多行”。生产上我不太接受无主键表进同步范围，宁可让业务加唯一索引。
4.2 Extract 参数：SETENV 与 trail 配置是跨平台重灾区
Extract 跑在源端，读 redo、写本地 trail。参数文件我按这个模板来：
GGSCI (test1) 1> edit param extgsxfEXTRACT extgsxf 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 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 AT 0:01 FETCHOPTIONS MISSINGROW ABEND STATOPTIONS REPORT WARNLONGTRANS 1H,CHECKINTERVAL 10m DYNAMICRESOLUTION TABLE test.*;关键几行：三个SETENV决定进程能不能连上库，Windows 源端这里要写成SETENV (ORACLE_HOME="C:\\app\\oracle\\product\\11.2.0\\dbhome_1")这种双反斜杠形式，或者干脆用正斜杠，OGG 两种都认；EXTTRAIL ./dirdat/gs定义本地队列，两字母后缀 gs 要和后面 datapump、replicat 引用的完全一致；TRANLOGOPTIONS LOGRETENTION DISABLED表示不接管日志保留，归档由 DBA 自己管，生产上更安全；BR ,BRINTERVAL 20M是 Bounded Recovery 的检查间隔，长事务多的库把它调小能减少重启恢复时间；CACHEMGR CACHESIZE 2GB给大事务留内存；GETTRUNCATES让 truncate 也能同步过去；WARNLONGTRANS 1H超过一小时的事务会在报告里告警，避免长事务把 trail 撑爆；DYNAMICRESOLUTION减少启动时的内存占用，表多的时候很实用。
注册并绑定队列：
GGSCI (test1) 2> add extract extgsxf tranlog, begin now EXTRACT added. GGSCI (test1) 3> add exttrail ./dirdat/gs, extract extgsxf, megabytes 1024begin now表示从现在开始抽，megabytes 1024是单个 trail 文件滚动的阈值，写满就换下一个文件。启动后info extgsxf能看到 status 是 Running，stats extgsxf能看到已抽事务数。
4.3 DataPump：RMTHOST 写对，投递才通
投递进程本身不读 redo，只负责搬文件，参数比 extract 短很多：
GGSCI (test1 as goldengate@test1) 60> edit param dpgskfEXTRACT 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是投递进程的标志性参数，表示不解析数据、原样转发，省 CPU；RMTHOST写目标端 IP 和 MGR 端口，注意这里是逗号分隔的两个值，端口写错会报连接超时，而错误信息指向的是 MGR，很容易误判成目标端没起；RMTTRAIL是写到对端的位置，名字与源端本地 trail 一致即可，但要在目标端的 dirprm 里能找到对应引用。
GGSCI (test1 as goldengate@test1) 61> add extract dpgskf, exttrailsource ./dirdat/gs GGSCI (test1 as goldengate@test1) 62> add RMTTRAIL ./dirdat/gs, extract dpgskf, megabytes 1024 GGSCI (test1 as goldengate@test1) 63> start dpgskf第一步把投递进程绑到本地 trail 上，第二步声明远端队列。两条都成功才说明链路定义完整，少一条启动时会提示 extract 不存在。
4.4 Replicat：ASSUMETARGETDEFS 与抑制触发器
目标端 replicat 是唯一往库里写数据的进程，参数错一行就可能写坏数据：
GGSCI (test2 as goldengate@test1) 13> edit param repgs1REPLICAT 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 AT 0:01 STATOPTIONS RESETREPORTSTATS NUMFILES 150 GETTRUNCATES DYNAMICRESOLUTION ALLOWNOOPUPDATES GROUPTRANSOPS 1000 MAP test.* , TARGET test.*;重点解释几个：ASSUMETARGETDEFS表示两端表结构完全一致、不做定义文件比对，跨平台同构迁移用它是标准做法，但如果两边列顺序或类型有差异就得改用SOURCEDEFS；DBOPTIONS DEFERREFCONST把外键约束检查推迟到事务提交，避免子表先写导致约束报错；SUPPRESSTRIGGERS抑制目标端触发器，防止同步写入再触发业务逻辑形成二次写入；REPERROR (DEFAULT, ABEND)任何错误都让进程停下，宁可停也不脏写；GROUPTRANSOPS 1000每 1000 个事务合并提交一次，明显提升 apply 性能；ALLOWNOOPUPDATES允许“值没变的更新”通过，源端业务有空更新时不会卡住；NUMFILES 150控制同时打开的 trail 文件数。
注册复制进程：
GGSCI (test2 as goldengate@test1) 14> add replicat repgs1, exttrail ./dirdat/gs, checkpointtable goldengate.ggschkptcheckpointtable一定要写全schema.table，和 GLOBALS 保持一致。
4.5 初始化数据：expdp 加 flashback_scn，aftercsn 对齐
存量数据不通过 OGG 抽，先用数据泵倒过去，关键是两边 SCN 要对上。先在源端取当前 SCN：
SQL> select to_char(current_scn) from v$database;假设备份点是 1085057，导出时用 flashback_scn 固定一致性点：
expdp test/test TABLES=test.t1 DUMPFILE=t1.dmp flashback_scn=1085057dump 文件拷到目标端导入：
impdp test/test dumpfile=t1.dmp然后启动 replicat 并指定从这个 SCN 之后开始应用，重复数据就不会被再写一遍：
GGSCI (test2 as goldengate@test1) 20> start replicat repgs1, aftercsn 1085057aftercsn用在 replicat 启动时只此一次，之后断点由 checkpoint 表接管。另一种做法是用sourceistable类型的初始化抽取进程直接从源库读表投到目标端，参数里带SQLPREDICATE 'AS OF SCN xxxx'，适合不能停业务、也拿不到导出窗口的场景，代价是要多维护一套 specialrun 参数。两种方式选一种即可，不要混用，混用必然出现主键冲突。
5. 排查与避坑：进程起不来、数据不动时按这个顺序看
OGG 的报错有个特点：真正的原因往往在第一条错误里，后面几十行都是连锁反应。我排查固定从 ggserr.log 的最后一次进程启动记录看起，再看对应进程的 dirrpt 报告，最后才去翻 discard 文件。下面五条是这套跨平台环境里我实际踩过的，每条按现象、原因、解决写，遇到同类问题可以直接对照。
5.1 现象：MGR 启动即退出，info mgr 显示 stopped
原因通常有两个：端口被占，或者 dirrpt 目录不存在。端口冲突在多实例共存机器上很常见，7809 被别的服务先占了；目录问题则是没跑 create subdirs 就急着 start mgr。
解决：先用netstat -anp | grep 7809确认占用，改 MGR 参数里的 PORT，同时把 DYNAMICPORTLIST 换成没冲突的段；目录问题直接进 GGSCI 执行create subdirs，再start mgr。改完端口后，源端 datapump 的 RMTHOST 端口要同步改，否则链接路都建不起来。
5.2 现象：extract 启动报找不到 trail 或无法打开队列文件
原因多半是路径写法不对。Windows 源端参数文件里写了./dirdat/gs但安装目录和当前工作目录不一致，或者手工写成了D:\ogg\dirdat\gs带盘符的绝对路径，OGG 解析时把冒号当成参数分隔符。
解决：统一用相对路径./dirdat/xxx，并确保执行 GGSCI 时当前目录就是 OGG 安装根目录。Windows 上从“服务”方式启动和从 cmd 启动，工作目录可能不同，这是最容易忽略的一点。实在要用绝对路径，路径里不要有空格，反斜杠改成正斜杠。
5.3 现象：insert 同步正常，update 过去后目标端数据没变
原因是表级附加日志没加，或者加了但没切日志生效。extract 能读到 insert 的完整行，但 update 只有主键信息，其他列拼不出来。
解决：源端重新执行add trandata schema.table，看到 enabled 提示后alter system switch logfile切一次，再重启 extract。已经有存量同步的表，加完 trandata 后建议重新做一次全量初始化，否则中间这段的 update 会永久缺失。
5.4 现象：replicat 报列不匹配或数据类型转换失败后 ABEND
原因是两端表结构不完全一致，而参数里用了ASSUMETARGETDEFS。跨平台迁移时目标端手工建表少一列、或者 varchar2 长度改过，都会触发。
解决：临时把REPERROR (DEFAULT, ABEND)改成REPERROR (DEFAULT, DISCARD)让进程先跑起来，把出错的行落到 discard 文件，人工核对差异；根治办法是两端对齐表结构后重建 replicat 检查点并重做初始化。别长期挂着 DISCARD 跑，丢弃的行不会自己回来。
5.5 现象：中文数据同步到目标端变成问号
原因是两端字符集或 NLS_LANG 不一致。源库 Windows 上常见 ZHS16GBK，目标库 Linux 上是 AL32UTF8，参数文件里又都写着 AL32UTF8，看起来一致实际源端环境变量把会话字符集带偏了。
解决：源端 extract 的SETENV (NLS_LANG=...)按源库真实字符集写，目标端 replicat 按目标库写，中间由 OGG 自己做转换。查源库真实字符集用select value from nls_database_parameters where parameter='NLS_CHARACTERSET'。改完参数必须重启进程，热改不生效。
5.6 出错先看这三个文件
ggserr.log是总账，所有进程启停和错误都记在这里，按时间戳找最后一次启动；dirrpt/<进程名>.rpt是每个进程的详细报告，里面有读到哪张表、哪个事务出错；dirrpt/<进程名>.dsc是 discard 文件，只有在配了 DISCARD 策略时才有内容，里面是完整的失败记录。三个文件按这个顺序看，八成问题能定位。
6. 装完怎么验证跑通：三个动作加一条我必做的检查
装完不验证等于没装。我验收这套环境只做三件事：插一条、删一条、truncate 一次，再看一眼进程状态和延迟。这三步覆盖了 insert、delete、truncate 三种最容易出问题的操作类型，比跑一百行查询管用。
先看基线。源端和目标端各查一次：
SQL> select count(*), max(object_id) from test.t1;两边数字一致才继续。然后源端插入：
SQL> insert into test.t1 (object_id) values (87366); SQL> commit;提交后切一次日志推动 extract，等几秒到目标端查select max(object_id) from test.t1，能看到 87366 就是通了。接着删掉这一行，两边再核对一次，确认 delete 也过了。最后 truncate：
SQL> truncate table test.t1;目标端select count(*)应该变成 0。这一步失败通常是因为 replicat 参数里少了GETTRUNCATES，补上重启即可。
光看数据还不够，进程状态要一起看：
GGSCI> info all输出里 extract、datapump、replicat 三行状态都应是 RUNNING，lag at chkpt 应该在秒级。如果某一列延迟持续增长，基本可以确定是对应那一段卡住了：extract 卡住查源库归档空间和长事务，datapump 卡住查网络和目标端 MGR 端口，replicat 卡住查目标库锁等待。
我自己的检查清单是这样的：
| 检查点 | 命令 | 期望结果 |
|---|---|---|
| 进程状态 | info all | 三个进程 RUNNING |
| 抽取统计 | stats extgsxf | 事务数持续增长 |
| 复制统计 | stats repgs1 | 无 discard、无 retry |
| 延迟 | info <进程名> | lag 在秒级 |
| 错误日志 | tail -f ggserr.log | 无 ERROR 行 |
| 数据比对 | 两端 count + max 主键 | 完全一致 |
有一件事我每次都会做：故意在目标端把 replicat 停掉，源端继续写十条，再启动 replicat，看这十条能不能自动追平。这个动作验证的是 checkpoint 表到底有没有在工作——很多环境一路跑得好好的，真到需要断点续传的时候才发现检查点没写进去，只能重做全量。
从那以后我每次部署完 OGG，不管多晚都要走一遍“停进程、写数据、起进程、对账”这套流程，宁可多花二十分钟，也不想在业务切换当晚才发现断点续传是坏的。这套 12.2.0.2 的环境我在几个跨平台同步场景里反复用过，按上面的顺序配下来基本不会返工，希望帮到你。
本文还有配套的精品资源，点击获取
