Oracle GoldenGate实战：不停机情况下如何优雅地重新同步单张表（经典模式）

Oracle GoldenGate实战零停机修复单表数据同步的经典模式解决方案当关键业务系统需要7×24小时运行时数据同步的稳定性直接关系到业务连续性。上周我遇到一个典型案例某航空公司的航班调度系统中FLIGHT.TAB1表因网络闪断导致目标端数据滞后3小时而其他表同步正常。传统全量同步方案需要停机8小时显然不可行。本文将分享如何用Oracle GoldenGateOGG经典模式实现单表精准重同步同时保持其他表正常同步。1. 问题诊断与SCN定位策略数据不一致问题往往隐藏在业务高峰期的日志中。首先通过OGG的VIEW REPORT命令检查extprod和repprod进程状态# 查看抽取进程状态 VIEW REPORT extprod | grep -A 10 FLIGHT.TAB1 # 查看应用进程延迟 SEND REPPROD GETLAG当确认单表不同步后关键步骤是获取准确的SCN号。我推荐使用OGG内置函数而非直接查询数据库-- 更可靠的SCN获取方式 GGSCI SEND EXTPROD GETSCN Current SCN: 12340551884978注意OGG 11g与12c版本在SCN引用语法上有差异。11g需用双引号TRANSACTION而12c需用单引号TRANSACTION否则会报OGG-01298错误。2. 数据导出导入的实战技巧2.1 源端数据导出最佳实践使用expdp导出时必须包含FLASHBACK_SCN参数确保数据一致性。以下是经过优化的导出命令expdp system/password directoryDATA_PUMP_DIR dumpfiletab1_resync_$(date %Y%m%d).dmp logfiletab1_resync.log tablesFLIGHT.TAB1 contentDATA_ONLY flashback_scn12340551884978 parallel4 compressionALL重要参数说明参数作用推荐值contentDATA_ONLY仅导出数据必选flashback_scn保证数据一致性从OGG获取parallel加速导出根据CPU核数调整compression减少传输时间ALL2.2 目标端数据预处理在导入前禁用约束比清空表更安全。执行顺序应该是禁用外键约束SELECT ALTER TABLE ||TABLE_NAME|| DISABLE CONSTRAINT ||CONSTRAINT_NAME||; FROM ALL_CONSTRAINTS WHERE R_CONSTRAINT_NAME IN ( SELECT CONSTRAINT_NAME FROM ALL_CONSTRAINTS WHERE TABLE_NAMETAB1 );保留表结构清除数据-- 比TRUNCATE更安全的方式 DELETE FROM FLIGHT.TAB1; COMMIT;3. Replicat进程的精细调控3.1 参数文件的关键修改在repprod.prm中为问题表添加SCN过滤条件其他表保持原样MAP FLIGHT.TAB1, TARGET FLIGHT.TAB1, FILTER (GETENV (TRANSACTION, CSN) 12340551884978); -- 其他正常表无需过滤 MAP FLIGHT.TAB2, TARGET FLIGHT.TAB2; MAP FLIGHT.TAB3, TARGET FLIGHT.TAB3;3.2 进程重启的优雅方式使用ROLLOVER命令可减少重启影响# 平滑重启replicat SEND REPPROD ROLLOVER监控同步进度时这个组合命令特别有用watch -n 5 echo STATS REPPROD TOTALFLIGHT.TAB1 | ./ggsci4. 验证与收尾工作当延迟归零后按此流程完成最终同步暂停replicat进程SEND REPPROD STOP移除过滤条件vi dirprm/repprod.prm重启进程START REPPROD重新启用约束SELECT ALTER TABLE ||TABLE_NAME|| ENABLE CONSTRAINT ||CONSTRAINT_NAME||; FROM ALL_CONSTRAINTS WHERE STATUS DISABLED;我在某次金融系统迁移中用这个方法成功修复了账户余额表的不同步问题整个过程业务无感知。关键点在于精确控制SCN范围、保持其他表正常同步、完善的预处理和后处理。