容灾目标是「主库挂了能秒级接管」就选data guard物理standby；需异构同步或部分表过滤则用goldengate；adg dml redirect非双活，混合部署常dg+ogg组合实现容灾与数据分发。
容灾目标是「主库挂了能秒级接管」，就选 Data Guard 物理 standby
只要你的核心诉求是数据库级高可用、RPO≈0、故障后快速 failover（不是 failover 后再手动修应用），Data Guard 就是更直接、更少变量的选择。它不解析日志内容，只传输和应用归档/在线重做日志，链路短、延迟稳、异常点少。
常见错误现象：ORA-16792（配置参数不一致）、LOG_ARCHIVE_DEST_n 用 SYNC 却没配 NET_TIMEOUT 导致主库夯住、备库未开 FLASHBACK 无法转快照库——这些问题本质都是配置细节漏项，不是架构缺陷。
- 必须开启
ARCHIVELOG和FORCE LOGGING，否则 DG 启动即失败 - 最大保护（
MAXIMUM PROTECTION）模式下，备库不可达会直接 shutdown 主库，生产环境建议从MAXIMUM AVAILABILITY起步 - 物理 standby 默认只读；要支持实时查询（Active Data Guard），需额外购买
ADG许可，非免费 - 跨平台（如 Linux 主库 → Windows 备库）不支持物理 standby，只能退到逻辑 standby 或换 OGG
需要「部分表同步」「字段过滤」「Oracle → Kafka/MySQL」，就绕不开 GoldenGate
GoldenGate 不是容灾兜底工具，而是数据流动引擎。它解决的是「数据怎么动起来」的问题，不是「主库崩了怎么办」的问题。如果你的场景里出现「只同步订单表」「把手机号脱敏后再写入报表库」「把 Oracle 变更实时推到 Flink 消费」，DG 做不到，OGG 是事实标准。
典型踩坑点：OGG-01223（trail 文件损坏）、源端 EXTRACT 因归档被提前清理而中断、目标端 REPLICAT 遇唯一键冲突卡死却不自动跳过（得手动 SKIPTRANSACTION）——这些都源于 OGG 需要解析日志并构造 SQL，比 DG 多一层逻辑，自然多一重风险面。
统一LLM网关 - 一个API对接70+AI模型，使用单一API密钥即可调用GPT、Claude、Gemini、Qwen、Deepseek、Grok等主流模型。
- DDL 同步必须显式开启：
DDL INCLUDE MAPPED，且目标库对象名大小写、字符集、权限需提前对齐，否则高频报OGG-01163 - 亚秒级延迟是常态，但不是强保障：大事务拆分、目标库慢 SQL、网络抖动都会导致
LAG AT CHECKPOINT突增，监控必须盯紧这个指标 - OGG 不支持运行时故障转移：主库挂了，不能自动把
REPLICAT切到另一套源端；它只保证“数据能追上”，不保证“服务能接上”
19c 下别被「ADG DML Redirect」误导，它不等于双活写入
Oracle 19c 引入的 ADG DML Redirect 功能，允许客户端在 ADG 备库发起 DML，由备库自动转发到主库执行并回传结果。但它本质仍是单点写入，所有变更最终落在主库，不是真正的双活。别把它和 GoldenGate 的双向复制或逻辑 standby 的本地 DML 混淆。
这个功能对读写分离类场景有帮助，但不会降低主库压力，也不改变 RPO/RTO 指标。如果真需要两端同时写入（比如异地双中心业务分流），必须用 GoldenGate 或逻辑 standby（后者限制极多）。
-
DML Redirect要求客户端使用 Oracle Net Service Name 并启用ENABLE_DML_REDIRECT=ON - 不支持含
SYSDATE、ROWID、SEQUENCE.NEXTVAL的语句，逻辑 standby 同样受限 - 开启后仍需严格管控应用连接路由，避免误连备库执行 DDL 或 DCL
混合部署不是噱头，VPS 跨区域容灾常靠 DG + OGG 组合
美国 VPS 上跑 Oracle 19c，主库在 us-west，备库在 us-east，既要低延迟容灾又要支撑报表分析——这时单独用 DG 或 OGG 都不够。真实方案往往是：DG 物理 standby 保 RPO≈0 容灾能力，OGG 从 DG 备库（非主库）抽取变更，投递到 Kafka 或 MySQL 报表库。这样既规避了 OGG 直连生产库带来的资源争抢，又绕开了 DG 无法做异构同步的短板。
这种组合的关键约束在于网络：跨区域 TCP 传输需调优 net.ipv4.tcp_window_scaling 等内核参数，否则重传率高、DG 日志传输延迟波动大，会拖累 OGG 抽取起点。
- OGG 源端应连 DG 备库（
standby redo log可读），而非主库，减少生产负载 - DG 备库开启
ACTIVE DATA GUARD后，才能支持 OGG 的实时抽取（READ COMMITTED隔离级别） - OGG trail 文件建议存放在独立磁盘，避免与 DG 归档路径争 I/O
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 或 START EXTRACT，可能下周就收到 Oracle LMS 的邮件。
