MAXIMUM AVAILABILITY 是 Oracle Data Guard 中兼顾数据安全与业务连续性的折中模式，要求主库提交前将 redo 同时写入本地日志和至少一个备库的备用重做日志，但不等待应用完成；备库不可用时主库自动降级为 MAXIMUM PERFORMANCE 模式。
什么是 MAXIMUM AVAILABILITY 模式
MAXIMUM AVAILABILITY 是 Oracle Data Guard 三种保护模式中兼顾数据安全与业务连续性的折中选择。它要求主库事务提交前，必须将 redo 写入本地联机日志 且 至少一个备库的备用重做日志（standby redo log），但不强制等待备库应用（apply）完成。主库不会因备库短暂不可用而宕机，但会降级为 MAXIMUM PERFORMANCE 模式运行，直到备库恢复同步能力。
配置前必须满足的物理条件
缺一不可，否则 ALTER DATABASE SET STANDBY TO MAXIMIZE AVAILABILITY 会报错或静默失败：
- 主库和备库都已启用
FORCE LOGGING（不是可选，是硬性前提） - 备库已创建并挂载（
STARTUP MOUNT），且存在至少一组 standby redo log，大小、组数需与主库联机日志对齐（例如主库有 3 组 × 200MB，则备库 standby redo log 也应 ≥3 组 × 200MB） - 主库
LOG_ARCHIVE_DEST_2（指向备库）必须启用SYNC+VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)，且DB_UNIQUE_NAME正确指向备库配置 - 主库
LOG_ARCHIVE_CONFIG必须包含主备双方的DB_UNIQUE_NAME，例如：'DG_CONFIG=(primary_db,standby_db)'
执行 ALTER DATABASE SET STANDBY TO MAXIMIZE AVAILABILITY 的时机和风险
这条命令只在主库上执行，且必须在 Data Guard 配置已启动、日志传输正常后进行。常见错误现象包括：
-
ORA-16661: the standby database needs to be enabled：备库未在 DGMGRL 中启用（ENABLE DATABASE 'standby_db'）或未启动到 MOUNT 状态 -
ORA-16826: unable to apply redo：备库虽然挂载，但 standby redo log 缺失或大小不匹配，导致无法接收 SYNC 日志 - 命令成功但实际未生效：检查
V$DATABASE.PROTECTION_MODE是否真为MAXIMUM AVAILABILITY，而非仍显示MAXIMUM PERFORMANCE—— 这通常意味着LOG_ARCHIVE_DEST_2的SYNC属性未生效（比如被DELAY或ASYNC覆盖）
执行后，主库 LGWR 进程会直接网络传输 redo 到备库 SRL，延迟比 ARCH 进程方式低得多，但对网络稳定性更敏感。一旦网络抖动超 30 秒（默认 NET_TIMEOUT），主库会自动切换为最大性能模式，并写入 alert 日志。
验证和持续监控的关键点
配置不是一次性的，需要确认日志是否真以 SYNC 方式传输并被备库接收：
- 查主库：
SELECT DESTINATION, TRANSMIT_MODE, AFFIRM, VALID_FOR FROM V$ARCHIVE_DEST WHERE DEST_ID = 2;——TRANSMIT_MODE应为SYNC，AFFIRM应为YES - 查备库：
SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME, APPLIED FROM V$ARCHIVED_LOG WHERE STANDBY_DEST = 'YES' ORDER BY SEQUENCE# DESC FETCH FIRST 5 ROWS ONLY;——APPLIED字段应为YES，且最新几条日志的NEXT_TIME与当前时间差值应在秒级 - 查主库 alert.log：搜索
Media Recovery Waiting for thread或Standby redo log selected for online，确认备库正在实时接收 SRL
真正容易被忽略的是：MAXIMUM AVAILABILITY 模式下，备库的 REDO_TRANSPORT_USER（如使用密码文件认证）权限必须包含 SYSOPER，否则 LGWR 无法建立 SYNC 连接，主库会回退到 ASYNC 传输，但不会报错，只在 trace 文件里留下线索。
