选错Data Guard保护模式会导致性能抖动、丢数据或停库；最大保护模式强制RPO=0但主库会停机，最大可用性模式自动降级保可用，最大性能模式优先响应速度允许秒级丢数据。
选错保护模式，轻则主库性能抖动，重则故障时丢数据甚至停库。 没有“通用最优解”，只有匹配业务 SLA 的配置 —— 关键看你要保数据、保可用，还是保响应速度。
最大保护模式：主库能停，数据不能丢
适用于金融核心账务、支付清算等绝对不允许 RPO=0 的场景。它强制 LGWR SYNC AFFIRM，事务提交前必须确认 redo 已落盘到至少一个备库的 standby redo log。一旦备库不可达（网络中断、备库宕机、监听异常），主库立即 shutdown，不是 hang 也不是降级 —— 这是设计行为，不是 bug。
- 必须配置至少两个物理备库，否则单点故障直接导致主库不可用
-
LOG_ARCHIVE_DEST_n中必须启用SYNC和AFFIRM，且备库需有standby redo log - 主库写入延迟直接受备库 IO 和网络 RTT 影响，TPS 明显下降，尤其在高并发小事务场景
- 切忌在测试环境只搭一个备库就开最大保护，上线后极易因备库维护触发主库停机
最大可用性模式：数据尽量不丢，主库尽量不停
这是生产环境最常被低估也最容易误配的模式。它和最大保护共用同一套传输参数（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是否持续归零 - 如果备库长期 lag > 5 秒，说明网络或 IO 瓶颈已存在，此时最大可用性 ≠ 实际可用性
最大性能模式：主库快，备库跟得上算赢
默认模式，也是绝大多数报表、分析、读写分离类系统的合理选择。主库事务提交只依赖本地 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 秒内
真正难的不是查文档配参数，而是把业务方说的“不能丢数据”翻译成可量化的 RPO/RTO，再映射到三种模式的行为边界。比如“交易完成后用户要立刻查到结果”，这本质是主库一致性问题，不是 Data Guard 能解决的；而“服务器断电后必须找回最后一笔充值”，才真正需要最大保护或最大可用性模式兜底。
