最大保护模式适用于绝对不容忍事务丢失的场景，如金融核心账务系统，要求至少两个备库在线且主库收到LGWR SYNC AFFIRM确认才允许commit，否则主库挂起。
最大保护模式适合什么场景
最大保护模式（MAXIMIZE PROTECTION）只在你绝对不能容忍任何已提交事务丢失时才用，比如金融核心账务系统。它要求至少两个备库在线，且主库必须收到至少一个备库的 LGWR SYNC AFFIRM 确认才允许 commit。一旦所有参与的备库都不可用（网络中断、备库宕机、standby redo log 写满未清空），主库会直接挂起，拒绝新事务。
常见错误现象：ORA-16136: Data Guard broker operation in progress 或主库出现大量 log file switch (archiving needed) 等待，其实是 LGWR 被卡在等待 AFFIRM 响应。
- 必须提前配置至少两个备库，单备库无法启用该模式
- 备库的
standby_redo_log大小和组数要 ≥ 主库 online redo log，否则 AFFIRM 会失败 - 主库
log_archive_dest_2必须带SYNC AFFIRM，且VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) - 切换前需停库到
MOUNT状态，执行alter database set standby database to maximize protection
最高可用性模式为什么更常用
最高可用性模式（MAXIMIZE AVAILABILITY）是生产环境最常选的折中方案：正常时等 LGWR SYNC AFFIRM，确保零丢失；当备库临时不可达（如网络抖动、维护重启），主库自动降级为异步传输，继续提供服务，恢复后自动追平。
它对网络稳定性要求没那么苛刻，但依然需要备库开启 FLASHBACK DATABASE 和配置足够大的 standby_redo_log，否则故障恢复时可能无法做快速 failover。
- 主库参数
log_archive_dest_2同样要设为LGWR SYNC AFFIRM，但允许短时断连 - 备库角色切换后，其
log_archive_dest_2需反向指向原主库，并保持相同 SYNC/AFFIRM 设置 - 切模式前必须确保主备双方
DB_UNIQUE_NAME在log_archive_config中双向声明 -
select protection_mode, protection_level from v$database返回MAXIMUM AVAILABILITY才算生效，不是只改参数就完事
最大性能模式真能随便用吗
最大性能模式（MAXIMIZE PERFORMANCE）默认就是它，主库用 LGWR ASYNC 或 ARCH 传日志，不等备库响应。看起来“最省心”，但实际隐患不少：主库 crash 后，可能丢失最近几秒甚至几十秒的归档间隙数据；备库 apply lag 可能长期累积，导致 switchover 时间不可控。
容易被忽略的是：即使选这个模式，也得保证 standby_redo_log 存在且大小合理——否则备库从 MANAGED RECOVERY 切到 READ ONLY（即 ADG）时会报 ORA-01153: an incompatible media recovery is active。
- 主库
log_archive_dest_2应设为LGWR ASYNC，避免误配成 SYNC 导致性能陡降 - 备库必须运行在
OPEN READ ONLY WITH APPLY状态才能启用 ADG，光靠RECOVER MANAGED STANDBY DATABASE不够 - 监控关键视图：
v$archive_dest_status查传输状态，v$managed_standby看 MRPO（应用延迟），别只盯v$dataguard_stats里的apply_lag
切换保护模式时最易踩的坑
模式切换不是改个参数再查一下 v$database 就算完。真正卡住的地方往往在底层同步机制没对齐：比如主库启了 SYS.AUDIT_TRAIL 但备库没开对应审计目录权限，切 MAXIMIZE PROTECTION 时会因 audit write 失败导致 AFFIRM 超时；又或者 CDB/PDB 环境下，只改了 CDB 的 log_archive_dest_2，忘了在 PDB 内执行 ALTER PLUGGABLE DATABASE ... SAVE STATE 持久化配置。
另一个隐形雷区是密码文件：主备库 orapw<sid> 必须完全一致，且包含所有 SYSDBA 用户；如果用了 Oracle Wallet 或外部认证，remote_login_passwordfile=EXCLUSIVE 这个参数必须两边严格匹配，否则 DGMGRL 连不上备库，broker 会静默失败。
- 切模式前先确认
v$archive_dest中目标DEST_ID=2的STATUS是VALID，不是DEFERRED或INACTIVE - 主库执行
alter database set standby database to maximize ...之前，备库必须处于MOUNT状态，且open_mode不能是READ ONLY - 使用
DGMGRL切换时，EDIT DATABASE ... SET PROPERTY LogXptMode修改的是传输方式，不是保护级别——后者必须用 SQL 命令
MAXIMIZE PERFORMANCE，后续加专线、上双备库后，也能平滑升到 AVAILABILITY。关键是每次变更前，把 standby redo log 容量、密码文件一致性、broker 配置同步这三件事亲手核一遍——其余都是纸面功夫。 
