最大可用模式在备库或网络异常时自动降级为最大性能模式以保障主库可用性；切换需确认备库standby redo log就绪、MRP0进程运行，且主库OPEN状态，命令为ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE，并同步更新DG Broker的LogXptMode为ASYNC。
最大可用模式（MAXIMUM AVAILABILITY）和最大性能模式（MAXIMUM PERFORMANCE）不是“选哪个更好”，而是“在什么条件下必须切、怎么切才不中断业务”。核心判断是：只要备库不可靠或网络抖动频繁，就该用最大性能；只要能接受轻微延迟且要求零丢失（故障切换时），才考虑最大可用。
什么时候必须切到最大性能模式
主库出现 log file sync 等待飙升、TPS明显下降、或备库反复断连（如日志传输失败持续超过 NET_TIMEOUT 设置值），说明当前最大可用模式已无法稳定维持同步。此时不主动切，主库可能因超时自动降级，但降级过程伴随隐式重连开销和短暂事务阻塞。
-
NET_TIMEOUT默认是30秒，但实际建议设为10–15秒——太长会让主库卡更久，太短容易误判 - 切换前确认备库的
standby redo log已创建且大小/组数匹配主库，否则即使切过去也无法真正同步 - 如果备库处于
APPLYING ARCHIVE LOG状态而非实时应用（即MRP0进程未运行），强行切最大可用会立即报错ORA-16826: unable to apply redo
从最大可用切最大性能的实操要点
切换本身只需一条命令，但生效前提常被忽略：主库必须处于 OPEN 状态（无需 MOUNT），且备库不能处于 READ ONLY WITH APPLY 的 ADG 模式下执行该操作——否则会报 ORA-16625: cannot reach database。
- 先在主库执行：
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE; - 立刻检查
V$DATAGUARD_CONFIG和V$ARCHIVE_DEST_STATUS，确认目标LOG_ARCHIVE_DEST_n的STATUS变为VALID且TRANSMISSION_MODE显示ASYNC - 若使用
DG Broker，还需同步更新：EDIT DATABASE 'primary_db' SET PROPERTY LogXptMode='ASYNC'; - 切完后观察
V$SESSION_EVENT中log file sync平均等待时间是否回落至 1–3ms（原最大可用下常达 5–15ms）
反过来切回最大可用的风险点
这不是“恢复设置”那么简单。最大可用要求同步写入 + 落盘确认（SYSLOG 级别的 AFFIRM），一旦网络或备库 I/O 出现瞬时抖动，主库就会卡在 commit 上——尤其对高并发小事务场景（如 OLTP）极其敏感。
- 必须提前验证备库的
standby redo log是否正在被MRP0进程实时应用（查V$MANAGED_STANDBY中PROCESS=MRP0 且STATUS=APPLYING_LOG） -
LOG_ARCHIVE_DEST_n必须显式配置SYNC AFFIRM，不能只写SYNC—— 缺少AFFIRM会导致切过去后实际仍是异步行为 - 切之前关闭所有长事务（如批量导入），否则切换瞬间可能触发
ORA-16820: standby database is no longer receiving redo并回滚整个操作 - 切完后用
SELECT * FROM V$DATAGUARD_STATS WHERE NAME LIKE '%transport%';核对transport lag是否稳定在 0 或极低值（
真正难的从来不是命令敲得对不对，而是你有没有在切之前看清 V$DATAGUARD_STATUS 里最近三条错误是不是都跟网络超时或备库 I/O 延迟有关——这些才是决定要不要切、以及切了能不能稳住的唯一依据。
