最大可用性模式需同时满足lgwr+sync+affirm三要素，并配置srl、net_timeout及网络链路，缺一则退化为最高性能模式。
最大可用性模式不是设个参数就生效的，它必须同时满足 lgwr + sync + affirm 三要素，且主备库网络链路、srl 配置、net_timeout 缺一不可，否则实际运行中会悄悄退化为最高性能模式。
检查并强制启用 LGWR + SYNC + AFFIRM 组合
最大可用性要求重做日志在事务提交前，必须由 LGWR 进程实时同步写入备库的 standby redo log（SRL），归档进程（ARCH）做不到这点。
- 执行
SHOW PARAMETER log_archive_dest_2，确认输出中包含LGWR SYNC AFFIRM—— 如果出现ARCH或NOAFFIRM，立刻修正 - 典型正确配置：
LOG_ARCHIVE_DEST_2='SERVICE=standby LGWR SYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=standby' - 常见错误现象：主库提交变慢但备库
v$archived_log有记录，而v$managed_standby查不到LGWR连接或RFS写 SRL 的活动 → 说明根本没走 LGWR 同步路径
确保备库已创建足够数量和大小的 Standby Redo Log
RFS 进程只有写入 SRL 才算完成 AFFIRM 落盘；如果 SRL 不存在或空间不足，AFFIRM 会失败，主库可能挂起或自动降级。
- 备库 SRL 组数至少 ≥ 主库 Online Redo Log 组数（例如主库有 3 组，备库至少建 3 组 SRL）
- SRL 单组大小 ≥ 主库最大 Online Redo Log 文件大小（查
v$log中BYTES列） - 建 SRL 命令示例：
ALTER DATABASE ADD STANDBY LOGFILE GROUP 4 '/u01/oradata/standby/srl04.log' SIZE 50M; - 验证是否生效：
SELECT GROUP#, THREAD#, SEQUENCE#, ARCHIVED, STATUS FROM V$STANDBY_LOG;，状态不能是UNASSIGNED
必须设置 NET_TIMEOUT 防止单点故障拖垮主库
默认情况下，主库会无限等待备库响应。一旦网络抖动、SRL 满或备库宕机，所有事务卡住 —— 这在生产环境不可接受。
-
NET_TIMEOUT必须显式设置（单位秒），推荐值 20～30 秒：ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=standby LGWR SYNC AFFIRM NET_TIMEOUT=30 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=standby'; - 超时后，Oracle 自动将该
log_archive_dest_n降级为异步（ASYNC），主库继续提供服务，待网络恢复再自动切回SYNC - 不设
NET_TIMEOUT是最大可用性配置中最常被忽略、也最危险的遗漏点
验证保护模式是否真正生效
配置完别急着切业务，用真实场景验证行为是否符合预期：
- 查当前模式：
SELECT NAME, DATABASE_ROLE, PROTECTION_MODE, PROTECTION_LEVEL FROM V$DATABASE;，PROTECTION_MODE和PROTECTION_LEVEL都应显示MAXIMUM AVAILABILITY - 模拟备库宕机或断网：停掉备库监听或拔网线，观察主库是否仍可提交（
INSERT; COMMIT;不卡）、v$archive_dest_status中该 dest 的STATUS是否变为DEFERRED、ERROR列是否提示超时 - 恢复网络后，检查
v$archive_dest_status是否自动恢复为VALID，且RECOVERY_MODE变回MANAGED REAL TIME APPLY
真正难的不是写对那几行参数，而是让 LGWR、SYNC、AFFIRM、NET_TIMEOUT、SRL 这五个环节在主备两端严丝合缝地咬合运转；任意一个松动，最大可用性就只剩名字了。
