多机房ADG架构核心目标是实现RPO=0、RTO≤30秒且Apply Lag≤60秒；需每季度Switchover演练、每年Failover实战，确保参数生效、连接自动重连、错误可捕获，并切换后验证lag为0及归档应用完整。
明确多机房ADG架构的核心目标
多机房高可用容灾不是简单拉两台服务器配主备，而是围绕rpo=0（零数据丢失）和rto
网络与硬件分层规划要点
物理距离决定技术选型。同城（100公里）则需考虑带宽成本与WAN优化。硬件配置上，同城备库必须与主库同规格（CPU/内存/IO能力），否则切换后易成性能瓶颈；异地备库可适度降配，但磁盘吞吐不能低于主库70%，否则日志应用会持续积压。
- 主库与同城备库：共用同一套Data Guard Broker管理，启用Real-Time Apply + Active Data Guard只读功能
- 异地备库：单独配置Broker Observer（观察器），避免单点故障影响整个集群判断
- 所有节点统一部署NTP服务，时间误差严格控制在±50ms以内，否则RFS进程注册可能失败
同步模式选择与参数调优实战
Oracle 19c提供三种保护模式，多机房场景下需混用而非一刀切：
- 同城备库用MAXIMUM AVAILABILITY（最大可用）：主库提交前等待至少一个同城备库写入Standby Redo Log并确认，既保证RPO≈0，又避免主库因网络抖动被强制挂起
- 异地备库用MAXIMUM PERFORMANCE（最大性能）：主库不等待异地响应，仅异步传输归档日志，降低WAN延迟影响；配合LOG_ARCHIVE_DEST_n的DELAY属性（如DELAY=3600），可人为设置1小时延迟，防范误删/逻辑错误传播
- 禁用ARCHIVE_LAG_TARGET，改用Broker自动failover触发条件（如Transport Lag > 30秒且Apply Lag > 60秒），更贴近真实业务水位
故障切换与演练关键动作
自动切换≠无风险切换。生产中必须做到“可测、可控、可逆”：
- 每季度执行一次Switchover演练（主备角色互换），验证Broker配置与监听注册是否正常；切换前检查STANDBY_FILE_MANAGEMENT=AUTO、DB_FILE_NAME_CONVERT等参数是否生效
- 每年至少一次Failover实战（主库强制宕机），重点观测：应用连接池能否自动重连新主库、GSM或TNS别名是否指向正确SCAN IP、应用侧是否有未捕获的ORA-03113/ORA-12545错误
- 切换后立即执行SELECT * FROM V$DATAGUARD_STATS，确认transport lag与apply lag均为0；再查V$ARCHIVED_LOG确认最后归档序列号在备库已应用
