必须同时满足lgwr+sync+affirm三要素，且备库srl配置完备、net_timeout显式设置，否则实际退化为最高性能模式。
确认 log_archive_dest_2 是否真走 LGWR+SYNC+AFFIRM
最大可用性模式不是设个 PROTECTION_MODE 就生效的，它完全依赖 log_archive_dest_2 的实际传输行为。如果这里配错，主库会悄无声息退化为最高性能模式。
执行：SHOW PARAMETER log_archive_dest_2，输出里必须同时出现 LGWR、SYNC、AFFIRM —— 缺一不可。
- 出现
ARCH：说明走的是归档进程异步传输，哪怕写了SYNC也无效 - 出现
NOAFFIRM：RFS 只写文件系统缓存，断电即丢，不满足“提交前落盘”要求 - 常见假象：主库提交变慢 + 备库
v$archived_log有记录，但v$managed_standby查不到LGWR连接或RFS写SRL活动 → 实际根本没启用 LGWR 同步路径
备库必须有足够且可用的 Standby Redo Log
AFFIRM 的本质是强制 RFS 把重做写入 standby redo log 并刷盘。没有 SRL 或 SRL 不可用，AFFIRM 直接失败，主库要么挂起，要么自动降级。
- 组数：至少等于主库
v$log中的组数（例如主库 3 组 online redo log，备库至少建 3 组 SRL） - 大小：每组 SRL ≥ 主库最大 online redo log 文件大小（查
v$log.bytes） - 验证命令：
SELECT GROUP#, THREAD#, SEQUENCE#, ARCHIVED, STATUS FROM V$STANDBY_LOG；状态不能是UNASSIGNED - 建 SRL 示例：
ALTER DATABASE ADD STANDBY LOGFILE GROUP 4 '/u01/oradata/standby/srl04.log' SIZE 50M
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 自动将该 dest 降级为
ASYNC，主库继续提供服务；网络恢复后自动切回SYNC - 不设
NET_TIMEOUT是最大可用性配置中被忽略最多、后果最严重的一环
验证保护模式是否真正生效
配置完别只看 PROTECTION_MODE 显示 MAXIMIZE AVAILABILITY，那只是元数据。必须用真实行为验证：
- 查当前模式：
SELECT NAME, DATABASE_ROLE, PROTECTION_MODE FROM V$DATABASE - 模拟网络中断（如 iptables DROP），观察主库事务是否在
NET_TIMEOUT秒内继续提交（而非卡死） - 检查
v$archive_dest_status中该 dest 的STATUS和TRANSMIT_MODE是否随网络变化动态切换 - 切换前务必确认备库
v$managed_standby中有活跃的LGWR连接和RFS写SRL记录
最大可用性真正的复杂点不在参数拼写，而在于 LGWR/SRL/NET_TIMEOUT 三者必须同时在线且协同工作；任一环节掉链子，保护就失效了。
