Oracle Data Guard三种保护模式如何选择？

选错Data Guard保护模式会导致性能抖动、丢数据或停库；最大保护模式强制RPO=0但主库会停机，最大可用性模式自动降级保可用，最大性能模式优先响应速度允许秒级丢数据。

选错保护模式，轻则主库性能抖动，重则故障时丢数据甚至停库。 没有“通用最优解”，只有匹配业务 SLA 的配置 —— 关键看你要保数据、保可用，还是保响应速度。

最大保护模式：主库能停，数据不能丢

适用于金融核心账务、支付清算等绝对不允许 RPO=0 的场景。它强制 LGWR SYNC AFFIRM，事务提交前必须确认 redo 已落盘到至少一个备库的 standby redo log。一旦备库不可达（网络中断、备库宕机、监听异常），主库立即 shutdown，不是 hang 也不是降级 —— 这是设计行为，不是 bug。

1. 必须配置至少两个物理备库，否则单点故障直接导致主库不可用
2. LOG_ARCHIVE_DEST_n 中必须启用 SYNC 和 AFFIRM，且备库需有 standby redo log
3. 主库写入延迟直接受备库 IO 和网络 RTT 影响，TPS 明显下降，尤其在高并发小事务场景
4. 切忌在测试环境只搭一个备库就开最大保护，上线后极易因备库维护触发主库停机

最大可用性模式：数据尽量不丢，主库尽量不停

这是生产环境最常被低估也最容易误配的模式。它和最大保护共用同一套传输参数（LGWR SYNC AFFIRM），但行为上更务实：当备库失联时，主库自动降级为 MAXIMUM PERFORMANCE 继续服务，待连接恢复再自动切回同步。

1. 降级过程无需人工干预，但切换瞬间的 PROTECTION_MODE 在 V$DATABASE 中会短暂显示为 RESYNCHRONIZATION，不是错误状态
2. 仍要求备库配置 standby redo log，否则 SYNC 无法生效，实际退化为 ASYNC
3. 日常监控重点不是“是否 SYNC”，而是 SELECT * FROM V$DATAGUARD_STATS 中的 apply lag 和 transport lag 是否持续归零
4. 如果备库长期 lag > 5 秒，说明网络或 IO 瓶颈已存在，此时最大可用性 ≠ 实际可用性

最大性能模式：主库快，备库跟得上算赢

默认模式，也是绝大多数报表、分析、读写分离类系统的合理选择。主库事务提交只依赖本地 online redo log 写入，redo 通过 ARCH 或 LGWR ASYNC 异步传到备库，主库完全不受备库状态影响。

1. 可接受少量数据丢失（RPO 通常为秒级），典型风险是主库突崩且最后几秒 redo 尚未传到备库
2. LOG_ARCHIVE_DEST_n 可用 ASYNC + NOAFFIRM，甚至允许用 ARCH 进程代替 LGWR，对网络带宽压力小
3. 备库无需 standby redo log（除非启用实时应用 real-time apply）
4. 容易踩的坑：误以为 “异步 = 不可靠”，其实只要网络稳定、归档路径充足、备库定期 recover，RPO 仍可控制在 1~3 秒内

真正难的不是查文档配参数，而是把业务方说的“不能丢数据”翻译成可量化的 RPO/RTO，再映射到三种模式的行为边界。比如“交易完成后用户要立刻查到结果”，这本质是主库一致性问题，不是 Data Guard 能解决的；而“服务器断电后必须找回最后一笔充值”，才真正需要最大保护或最大可用性模式兜底。