主备库必须部署在不同地理区域，如北京和上海，或OCI/Exadata的不同region；同城双机房仅适合测试，跨区域才是生产级容灾底线。
主备库部署位置怎么选？别只看网络延迟
同城双机房不是最优解，跨区域才是生产级容灾的底线。主库和备库必须部署在不同地理区域（比如北京和上海），否则一次区域性断电或光缆中断就能让整套架构失效。
OCI 或 Exadata 环境下，优先选择不同 region；本地私有云环境，则至少保证主备机房之间物理隔离、供电独立、网络路由不重叠。同一 availability domain 内配 Data Guard 属于伪高可用，仅适合测试或非核心系统。
- 同步模式（
SYNC）要求 RTT ≤ 5ms，这基本只能在同城双活场景下满足；但 RPO=0 的代价是主库事务响应变慢，尤其对 OLTP 高并发写入敏感 - 异步模式（
ASYNC）可跨省甚至跨国，但存在数据延迟风险，需结合MAXIMUM PERFORMANCE模式使用，并定期验证日志 GAP - 如果用 RAC + DG 组合，备库也必须是 RAC（即“2+2”），否则 Failover 后单点成为新瓶颈
物理备库 vs 逻辑备库：选错类型会卡死运维
95% 的生产系统应该直接选物理备库（Physical Standby）。它基于块级恢复，兼容所有数据类型、DDL 和隐式操作，且切换速度快（分钟级），是唯一支持 Failover 和 Switchover 的标准路径。
逻辑备库（Logical Standby）表面支持读写，实际限制极多：LOB、XMLType、Object Types 等类型可能无法复制；ALTER SYSTEM、FLASHBACK 等命令会被跳过；更麻烦的是，一旦主库执行了不支持的 DDL（比如 TRUNCATE），备库就会报错停在 LOGICAL STANDBY 状态，需要人工干预重建。
- 只有明确需要备库跑报表且能接受表级只读 + DDL 白名单管控时，才考虑逻辑备库
-
Snapshot Standby是临时方案，仅用于测试验证，切回物理备库前必须闪回，不能长期运行 - 启用
Active Data Guard（ADG）后，物理备库可只读打开，同时继续应用 Redo，这才是真正的“读写分离+零RPO”组合
Data Guard 保护模式怎么设？别盲目追求 RPO=0
Oracle 提供三种保护模式：MAXIMUM PROTECTION、MAXIMUM AVAILABILITY、MAXIMUM PERFORMANCE。它们不是性能高低排序，而是 RPO/RTO 权衡矩阵。
MAXIMUM PROTECTION 要求至少一个备库同步确认，主库才会提交——但只要该备库宕机或网络中断，主库立刻挂起（ORA-16191）。生产环境几乎不用，只在极少数合规强监管场景下短暂启用。
- 日常推荐
MAXIMUM AVAILABILITY：主库默认 SYNC，备库掉线自动降级为 ASYNC，主库不停；恢复后自动追平，RPO 接近 0 且业务不中断 - 异地灾备第三节点（如贵阳单机）必须用
MAXIMUM PERFORMANCE，否则主库受远端延迟拖累 - 切换前务必检查
DBA_DATAGUARD_CONFIG和V$DATAGUARD_STATS，确认无未传输日志、无应用延迟（apply lag> 0 就不能做 Switchover）
配置时最容易漏掉的三件事
很多团队按文档走完流程，结果 Failover 失败或切换后应用连不上——问题往往出在细节。
- 主备库的
DB_UNIQUE_NAME必须不同，但DB_NAME必须相同；漏改前者会导致 Broker 无法识别角色，DGMGRL报ORA-16664 - 备库的
listener.ora和tnsnames.ora必须包含主库服务名，否则 Broker 切换时无法重定向连接，应用持续连老地址 - 启用 ADG 后，备库开启只读前必须先启动
MRP进程（ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT），否则只是静态副本，不实时同步
真正难的不是第一次配置成功，而是让这套机制在无人值守时仍能正确响应故障——所有路径、权限、归档目标、Standby Redo Log 数量，都得按真实负载压测过，而不是照搬模板。
