容灾首选Data Guard，因其轻量稳定、RPO≈0；GoldenGate适用于跨库同步与数据流动，非容灾兜底。两者均需ARCHIVELOG和FORCE LOGGING，但许可成本与架构适配差异显著。
容灾场景下优先选 Data Guard，除非你明确需要跨库或双活
如果目标只是 oracle 数据库高可用、故障快速切换、rpo≈0 的容灾，data guard 是更轻量、更稳定、更少维护的选择。它直接复用 oracle 自身的 lgwr / arch 进程和归档日志传输机制，不引入额外中间件，也不依赖解析 sql 或构造事务——这意味着链路短、延迟低、出错点少。
常见错误现象：ORA-16792（配置不一致）、备库因未开 FLASHBACK 无法转为快照库、LOG_ARCHIVE_DEST_n 中 SYNC 模式下主库被阻塞却没配超时参数。这些都不是 GoldenGate 会遇到的问题，但恰恰是 DG 配置里最容易漏掉的细节。
- 物理 standby 启动后默认只读，要启用实时查询必须开启
ACTIVE DATA GUARD许可（非免费） - 最大保护（
MAXIMUM PROTECTION）模式下，一旦网络抖动或 standby 不可用，主库会直接 shutdown —— 生产环境慎用，建议从MAXIMUM AVAILABILITY起步 - 逻辑 standby 支持 DML，但对数据类型、DDL、函数索引等有严格限制，比如含
SYSDATE、ROWID、SEQUENCE.NEXTVAL的语句可能无法重演
GoldenGate 适合做「数据流动」而不是「容灾兜底」
GoldenGate 的核心价值不在替代主库，而在让数据动起来：同步部分表、过滤字段、转换结构、写入异构库（如 Oracle → Kafka / MySQL / PostgreSQL）、支撑报表分离或双写兜底。它的复制粒度是事务级甚至行级，不是数据库级镜像。
典型踩坑点：GGS ERROR OGG-01223（trail 文件损坏）、源端抽取进程（EXTRACT）因归档日志被提前清理而中断、目标端 REPLICAT 因唯一键冲突卡住却无自动跳过机制（需手动 SKIPTRANSACTION）。这些问题在 DG 里几乎不存在，因为 DG 不解析日志内容。
- OGG 不支持运行时故障转移 —— 主库挂了，不能自动把 replicat 切到另一套源端；它只保证“数据能追上”，不保证“服务能接上”
- 亚秒级延迟是常态，但不是强保障：网络抖动、目标库慢 SQL、大事务拆分都会导致 lag 突增，监控必须盯紧
LAG AT CHECKPOINT - DDL 同步需显式开启（
DDL INCLUDE MAPPED），且目标库对象名大小写、字符集、权限需提前对齐，否则OGG-01163错误频发
别拿 DG 的物理 standby 和 OGG 的双活比「读写能力」
有人说 “DG 备库只能读，OGG 可以双写”，这本身是个误导前提。DG 的物理 standby 确实不能写，但逻辑 standby + APPLY SERVER 关闭后可临时 read-write；而 OGG 的双写必须靠应用层控制冲突（比如用时间戳/UUID 分片），OGG 自身不提供分布式事务协调能力。
真实约束在于：如果你真需要两端同时写入并保持最终一致，那既不是 DG 也不是 OGG 的本职工作——那是应用架构或分布式事务中间件（如 Seata、XA）该解决的问题。OGG 只负责把 A 库的变更“尽力可靠”地推到 B 库，不保证 B 库改完之后 A 库还能接受来自 B 的反向变更。
- OGG 双向复制（Bi-Directional）需手动配置冲突检测规则（
RESOLVECONFLICT），且仅支持简单策略（如“取最新时间戳”），复杂业务逻辑得自己写 handler - DG 的快照 standby 可读写，但写入内容会在下次闪回或切换时丢失 —— 它不是为长期双活设计的，而是为测试/报表隔离准备的
- 两者都要求源库开启归档（
ARCHIVELOG）和强制日志（FORCE LOGGING），这点没得绕
升级与许可成本往往比技术选型更影响决策
Oracle 官方已明确：Data Guard 是数据库内置功能，11g 及以后版本随数据库许可证附赠；而 GoldenGate 是独立商用产品，按 CPU 核数或命名用户收费，且 12c 之后不再提供永久许可，只卖订阅。很多团队压根没算这笔账，直到上线前被 License Audit 找上门。
另一个现实问题：ADG（Active Data Guard）虽支持实时查询，但开启 REAL TIME APPLY 后，备库的 DBWR 进程压力明显上升，尤其在高并发小事务场景下，I/O 等待可能成为瓶颈 —— 这时候加资源不如先看是不是真需要备库扛查询流量。
- GoldenGate 19c+ 支持集成
Kafka和Cloud Storage，但需要额外部署Adapter插件，版本兼容性要逐个验证（比如ogg-kafka-adapter-19.1.0.0.0不兼容 JDK 17） - DG 在 19c 中新增
FAR SYNC实例缓解长距离网络延迟，但要求主库、far sync、standby 全部同版本，混搭易出ORA-16826 - 国产替代方案（如 Beedup）确实在本地化支持和响应速度上有优势，但对 Oracle RAC + ASM + Multitenant 架构的适配深度，目前仍弱于原厂工具
