OGG 12.2 跨平台 Oracle 数据同步部署与排错

简介《Oracle OGG安装部署细说Windows同步到Linux》是一份面向Oracle DBA、数据同步实施人员及异构环境运维者的PDF技术文档聚焦Windows端Oracle到Linux端Oracle的GoldenGate实时复制部署。内容围绕源库与目标库准备、归档与强制日志及附加日志开启、OGG专用用户与权限授予、enable_goldengate_replication参数设置、ggsci子目录初始化、GLOBALS与checkpoint表配置以及Manager、Extractor、Replicat组件配置和后续监控维护、日志排查展开附有可直接参考的SQL与命令片段。压缩包仅含1个PDF文件大小约496KB便于随身查阅和按步骤对照实施。目前已有298人学习适合需要快速搭建OGG同步链路、梳理跨操作系统部署要点或查漏补缺的初中级读者。1. 跨平台同步先想清楚三件事OGG 12.2 的适用边界上周有位同行问我Windows 上的业务库要并到 Linux 那套新环境两边得同时写一段时间问有没有比写触发器更靠谱的做法。这种 oracle linux OGG 数据同步的场景GoldenGate 基本是绕不开的选项——它从源库的在线 redo 或归档里抓变更落成自己的 trail 文件再投递到目标端重放中间不碰源库的业务表源端压力可控目标端还能做字段映射和冲突策略。这次拆的是一份 OGG 12.2.0.2 的部署记录源头是 Windows 上的 Oracle目标端是 Linux 上的 Oracle跨操作系统、跨字符集链路里该踩的坑一个不少。适合手上正要做异构迁移、双写过渡或者报表库准实时同步的人尤其是第一次从零配 Extract / DataPump / Replicat 三进程的。下面按数据库前置条件、安装初始化、三进程配置、初始化数据对齐、排错的顺序把这条链路完整走一遍。2. 数据库侧前置条件归档、强制日志与附加日志的四个开关OGG 能不能跑起来一半取决于数据库这边开没开对。很多进程起不来的问题根子不在 OGG 参数而在源库压根没记全所需的信息。这一章把源库和目标库要改的东西一次列清顺序也别乱先开归档再谈附加日志。2.1 源库三个开关的顺序与验证源库必须处于归档模式Extract 读的是在线 redo归档是它的兜底。如果 Extract 停了一段时间再启动需要回头去读归档库不在归档模式就只能重新做初始化。切换归档要重启到 mount 状态-- 以 sysdba 身份连接源库 SQL shutdown immediate; SQL startup mount; SQL alter database archivelog; SQL alter database open; -- 强制记录日志保证即使表上开了 nologging变更也会写 redo SQL alter database force logging; -- 开启最小附加日志让 redo 里带上足够定位行的信息 SQL alter database add supplemental log data; -- 验证三个开关的实际状态 SQL select SUPPLEMENTAL_LOG_DATA_MIN, FORCE_LOGGING, LOG_MODE from v$database;逻辑说明force logging是必须的业务方偶尔为了赶批量会临时改成 nologging一旦发生这部分变更在 redo 里就是残缺的Replicat 端会出现行对不上。add supplemental log data打开的是库级最小附加日志配合后面表级的add trandata才能真正把主键或唯一索引的前镜像写进去。参数说明SUPPLEMENTAL_LOG_DATA_MIN期望值是YES如果显示IMPLICIT说明只开了最小集合需要再确认表级 trandata 是否加过。执行完这三个开关后建议手动切一次日志让配置立即生效不用等自然切换SQL alter system switch logfile;这一步别省。有次我在测试库上开完附加日志就去加 trandata结果报找不到补充日志信息切了一次日志就正常了属于典型的配置生效滞后。2.2 OGG 账号表空间、系统权限与 dbms_goldengate_authOGG 需要一个独立的数据库账号源端和目标端都要建且权限不完全一样。别图省事用 sys 或 systemcheckpoint 表和 trail 元数据都会写进这个账号下混用之后清理起来很麻烦。-- 建独立表空间300M 起步自动扩展 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; -- 允许闪回查询日志信息不足时用 as of scn 补查 SQL grant flashback any table to goldengate; -- 关键一步授予 OGG 管理员所需的一套内部权限 SQL exec dbms_goldengate_auth.grant_admin_privilege(GOLDENGATE); -- 打开 OGG 复制开关12c 之后必须显式开启 SQL alter system set enable_goldengate_replication true scopeboth;逻辑说明dbms_goldengate_auth.grant_admin_privilege这个包会一次性授予 OGG 需要的几十个内部权限包括读 redo、管队列、操作 checkpoint 表等。手工一条条 grant 极容易漏漏了之后的报错往往很含糊比如ORA-26903或者进程启动即 ABEND。我一般习惯把它当成建号的标准动作跟create user连着写。参数说明第二个参数可以传*表示对所有 schema 生效也可以只传具体用户名。传具体用户名更安全避免 OGG 账号有能力去碰不该碰的库。enable_goldengate_replication是实例级参数scopeboth保证重启后依然有效别只写memory。2.3 目标库少开什么、多开什么目标库是接收端不需要从自己的 redo 里抽数据所以归档和附加日志都可以不开除非目标端还要往下游再同步一层。但账号权限要补两块一是前面那套建号流程一模一样走一遍二是额外给 DML 权限。-- 目标库建号部分与源库一致此处略过补充 DML 授权 SQL grant insert any table, update any table, delete any table to goldengate; -- 目标库同样要打开复制开关 SQL alter system set enable_goldengate_replication true scopeboth;逻辑说明Replicat 是以 OGG 账号身份往目标表里写数据的如果只给了 connect/resource遇到跨 schema 的MAP test.*, TARGET test.*就会报权限不足。用insert any table这类系统权限是为了省掉逐表授权的活如果安全策略不允许也可以改成对象级授权但表一多就很痛我一般倾向于前者。目标库还有个容易忽略的点checkpoint 表要单独建在目标库里不能跟源库共用。源端和目标端的 checkpoint 表结构相同、数据独立各自记录自己进程的读写位置。两边都执行add checkpointtable goldengate.ggschkpt即可这个动作放在下一章的 GGSCI 初始化里做更顺手。3. OGG 安装与两端初始化Windows 与 Linux 的差异点安装本身不复杂麻烦的是两端目录结构、环境变量、服务注册方式都不一样。这一章先把安装落盘讲清楚再把create subdirs、GLOBALS、checkpoint 表、MGR 参数这几步做完做完之后两端应该都能start mgr成功。3.1 安装包与 runInstaller 的落盘路径Linux 端的安装包是122022_fbo_ggs_Linux_x64_shiphome.zip用 oracle 用户解压后进入fbo_ggs_Linux_x64_shiphome/Disk1执行runInstaller图形界面里选择与源库匹配的数据库版本安装路径我一般固定成/u01/app/ogg跟 Oracle 的 ORACLE_BASE 分开备份和清理都方便。# 切到 oracle 用户再操作别用 root 解压 su - oracle unzip 122022_fbo_ggs_Linux_x64_shiphome.zip cd fbo_ggs_Linux_x64_shiphome/Disk1 export DISPLAY10.0.100.21:0.0 # 图形化安装需要 ./runInstaller逻辑说明runInstaller是 Java 写的图形安装器没有 X 转发会直接报错退出。如果服务器不给开图形也可以选静默安装用 response file但 12.2 的 response 模板生成比较绕第一次部署时用图形界面确认一遍路径和组件更稳妥。参数说明安装路径里不要带空格和中文Windows 端同理。Windows 端的包是fbo_ggs_Windows_x64_shiphome.zip解压后跑setup.exe装到C:\ogg。装完两端都要确认ggsci能起来这是后面所有命令的入口。3.2 create subdirs 与 GLOBALS 的三个参数安装完第一件事是建子目录它会把 dirprm、dirrpt、dirdat、dirchk 这些工作目录一次建好源端目标端都要做。[oracletest1 ogg]$ ./ggsci Oracle GoldenGate Command Interpreter for Oracle Version 12.2.0.2.2 OGGCORE_12.2.0.2.0_PLATFORMS_170630.0419_FBO Linux, x64, 64bit (optimized), Oracle 11g on Jun 30 2017 14:42:26 GGSCI (test1) 1 create subdirs接着配全局参数文件。GLOBALS 是个无扩展名的纯文本文件放在 OGG 安装根目录下源端目标端内容一致GGSCI (test1) 2 edit params ./GLOBALS GGSCHEMA goldengate CHECKPOINTTABLE goldengate.ggschkpt SYSLOG NONE逻辑说明GGSCHEMA告诉 OGG 用哪个 schema 存内部对象CHECKPOINTTABLE指定 checkpoint 表的全名写上这两个之后后面建进程时就不需要反复指定 checkpoint 表。SYSLOG NONE是关掉往系统日志写消息Linux 上如果不关/var/log/messages会被 OGG 刷得很难看。参数说明文件名必须叫GLOBALS大写没有后缀放在 OGG 根目录。改了之后要重启 MGR 才生效。Windows 端路径是C:\ogg\GLOBALS用记事本存成 ANSI 或 UTF-8 无 BOM 都行带 BOM 会解析失败。3.3 checkpoint 表与 MGR 进程参数逐行拆解先登录数据库再建 checkpoint 表两端都做GGSCI (test1) 3 dblogin userid goldengate password goldengate Successfully logged into database. GGSCI (test1 as goldengatetest1) 4 add checkpointtable goldengate.ggschkpt Successfully created checkpoint table goldengate.ggschkpt.MGR 是管理进程负责启动、监控、自动重启其他进程也是 DataPump 投递的目标端口。参数文件长这样GGSCI (test1) 5 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是 MGR 的固定监听端口DYNAMICPORTLIST是给 DataPump 动态分配的端口范围。中间是自愈配置AUTORESTART ER *表示任何进程异常退出都自动拉起最多重试 3 次每次间隔 5 分钟60 分钟后计数清零。后面三行是清理策略trail 文件、DDL 历史、marker 历史分别按小时和天保留USECHECKPOINTS保证只删已经确认消费完的文件。参数说明MINKEEPHOURS 12是我习惯留的缓冲给排错留出回看窗口如果磁盘紧张可以压到 4 小时。LAGCRITICALMINUTES 10会往 ggserr.log 里写严重延迟告警配合监控抓取很方便。密码明文写在参数文件里不符合安全审计要求正式环境建议改用credentialstore加别名这里为了步骤清晰先保持明文。GGSCI (test1 as goldengatetest1) 6 start mgr Manager started.两端都start mgr成功后info mgr应该能看到运行状态和端口。到这一步两端的基础骨架就搭好了接下来才是真正配链路。4. 三进程链路与初始化数据Extract、DataPump、Replicat 怎么串起来OGG 的链路是三个进程接力源端 Extract 读 redo 写本地 trail源端 DataPump 读本地 trail 投递到目标端目标端 Replicat 读远程 trail 重放到目标表。三者职责不同参数侧重点也不同配错任何一环数据就断在半路。4.1 源端 Extract从在线 redo 里抓变更先加表级附加日志再建 Extract。表级 trandata 是必须的只有库级最小附加日志不够Replicat 定位不到具体行。GGSCI (test1) 7 dblogin userid goldengate password goldengate GGSCI (test1 as goldengatetest1) 8 add trandata test.t1Extract 参数文件GGSCI (test1) 9 edit params 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 WARNLONGTRANS 1H, CHECKINTERVAL 10m DYNAMICRESOLUTION TABLE test.*;逻辑说明SETENV三行是给 Extract 进程本身指定运行环境跨平台场景下这三个值尤其关键NLS_LANG必须跟源库字符集匹配否则中文表名和字段会在 trail 里变成乱码。TRANLOGOPTIONS LOGRETENTION DISABLED表示不用 OGG 自己的日志保留机制依赖数据库的归档保留策略配合BR BRINTERVAL 20M做 Bounded Recovery进程异常时的恢复粒度控制在 20 分钟内。GETREPLICATES和GETTRUNCATES分别捕获复制语句和 truncate 操作后者不打开的话目标端会静默丢 DDL 级的清表。DDLOPTIONS ADDTRANDATA让 OGG 在遇到新表时自动加 trandata省掉人工补。参数说明WARNLONGTRANS 1H是长事务告警阈值超过 1 小时未提交的事务会往日志里写警告同时CHECKINTERVAL 10m每 10 分钟检查一次。长事务是 trail 膨胀的头号原因尤其 Windows 端那种批量 job一定要盯着。FETCHOPTIONS MISSINGROW ABEND表示如果重放时找不到对应行直接终止进程而不是继续宁可停下来让人看也不要带着不一致往下跑。GGSCI (test1) 10 add extract extgsxf tranlog, begin now EXTRACT added. GGSCI (test1) 11 add exttrail ./dirdat/gs, extract extgsxf, megabytes 1024 EXTTRAIL added. GGSCI (test1) 12 start extgsxfbegin now表示从现在的位置开始抓如果要做历史数据同步这里要改成具体 SCN 或用sourceistable方式第 4.5 节会讲。4.2 DataPump跨平台投递与 RMTHOST 的写法DataPump 跑在源端把本地 trail 通过网络推到目标端的 MGR 端口。它是最容易被忽略的一环因为它不出现在数据抽取和重放的逻辑里但链路断了往往最先断在这。GGSCI (test1) 13 edit params 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 不做任何过滤和转换原样转发。加了这个之后TABLE test.*只是个声明实际投递内容不受影响。RMTHOST写目标端 IP 和 MGR 端口注意这里是 MGR 的固定端口 7809不是前面配的 DYNAMICPORTLISTMGR 收到连接后会分配动态端口给实际的数据流。RMTTRAIL是目标端落盘的 trail 路径写相对路径即可OGG 会解析到目标端的安装目录下。参数说明跨平台投递时目标端防火墙要放通 7809 以及 7800-7810 这一段。有次在客户现场调了半小时最后发现是安全组只开了 7809动态端口被封表现是 DataPump 状态RUNNING但目标端一直收不到文件属于很典型的黑匣子式故障。GGSCI (test1) 14 add extract dpgskf, exttrailsource ./dirdat/gs EXTRACT added. GGSCI (test1) 15 add rmttrail ./dirdat/gs, extract dpgskf, megabytes 1024 RMTTRAIL added. GGSCI (test1) 16 start dpgskf4.3 目标端 Replicat冲突处理与批量提交Replicat 在 Linux 端跑读投递过来的 trail按 MAP 规则写进目标表。参数里最需要琢磨的是冲突处理和提交粒度。GGSCI (test2) 17 edit params repgs1 REPLICAT repgs1 SETENV (ORACLE_HOME /u01/app/oracle/product/11.2.0/db_1) SETENV (ORACLE_SID test2) 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表示源端和目标端表结构一致不需要额外的定义文件跨平台但同构的场景用这个最省事。DBOPTIONS DEFERREFCONST把外键约束检查推迟到事务提交时避免因为重放顺序导致约束冲突。DBOPTIONS SUPPRESSTRIGGERS让重放过程中不触发目标表上的触发器防止业务触发器在同步链路上二次写数据这一点如果漏配很容易造成目标端数据翻倍。GROUPTRANSOPS 1000把 1000 个源事务合并成一个目标事务提交是提升重放吞吐最直接的手段。参数说明REPERROR (DEFAULT, ABEND)表示遇到任何错误都终止进程不做跳过。生产环境里也有人配成DISCARD把错误行丢掉继续跑但那等于让数据悄悄不一致除非明确知道某些行可以放弃否则不建议。ALLOWNOOPUPDATES处理源端更新了非关键列但目标端没有对应列的情况避免报错。GGSCI (test2) 18 add replicat repgs1, exttrail ./dirdat/gs, checkpointtable goldengate.ggschkpt REPLICAT added.注意这里先不要start等初始化数据做完再按 SCN 启动否则会跟导入的数据打架。4.4 DDL 同步的四个脚本与表级 trandata如果需要同步 DDL建表、加列、索引变更源端要额外跑几个脚本这一步在只做 DML 同步时可以省略但跨平台迁移阶段基本都会遇到。-- 源端以 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 -- 可选把 DDL 相关包 pin 到共享池减少重装带来的性能抖动 SQL ?/rdbms/admin/dbmspool.sql SQL /u01/app/ogg/ddl_pin goldengate逻辑说明marker_setup建 DDL 同步需要的 marker 表ddl_setup装 DDL 触发器role_setup创建 OGG 专用角色ddl_enable打开开关。四个脚本顺序不能乱中间任何一个失败后面的都会连不上。ddl_pin是可选项把 OGG 用到的包固定在共享池避免被换出后重新编译导致的短暂卡顿。参数说明ddl_pin的参数是 OGG 管理员 schema 名必须跟 GLOBALS 里的GGSCHEMA一致。执行完这些脚本后前面 Extract 参数里的DDL INCLUDE MAPPED才有意义否则 DDL 语句会被静默忽略。4.5 初始化数据SCN 对齐的两种做法存量数据不能靠 OGG 慢慢追必须单独导一次。核心是让导出和 Extract 的起点对齐在同一个 SCN 上顺序是先起 Extract拿到当前 SCN再按这个 SCN 导出。-- 1. 记录当前 SCN SQL select to_char(current_scn) from v$database; CURRENT_SCN ----------- 1085057 -- 2. 按该 SCN 导出源表 $ expdp test/test TABLEStest.t1 DUMPFILEt1.dmp flashback_scn1085057# 3. dump 文件拷到目标端后导入 $ impdp test/test dumpfilet1.dmp # 4. 目标端按 SCN 启动 Replicat只重放该 SCN 之后的变更 GGSCI (test2) 19 start replicat repgs1, aftercsn 1085057逻辑说明flashback_scn保证导出的是那个时间点的一致性快照aftercsn保证 Replicat 从同一个点之后开始重放两边正好接上。如果先导数据再起 Extract中间这段时间的变更就丢了如果 Extract 起得太早、SCN 取得太晚又会重复应用。我一般把select current_scn和start extract放在同一个脚本里连着执行减少人为误差。第二种做法是用sourceistable直接抽取适合表不多、不想走 expdp 的场景GGSCI (test1) 20 add extract init_t1, sourceistable GGSCI (test1) 21 edit params init_t1 EXTRACT init_t1 USERID goldengate, PASSWORD goldengate RMTHOST 10.0.100.141, MGRPORT 7809 RMTFILE ./dirdat/i1, MAXFILES 999, MEGABYTES 500 TABLE test.t1, SQLPREDICATE AS OF SCN 1085057; GGSCI (test1) 22 start extract init_t1目标端配一个 specialrun 的 Replicat 接收GGSCI (test2) 23 add replicat ri1, specialrun GGSCI (test2) 24 edit params ri1 REPLICAT ri1 SETENV (ORACLE_HOME /u01/app/oracle/product/11.2.0/db_1) SETENV (ORACLE_SID test2) USERID goldengate, PASSWORD goldengate EXTFILE ./dirdat/i1 MAP test.t1, TARGET test.t1;然后手工执行一次./replicat paramfile dirprm/ri1.prm完成初始化装载。注意 specialrun 不写 checkpoint跑完就结束不能用来做持续同步。4.6 三种 DML 验证初始化完成后按插入、删除、清表三种操作各验一遍覆盖最常见的三类变更-- 源端插入 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_id 87366; SQL commit; -- 目标端确认回退 SQL select max(object_id) from test.t1; MAX(OBJECT_ID) -------------- 87365 -- 源端清表 SQL truncate table t1; -- 目标端确认 SQL select count(*) from test.t1; COUNT(*) ---------- 0逻辑说明插入验证的是 Extract 能抓到新行、Replicat 能正确构造 INSERT删除验证的是主键定位是否准确如果 trandata 没加对删除可能变成全表扫描匹配或者直接报错truncate 验证的是GETTRUNCATES是否在两端都生效这一项经常被漏掉表现是源端清空了、目标端还有几万行。参数说明如果 truncate 没同步过去先查 Extract 参数里有没有GETTRUNCATES再查 Replicat 参数两处都要有。另外ALLOWNOOPUPDATES只影响更新对 truncate 无效。5. 避坑排查跨平台链路里最容易翻车的五处这条链路我在不同环境里配过几次参数大差不差但每次翻车的地方都很相似。下面五条按现象、原因、解决写都是实际遇到过的。5.1 进程类MGR 正常但 Extract 起不来现象start mgr成功info mgr显示 running但start extgsxf后状态立刻变成 ABENDEDview report extgsxf里只有一行ERROR OGG-01032 There is a problem in the Oracle database.。原因九成是enable_goldengate_replication没开或者开了但只在 memory 范围生效实例重启后又回去了剩下的一成是 OGG 账号缺dbms_goldengate_auth授权。解决show parameter enable_goldengate_replication确认是 TRUE不是的话重新alter system set ... scopeboth。再查select * from dba_sys_privs where granteeGOLDENGATE看有没有ALTER ANY TABLE、SELECT ANY TRANSACTION这类关键权限缺了就重新跑一遍授权包然后重启 MGR 和 Extract。5.2 数据类目标端有行但字段值是错的现象同步过去了行数对得上但中文名称字段是问号或者乱码时间字段普遍差几个小时。原因字符集和时区。Windows 源库常见ZHS16GBKLinux 目标库是AL32UTF8如果 Extract 的NLS_LANG写成AMERICAN_AMERICA.AL32UTF8读 GBK 数据时就会按 UTF-8 解析直接乱码。解决Extract 里的NLS_LANG必须写成源库的实际字符集比如AMERICAN_AMERICA.ZHS16GBKReplicat 端写目标库字符集。时区问题查两端的DBTIMEZONE不一致时在 Replicat 加SETENV (ORA_SDTZ08:00)显式指定会话时区。5.3 配置类Replicat 报 ORA-01403 找不到行现象Replicat 频繁ABENDED报告里全是ORA-01403: no data found对应的表明明有数据。原因update 或 delete 在目标端找不到匹配行。要么初始化数据的 SCN 对不上导致某段变更丢失要么SETENV (ORACLE_SID)写错了库进程连到了别的实例。解决先info replicat repgs1, detail看它当前停在哪个 SCN跟初始化时记录的 SCN 对比。如果 SCN 落后于实际导入点就得重新初始化。ORACLE_SID这个坑特别隐蔽参数文件是从源端拷过来改的很容易忘改我见过目标端参数里 SID 还写着源库实例名的进程能起来但写进的是完全不相干的库。5.4 性能类lag 越来越大DataPump 是瓶颈现象info all里 Extract 的 lag 一直是个位数DataPump 的 lag 从几十秒涨到几十分钟目标端 Replicat 反而很闲。原因跨平台投递的网络吞吐不够或者 trail 文件太小导致切换频繁。原文里megabytes 1024在变更量大的库上几小时就写满一个切换时会有短暂停顿。解决先把add rmttrail的 megabytes 调到 2048 以上减少文件切换再检查网络Windows 到 Linux 这段如果走了跨机房链路RTT 高会显著拉低吞吐。DataPump 参数里的TCPFLUSHBYTES可以适当调大默认 30KB 在高延迟链路上效率不高。5.5 运维类磁盘被 trail 文件撑爆现象运行一周后/u01使用率 100%OGG 各进程还在跑但新文件写不进去链路静默中断。原因PURGEOLDEXTRACTS没配或者配了但USECHECKPOINTS找不到 checkpoint 表清理逻辑判定为不安全直接跳过不删。解决MGR 参数里必须有PURGEOLDEXTRACTS ./dirdat/*, USECHECKPOINTS, MINKEEPHOURS 12且 checkpoint 表必须存在并且能被读写。清理是按文件粒度的最小保留单位是小时一天内大量小文件的话清理速度跟不上产生速度这种情况只能调大 trail 文件大小减少文件数。6. 把链路看住从 ggserr.log 到 lag 的三个固定动作链路配完只是开始能不能稳取决于你多久看一次状态。我现在的习惯是每天早中晚各跑一遍固定动作全部在 GGSCI 里完成五分钟内能确认整条链路是否健康。第一个动作看进程状态重点不是 RUNNING而是 lag 和 sinceGGSCI (test1) 1 info all Program Status Group Lag at Chkpt Time Since Chkpt MANAGER RUNNING EXTRACT RUNNING EXTGSXF 00:00:00 00:00:03 EXTRACT RUNNING DPGSKF 00:00:02 00:00:01Lag at Chkpt是检查点时间差Time Since Chkpt是多久没更新检查点。如果后者持续增长到几分钟以上即使状态是 RUNNING也说明进程卡住了通常是长事务或者网络抖动。这两个指标比单纯看状态可靠得多。第二个动作翻日志。所有进程的异常都会写进 OGG 根目录下的ggserr.log按时间倒序看最近的变化# 抓最近 200 行里的错误和警告 tail -n 200 /u01/app/ogg/ggserr.log | grep -Ei ERROR|WARNING|ABEND # 单独看某个进程的详细报告 GGSCI (test1) 2 view report extgsxf报告里我最关注三块Runtime Statistics里的每秒处理量Long Running Transactions里有没有卡住的事务以及Discarded Records是不是在增长。丢弃记录一旦出现说明有行被跳过必须马上查dirrpt下的 discard 文件。第三个动作是定期做一次小批量数据比对。抽样比对源端和目标端的行数、最大主键、金额汇总用一条 SQL 就能完成-- 在源端和目标端各执行一次对比结果 select count(*) as cnt, max(object_id) as max_id, sum(object_id) as sum_id from test.t1;三个值都对上基本可以确认链路没有静默丢数据。有次一个 update 因为目标端缺列被ALLOWNOOPUPDATES静默跳过就是靠这个比对发现的表面一切正常实际已经偏了两天。这套动作看起来笨但比出事之后再回头翻日志快得多。从那以后我每次交付 OGG 链路都会把这三个动作写进运维手册并且强制要求上线首周每天执行一遍把ggserr.log的轮转和 trail 目录的磁盘水位也一起纳入监控。链路这东西平时不吵不闹一坏就是数据层面的问题后悔药是买不到的。希望帮到你。本文还有配套的精品资源点击获取