Maximum Protection模式必须在明确要求“绝对零丢失”且能接受主库主动宕机时启用，如金融核心账务系统；其要求LGWR同步写入至少一个备库的standby redo log并确认，否则主库立即shutdown abort，依赖SYNC+AFFIRM+standby redo log三要素缺一不可。
选错保护模式，轻则丢数据，重则主库停摆——不是配置问题，而是业务sla没对齐。
Maximum Protection 模式什么时候必须用？
只有在明确要求“绝对零丢失”且能接受主库主动宕机风险时才启用。比如金融核心账务系统、监管强要求的实时清算场景。
- 主库事务提交前，
LGWR必须收到至少一个备库的standby redo log写入确认，否则主库直接shutdown abort - 必须配置
SYNC+AFFIRM+standby redo log，缺一不可；LOG_ARCHIVE_DEST_2中漏掉任一参数都会降级失败 - 单备库部署下极不推荐：一旦该备库网络抖动或宕机，主库立刻不可用；Oracle 官方建议至少配 2 个同步备库
- 常见错误现象：
ORA-16139: media recovery required或主库日志里反复出现LGWR: Standby redo logfile not available
Maximum Availability 是多数生产环境的真实选择
它不是“折中”，而是有状态的弹性保障——正常时等同 Maximum Protection，异常时自动切到 Maximum Performance，不中断业务。
- 依赖
NET_TIMEOUT参数（默认 30 秒）：主库等待备库响应超时后，自动降级为异步传输，事务继续提交 - 仍需
SYNC+AFFIRM+standby redo log，但允许短暂容忍网络分区 - 适合电商订单、支付清分、CRM 等“不能丢数据，但也不能停服务”的场景
- 容易踩的坑：
LOG_ARCHIVE_DEST_n中写错DB_UNIQUE_NAME，或备库未开启FORCE LOGGING，会导致降级后无法自动回切
Maximum Performance 不是“不保护”，而是明确接受 RPO > 0
它是默认模式，但被误用最多——不是性能好就该用，而是你得确认业务能承受秒级甚至分钟级数据丢失。
- 主库只等本地
online redo log写入完成即返回，ARCH或LGWR ASYNC后续发日志到备库 - 参数只需
ASYNC+NOAFFIRM，standby redo log非必需，但强烈建议配置，否则备库只能应用归档日志，延迟更高 - 典型适用：报表库、测试环境、日志类非关键业务；或主备跨地域（如上海—新加坡）且带宽受限
- 性能影响小 ≠ 安全风险低：若主库崩溃且备库尚未收到最后几个归档日志，这部分事务永久丢失；
V$ARCHIVED_LOG的APPLIED列长时间为NO就是预警信号
切换前必须验证的三件事
改模式不是执行一条 ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE ... 就完事。
- 先查当前状态：
SELECT PROTECTION_MODE, PROTECTION_LEVEL FROM V$DATABASE；PROTECTION_LEVEL为RESYNCHRONIZATION表示尚未完成同步，切模式会失败 - 确认备库已应用所有日志：
SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG WHERE APPLIED='YES'对比主库V$LOG_HISTORY，差值 ≤ 1 才安全 - 检查
LOG_ARCHIVE_DEST_2是否启用：SELECT DESTINATION, STATUS, TRANSMIT_MODE, AFFIRM, SYNC FROM V$ARCHIVE_DEST WHERE DEST_ID = 2；STATUS必须为VALID，否则切模式报ORA-16661
真正难的不是命令怎么敲，而是把“RPO=0”“RTOSYNC 还是 ASYNC、要不要强制 AFFIRM、备库到底该放同城还是异地——技术参数背后全是业务契约。
