有次帮人排查备库延迟聊到最后对方来了一句“那我直接把同步模式改成最大可用不就行了”我愣了一下因为“最大可用”是 Data Guard 的保护模式它本身不是同步模式。后来我发现“Oracle 同步模式”这个说法在很多人脑子里其实是笔糊涂账——有人问的是 DG 里 SYNC/ASYNC 怎么配有人问的是 Oracle 到底有哪几种数据同步方案还有人把逻辑备库和 GoldenGate 的定位搞混。这篇文章我就把这层窗户纸捅破聊一下 Oracle 生态里真正在用的 4 种同步模式配合我这些年实际维护过的环境说说每种模式怎么选、怎么配、坑在哪里。一个背景交代下面聊的 4 种同步模式我按大家在生产环境里最常遇见的分类来拆——Data Guard 物理备库、Data Guard 逻辑备库、GoldenGate 日志复制以及 Streams/高级复制这类老派方案。它们都能让数据从源端流向目标端但同步粒度、实时性、对源库的影响完全不同。选错了轻则性能被拖垮重则主备切换时才发现数据对不上。1. 先理清概念同步、保护模式、复制方案不是一回事1.1 “同步模式”这个说法到底指什么Oracle 文档里其实没有一个叫“同步模式”的官方术语。大家口中说的“同步”至少有三层含义redo 传输模式比如 Data Guard 里的SYNC、ASYNC、FAR SYNC这是主库把 redo 日志发给备库的传输方式。Data Guard 保护模式最大保护、最大可用、最大性能描述的是“主库在多大程度上等待备库确认”的策略。广义的数据复制方案物理备库、逻辑备库、GoldenGate、Streams这些是完整的数据同步架构。很多刚接手 Oracle 库的朋友一开口就是“把同步模式改成最大保护”其实是把上面第 2 层和第 3 层混着说了。为了后面不绕晕先把这些概念分开看。1.2 四种方案的全景对比下面这张表是我做同步方案评估时最常用的一张对比表一张表看明白四个候选对象的边界。方案同步粒度实时性目标库要求是否支持部分表典型用途DG 物理备库数据文件块级秒级仅 Oracle否整库同步容灾、高可用、ADG 只读查询DG 逻辑备库行级逻辑事务秒级仅 Oracle否整库逻辑应用容灾 备库可开放报表GoldenGate事务级亚秒级到秒级可异构是可按表同步异构同步、在线迁移、数据汇聚Streams/高级复制对象级/事务级秒级主要是 Oracle是存量老系统沿用新项目不建议也就是说如果你要的是“整个数据库的容灾”首选 DG 物理备库如果你要的是“把某几张表同步到另一个库”首选 GoldenGate如果你只有 Oracle 源和目标、还想备库提供报表查询逻辑备库可以作为补充选项Streams 和高级复制属于历史遗留产物我后面会专门说为什么不推荐。2. Data Guard 物理备库块级同步容灾首选2.1 工作原理一句话讲清物理备库的核心思路是主库产生 redo log通过网络传到备库备库把 redo 应用到自己的数据文件上。因为备库做的是和主库几乎一样的块级变更所以数据文件内容和主库在物理结构上高度一致。这个“同步”是面向整个数据库实例的不是面向单张表的。你没法说“我只要同步orders表到备库”DG 的粒度就是整个库。这一点在做选型时特别重要——通常业务部门提出的需求都是“把报表库那几张表同步一下”那不是 DG 的活。2.2 SYNC / ASYNC / FAR SYNC 三种传输模式怎么选这是“同步模式”这个关键词最容易被指代的内容。Data Guard 的 redo 传输有三种SYNC主库 commit 时必须等 redo 被备库接收注意是接收不要求应用事务才算提交成功。数据安全最好但网络延迟会直接拖累主库响应时间。ASYNC主库 commit 成功后立即返回redo 异步传往备库。对主库性能影响最小但是备库数据理论上会有丢失窗口。FAR SYNC通过一个中间站点far sync 实例做中转。主库把 redo 用SYNC传到中间站中间站再异步转发到最终备库。适合跨大距离的容灾场景因为主库只感知到中间站的延迟而不是远端备库的延迟。我见过很多人在同机房也非要配SYNC结果只要备库磁盘稍微慢一点主库的commit等待立刻增加应用层超时报警一片。同机房的容灾我一般建议用ASYNC或者SYNC二选一先压测不同机房的业务优先考虑FAR SYNC。2.3 三种保护模式和生产库的关系传输模式之上还有一层保护模式这层决定主库对“备库不可用”的态度最大保护Maximum Protection要求备库必须可用否则主库自动 Shutdown。这是最极端的数据安全策略。最大可用Maximum Availability正常情况下等同于最大保护但备库故障时自动降级为最大性能不拖垮主库。这是我能接受的最高安全等级。最大性能Maximum Performance默认模式主库完全不等待备库数据丢失风险最大。配置命令很简单SQL ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY;但真正要配套的是传输参数SQL ALTER SYSTEM SET LOG_ARCHIVE_DEST_2SERVICEstby SYNC AFFIRM DB_UNIQUE_NAMEstby SCOPEBOTH;AFFIRM表示备库要写日志成功后才确认。很多新手只改了保护模式忘了改传输方式结果最大可用模式其实还是跑了异步保护等级的语义就没真正实现。2.4 我在真实环境里的配置习惯我自己维护过的生产环境主备库在同一机房跑的是最大性能加ASYNC绝大多数业务都没问题。只有一套账务系统要求严格用最大可用加SYNC但前提是网络专线延迟控制在 1ms 以下而且备库本身是高性能存储。每次巡检我会重点看两个视图SELECT * FROM V$ARCHIVED_LOG ORDER BY SEQUENCE# DESC; SELECT * FROM V$DATAGUARD_STATS;特别是V$DATAGUARD_STATS里的apply lag和transport lag只要持续超过阈值就说明备库已经跟不上主库了。遇到备库延迟很多人第一反应是加带宽其实八成原因是备库应用 redo 的磁盘 IO 太慢或者归档日志清理不及时。先把备库 IO 打上去再说。3. Data Guard 逻辑备库能供查询的“同步”但限制不少3.1 物理备库不能解决的问题物理备库有个天然的短板它以块级重放 redo数据文件结构必须和主库完全一致。所以物理备库虽然可以临时以只读方式打开但很难针对某张表做单独加工而且传统模式下备库在应用 redo 时无法开放查询即便开了 Active Data Guard它依然是“主库的一个物理副本”。业务方经常说“我要在备库跑报表但不能影响主库”。这时候逻辑备库就登场了。逻辑备库也是 Data Guard 的一部分但它不是重放数据块而是把 redo 里的变更通过 LogMiner 解析成逻辑 SQL再在备库执行。3.2 LogMiner 逻辑应用的代价与限制听起来很美好实际上代价不小redo 解析本身有额外开销主库日志量大的时候备库解析和应用的性能很容易成为瓶颈。逻辑备库的 SQL 应用要求表能唯一定位所以源表最好有主键或唯一索引。很多数据类型和对象在逻辑备库不受支持比如XMLType、索引组织表、某些CLOB场景、加密列等。主库执行过的某些 DDL比如在线重定义、表结构大变动可能直接导致逻辑备库复制中断。我接手过一套用逻辑备库做报表的存量系统最头疼的问题就是主库表结构变更后逻辑备库的 SQL Application 停在一个未知状态最后不得不STOP掉手工追赶再重新START。这类操作必须放在维护窗口否则线上报表库的数据就永远比主库晚好几个小时。3.3 上线前必须做的三件事如果你确实要用逻辑备库我的建议是把下面三步做成上线前检查清单先跑一遍类型支持检查SELECT DISTINCT SUPPORTED FROM DBA_LOGSTDBY_UNSUPPORTED; SELECT TABLE_NAME, SUPPORTED FROM DBA_LOGSTDBY_UNSUPPORTED WHERE TABLE_NAME 业务表名;确认核心表都有主键或唯一约束。这个问题在逻辑备库里是致命的没有唯一标识LogMiner 就不知道变更应该定位到哪一行。提前规划 DDL 流程。大表在线重定义、改分区、加主键这类操作先在测试环境跑一遍逻辑备库的START/STOP流程确保不会中断。另外有一点很多人忽略逻辑备库虽然是“逻辑”应用但它依然只能同步整个数据库你不能只挑某几张表。如果你真的只想要几张表那就去用 GoldenGate别在逻辑备库上死磕。4. GoldenGate事务级逻辑复制异构场景的主力模式4.1 捕获-投递-复用三段式原理GoldenGate 的原理可以概括成三条链路捕获、投递、复用。源端的Extract抽取进程直接读取 redo/archive log把变更解析成 GoldenGate 自己的事务格式然后通过Data Pump投递进程发送到目标端目标端的Replicat复用进程把事务在目标库重放。整个过程不依赖 Oracle 自身的 Data Guard 机制。和 DG 最大的区别是GoldenGate 是事务级同步而且可以在表、schema 级别做精细化过滤。你完全可以只把sales方案下的三张表同步到目标库。也正因为这个特性GoldenGate 成为企业异构数据同步和在线迁移的标配。4.2 常见的四种拓扑方向很多人以为 GoldenGate 只能一对一同向其实它可以组出不少形态一对一复制一个源到一个目标最基础。一对多分发一个源同步到多个目标库常见于总部向分支机构下发数据。多对一汇聚多个源库汇聚到一个目标库典型的 ODS/数仓场景。双向复制两个库互相同步用于应用层做读写分离和就近访问但需要有完善的冲突处理机制。我参与过一个模拟项目把 5 个业务库的transaction表汇聚到一个汇总库用的就是 GoldenGate 的多对一配置。每条源链路独立抽取目标端按来源映射不同目标表或表分区整体延迟最差也在 3 秒以内比原来每天凌晨跑 ETL 的做法实时多了。4.3 最小化配置跑通一张表快速体验 GoldenGate 的配置大致是这几步源端开启补充日志让日志里有足够的主键和旧值信息SQL ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;创建 GoldenGate 专用用户并授权。源端抽取进程参数例如EXTRACT ext1 USERIDALIAS ogg_admin EXTTRAIL ./dirdat/et TABLE hr.orders;目标端复用进程参数例如REPLICAT rep1 USERIDALIAS ogg_admin MAP hr.orders, TARGET hr.orders;启动进程后查看状态GGSCI START EXTRACT ext1 GGSCI START REPLICAT rep1 GGSCI INFO ALL这只是一个最简跑通流程。生产上的 GoldenGate 配置要考虑大事务切分、DDL 复制、初始数据加载、进程异常恢复这些额外问题。我见过太多人以为配完就没事结果一次大事务就把 trail 文件塞满进程直接 hang 住。4.4 OGG 和 DG 怎么配合经常有同事问我“有了 Data Guard还用得着 GoldenGate 吗”两者不是替代关系而是分层关系容灾层用 Data Guard 物理备库负责整库级别的故障切换和无损恢复。数据流动层用 GoldenGate负责把业务表同步到分析库、异构库或者下游消息系统。比如一套系统核心库到同城容灾库走 Data Guard同时库里最热门的业务订单表通过 GoldenGate 同步到下游的数据分析平台。两层各干各的互不干扰。配置上注意一点如果你在 DG 主库上再跑 GoldenGate务必考虑日志量的增长因为补充日志会让 redo 变大而 DG 的传输和备库应用会跟着吃更多带宽和 IO。5. Streams 与高级复制还在存量系统里的老模式5.1 Streams 的队列式架构Streams 是 Oracle 9i 引入的复制架构后来定位变得非常宽既能做复制也能做消息队列。它内部有一套基于队列的逻辑源库的变更被捕获成 LCR逻辑变更记录进队列再通过传播进程路由到目标库的目标队列最后被应用进程执行。说实话Streams 在 10g 时代是挺好用的可以按表同步也可以做事件分发。但它的架构太重、配置链路长一旦队列堵了问题定位特别痛苦。我印象最深的一次故障源库一张大表做了ALTER TABLE MOVEStreams 捕获进程直接报错停住后面的应用进程全部排队备库数据落后了两天。那次排查花了一个通宵结论是业务操作在生产库上太“奔放”。5.2 高级复制和物化视图复制比 Streams 更早的是高级复制Advanced Replication也叫多主复制。它的思路是在多个库之间维护同一组表的数据一致性技术手段可以是触发器、延迟事务队列也可以是物化视图刷新。这类方案对生产库性能影响大而且在表结构变更、冲突处理、网络不稳定这些场景下都非常痛苦。现在新系统很少见到有人主动选它它更多出现在老系统迁移项目里一查源库发现还在用物化视图刷新做日级同步或者用多主复制支撑两个营业点之间的小表互备。5.3 为什么建议尽快迁移核心原因很简单Oracle 官方早已将 Streams 标记为废弃特性新版本对它的支持越来越弱装库时多看几眼告警日志都能看到相关提示。高级复制更是连升级到新版本都费劲。选择还在维护期的技术栈本质上是在给未来的升级和故障处理埋雷。5.4 存量系统迁移建议如果手里真有 Streams 或高级复制的存量库我的建议是分两步走如果是整库容灾目标直接用 Data Guard 物理备库替换切换起来最稳。如果是部分表同步到 Oracle 目标或异构目标优先迁到 GoldenGate因为它也是日志级捕获对源库影响方式和 Streams 类似但架构清晰得多。实战里最难的不是配新链路而是把旧链路上那些“隐形的增量”全部找到。某次迁移模拟项目里我们先把源库和目标库做了全量对比列出几百张存在差异的表再用 GoldenGate 的初始加载配合追平最后才切换业务。这个流程跑完老的 Streams 配置才敢下掉。6. 选型决策四个问题帮你选出对的同步方案6.1 四个问题定方案每次做同步方案评审我都会问业务方四个问题答案基本能锁定方向你的目标库还是 Oracle 吗如果不一定是 OracleDG 物理备库和逻辑备库直接出局GoldenGate 是首选。如果目标是 Kafka、大数据平台那还要考虑 GoldenGate 的异构适配器。你的容灾要求是整库还是部分表整库容灾偏好 DG部分表、按业务抽取走 GoldenGate。你的 RPO/RTO 是多少如果 RPO 接近 0RTO 要求分钟级DG 最大可用或最大保护才够如果允许分钟级数据丢失DG 最大性能 ASYNC 就能满足成本也低。团队有没有能力维护复杂链路逻辑备库和 GoldenGate 的日常监控、版本升级、故障恢复都比物理备库复杂。没有专门 DBA 支撑的小团队我会直接劝他别上逻辑备库。6.2 场景决策表直接照着下面这张表抄作业就行业务场景首选方案备选方案备注同城双机房整库容灾DG 物理备库ASYNC物理备库SYNC网络延迟小于 2ms 可上 SYNC跨地域容灾延迟敏感DG 物理备库FAR SYNCGoldenGate中间站方案可降低主库感知延迟备库想分担报表查询DG 逻辑备库或 ADGGoldenGate 同步到报表库先检查表类型支持和唯一索引只同步几张核心表GoldenGateStreams不建议异构环境直接锁定 GoldenGate多库数据汇聚到 ODSGoldenGate 多对一物理备库 物化视图汇聚场景优先考虑事务级复制Oracle 到非 Oracle/大数据GoldenGate 异构适配Data Pump ETL实时性要求高则选 GoldenGate把这张表和前面四套方案的原理放在一起看思路就很清晰了物理备库解决的是“活着”的问题逻辑备库解决“备库能用”的问题GoldenGate 解决“数据能流动到哪”的问题Streams 则属于“历史遗留如何消化”的问题。我在实际选型中还有一个习惯不管选哪条路上线前都先在测试环境做一轮混沌演练模拟主库断网、备库磁盘写满、GoldenGate 进程崩溃这些场景记录下每个方案的实际 RPO/RTO而不是盯着厂商文档里的理想指标。同步方案这东西平时默默无闻出问题那几次才是它真正亮肌肉的时候提前知道它的底线总比上线后手忙脚乱强。