最大性能模式是Oracle Data Guard默认保护模式，采用ASYNC异步传输，主库不等待备库确认即提交事务，性能影响最小但存在少量数据丢失风险（RPO>0）。
最大性能模式是 Oracle Data Guard 中默认且最轻量的保护模式，它允许主库在不等待备库确认的情况下提交事务，因此对主库性能影响最小，但存在少量数据丢失风险（RPO > 0）。如果你的业务能接受短时间内的数据丢失（例如报表库、测试环境、异地容灾场景），这个模式就是合理选择。
什么是最大性能模式？
最大性能模式使用异步重做传输（ASYNC），主库将重做日志写入本地 LOG_ARCHIVE_DEST_n 后立即提交，不阻塞用户事务。备库通过 ARCH 进程拉取归档日志，或通过 LNS（Log Network Server）进程推送，具体取决于配置方式。
关键点：它不要求备库实时应用，也不强制同步确认 —— 所以即使备库宕机、网络中断或归档积压，主库仍可正常运行。
LOG_ARCHIVE_DEST_n 必须设为 ASYNC
这是启用最大性能模式的核心配置项。错误地写成 SYNC 或漏掉 ASYNC 会导致实际运行在最高可用模式甚至最大保护模式，引发意外性能抖动或挂起。
- 主库上必须显式指定：
LOG_ARCHIVE_DEST_2='SERVICE=standby_db ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=standby_db' -
VALID_FOR参数不能写错，否则归档可能不触发；常见错误是写成(STANDBY_LOGFILES,STANDBY_ROLE)导致主库不发日志 - 确保
DB_UNIQUE_NAME与备库实际值完全一致（区分大小写），否则ALTER SYSTEM SWITCH LOGFILE后看不到归档传输日志 - 如果用了 Data Guard Broker，
EDIT DATABASE ... SET PROPERTY LogXptMode='ASYNC'会覆盖手动配置，需统一管理
如何验证是否真正在最大性能模式下运行？
仅看参数配置不够，必须结合动态视图确认当前行为。最容易被忽略的是：即使配置了 ASYNC，若备库处于 MOUNT 状态但未启动 Redo Apply，主库仍可能因归档目录满或网络超时而报错 ORA-16057: DGID not found 或 ORA-16714，这会让 DBA误以为“模式失效”。
- 查主库：
SELECT DEST_ID, STATUS, TRANSMIT_MODE, SYNCHRONIZATION_STATUS FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;——TRANSMIT_MODE应为ASYNC，STATUS应为VALID - 查备库：
SELECT PROCESS, STATUS, THREAD#, SEQUENCE# FROM V$MANAGED_STANDBY;—— 至少应看到ARCH或RFS在运行，MRP0（Redo Apply）可选，但若启用则说明在实时应用 - 观察
V$DATAGUARD_STATS中的apply_lag和transport_lag，最大性能模式下这两个值通常非零且随负载波动，不是 bug 是预期行为
最大性能模式下的典型陷阱
很多人以为只要设了 ASYNC 就万事大吉，但实际运维中几个细节常导致“伪最大性能”：
- 操作系统级网络缓冲区太小（如
net.core.rmem_max/net.core.wmem_max未调优），导致 LNS 进程频繁重传，间接拖慢主库 LGWR；尤其在高吞吐 OLTP 场景下，这种延迟会被误判为“同步卡顿” - 备库归档目录空间不足，主库会因无法归档而 hang 在
ARCH进程上，表现为log file sync等待飙升 —— 此时已不是 Data Guard 模式问题，而是基础运维疏漏 - 使用了
DELAY属性（如DELAY=3600），虽仍属最大性能范畴，但人为引入延迟，和“高性能”初衷相悖，需确认是否真有此业务需求 - 主库启用了
ENABLE BLOCK CHANGE TRACKING但备库未配对应参数，可能在切换后引发块修复异常，虽不影响当前模式运行，但埋下故障转移隐患
真正用好最大性能模式，不在于参数写得有多快，而在于理解它“不保证实时、不承诺一致、但保障主库不死”的设计哲学。任何试图在该模式下追求零延迟或强一致性，本质上都是方向性错误。
