Data Guard 保护模式一旦选择不当，往往会带来主库性能波动、故障时数据丢失，甚至直接导致数据库停机；最大保护模式强制实现 RPO=0，但主库可能因此中断服务，最大可用性模式会在异常时自动降级以保障业务可用，最大性能模式则优先保证事务响应速度，通常允许秒级数据丢失。
如果 Data Guard 保护模式选错，轻则主库性能抖动，重则在故障场景下丢数据，甚至触发停库。 实际上并不存在所谓“放之四海皆准”的最佳方案，真正合理的选择，取决于业务 SLA 的要求——核心在于你更看重数据零丢失、系统持续可用，还是数据库响应性能。
最大保护模式：主库可以停，数据绝不能丢
这种模式通常适用于金融核心账务、支付清算等对数据零丢失要求极高的业务场景，本质目标就是绝对保证 RPO=0，不接受任何数据偏差。它会强制启用 LGWR SYNC AFFIRM：在事务真正提交前，必须确认 redo 已成功写入至少一个备库的 standby redo log。一旦备库失联——例如网络中断、备库宕机，或监听服务异常——主库会立即 shutdown，不会 hang，也不会自动降级。这不是异常，也不是 bug，而是 Oracle Data Guard 最大保护模式的预期设计。
- 必须配置至少两个物理备库，否则一旦出现单点故障，主库可用性会被直接影响
LOG_ARCHIVE_DEST_n中必须启用SYNC和AFFIRM，同时备库需要配置standby redo log- 主库写入延迟会直接受到备库 IO 性能和网络 RTT 的影响，TPS 往往明显下降，尤其是在高并发、小事务场景下更明显
- 不要在测试环境仅部署一个备库就启用最大保护模式，否则上线后很容易因备库维护或短暂异常触发主库停机
最大可用性模式：尽量不丢数据，也尽量不停主库
这是 Oracle Data Guard 生产环境中最常见、也最容易被低估和误配置的保护模式。它与最大保护模式使用相同的传输参数（LGWR SYNC AFFIRM），但处理策略更加务实：当备库失联时，主库会自动降级为 MAXIMUM PERFORMANCE 模式继续对外提供服务，待连接恢复后再自动切回同步状态。
- 整个降级过程通常无需人工干预，但切换瞬间
PROTECTION_MODE在V$DATABASE中会短暂显示为RESYNCHRONIZATION，这属于正常现象，并非错误状态 - 仍然要求备库配置
standby redo log，否则 SYNC 无法真正生效，实际效果会退化为 ASYNC - 日常监控的重点不只是“当前是否处于 SYNC”，更要关注
SELECT * FROM V$DATAGUARD_STATS中的apply lag和transport lag是否能够持续接近 0 - 如果备库长期 lag > 5 秒，往往说明网络或 IO 已经存在瓶颈，此时所谓最大可用性，并不等于业务层面的真实可用性
最大性能模式：主库优先快，备库尽量跟上
这是 Oracle Data Guard 的默认模式，也是大多数报表系统、数据分析平台、读写分离架构中更合理的选择。主库事务提交只依赖本地 online redo log 写入，redo 通过 ARCH 或 LGWR ASYNC 以异步方式传输到备库，因此主库基本不受备库状态影响。
- 可以接受少量数据丢失（RPO 通常为秒级），典型风险场景是主库突然宕机，而最后几秒的 redo 尚未来得及传输到备库
LOG_ARCHIVE_DEST_n可使用ASYNC+NOAFFIRM，甚至允许通过ARCH进程替代LGWR，对网络带宽和链路质量的压力更小- 备库不一定需要
standby redo log（除非启用了实时应用real-time apply） - 常见误区是把“异步”直接等同于“不可靠”，其实只要网络稳定、归档路径空间充足、备库定期执行 recover，RPO 依然可以控制在 1~3 秒内
真正困难的地方，从来不是照着官方文档把 Data Guard 参数逐项配齐，而是要把业务口中的“不能丢数据”，准确转换成可量化的 RPO/RTO 指标，再进一步映射到三种保护模式各自的能力边界。比如，“交易完成后用户必须立即查询到结果”，本质上考验的是主库事务一致性与应用链路设计，这并不是 Data Guard 最擅长解决的问题；但如果需求变成“服务器断电后必须找回最后一笔充值记录”，那就完全不同了，这类场景真正需要依赖的，往往就是最大保护模式或最大可用性模式来兜底。
