最大保护模式下主库遇同步备库不可达会强制宕机保数据，非故障而是设计行为；最大可用模式则自动降级为异步传输，不报错但丧失零丢失能力。
最大可用（Maximum Availability）和最大保护（Maximum Protection）模式不能凭经验“选”，必须根据业务对停机容忍度和数据零丢失的刚性要求来决定——前者允许主库降级运行，后者强制主库宕机保数据。
最大保护模式下主库会自动 shutdown，这是设计行为不是故障
只要配置了 MAXIMUM PROTECTION，且任意一个同步备库（LOG_ARCHIVE_DEST_n 中启用 SERVICE=xxx LGWR SYNC AFFIRM）不可达（网络中断、备库宕机、Standby Redo Log 写满未清空），主库在下次 COMMIT 时就会报错 ORA-03172: STANDBY LOGFILE NOT AVAILABLE 并立即关闭实例。
- 这不是配置错误，是模式本身的设计约束
- 主库重启前必须先恢复备库连通性，并确认
V$ARCHIVE_DEST_STATUS.STATUS = 'VALID' - 没有“临时绕过”或“后台静默降级”的选项；
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION是不可逆的强保障机制
最大可用模式实际运行时可能动态降级为最大性能
当主库检测到所有配置的 SERVICE=xxx LGWR SYNC AFFIRM 目标均不可用（例如 STATUS = 'ERROR' 或超时未响应），它不会宕机，而是自动切换到异步传输，等效于 ASYNC NOAFFIRM 行为，此时 V$DATABASE.PROTECTION_MODE 仍显示 MAXIMUM AVAILABILITY，但实际已退化。
- 降级过程无告警、无日志明确提示“已降级”，需定期查
V$ARCHIVE_DEST_STATUS.ERROR和TRANSMIT_MODE - 恢复后不会自动切回同步：必须手动执行
ALTER SYSTEM SET log_archive_dest_2='SERVICE=xxx LGWR SYNC AFFIRM ...' SCOPE=BOTH并触发一次日志切换 - 如果只配了一个同步备库，该备库宕机期间主库虽能运行，但已失去零丢失能力——这点常被误认为“依然安全”
LGWR SYNC AFFIRM 与 LGWR SYNC NOAFFIRM 的关键区别在磁盘落盘确认
两者都属于同步传输，但 AFFIRM 要求备库将接收到的 redo 写入 Standby Redo Log 文件并完成 fsync，NOAFFIRM 只要求接收缓冲区写入即返回确认。Oracle 官方文档明确指出：NOAFFIRM 在备库断电场景下可能导致数据丢失。
-
MAXIMUM PROTECTION强制要求AFFIRM；MAXIMUM AVAILABILITY允许NOAFFIRM（FastSync），但不推荐用于核心系统 - 使用
NOAFFIRM时，V$ARCHIVE_DEST_STATUS.TRANSMIT_MODE显示SYNC，但DELAY_MINS和APPLIED_TIME可能明显滞后 - 验证是否真同步：在主库执行
ALTER SYSTEM SWITCH LOGFILE后，立刻查备库SELECT MAX(SEQUENCE#) FROM V$STANDBY_LOG，若值 ≥ 主库当前V$LOG.SEQUENCE#，才算真正落地
真正难处理的不是切换命令本身，而是两种模式对网络稳定性、备库 I/O 延迟、Standby Redo Log 大小和数量的隐性依赖——这些参数一旦没调好，MAXIMUM PROTECTION 会让主库频繁挂起，MAXIMUM AVAILABILITY 则会在你没注意时悄悄降级成裸奔状态。
