配置async模式的关键是主库log_archive_dest_2显式指定async、valid_for=(online_logfiles,primary_role)、db_unique_name一致，且备库监听必须含ur=a；任一缺失将导致状态为deferred或ora-16057。
直接结论：配置ASYNC模式的关键不是改一个参数，而是确保LOG_ARCHIVE_DEST_n中明确含ASYNC、VALID_FOR匹配主库角色、且备库监听支持UR=A——漏掉任一环，表面配置了ASYNC，实际可能卡在DEFERRED或报ORA-16057。
为什么LOG_ARCHIVE_DEST_2必须显式写ASYNC？
Oracle Data Guard默认不强制任何传输模式，LOG_ARCHIVE_DEST_n若未声明SYNC或ASYNC，会按底层传输服务（LGWR/ARCH）和Broker设置隐式推断，极易误入最高可用模式。最大性能模式唯一可靠的启用方式，就是手动指定ASYNC。
-
LOG_ARCHIVE_DEST_2='SERVICE=standby_db ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=standby_db'—— 这是主库上最简有效配置 - 不能写成
SYNC，也不能省略ASYNC；写成SYNC会导致主库事务等待备库确认，性能骤降 - 如果用Data Guard Broker管理，
EDIT DATABASE ... SET PROPERTY LogXptMode='ASYNC'会覆盖手动参数，需统一入口维护
VALID_FOR写错会导致归档根本不触发
VALID_FOR控制该归档目标在什么日志类型+数据库角色下生效。主库只产生ONLINE_LOGFILES，且只在PRIMARY_ROLE下发送日志。若误配为(STANDBY_LOGFILES,STANDBY_ROLE)，主库将完全忽略该DEST，ALTER SYSTEM SWITCH LOGFILE后查V$ARCHIVE_DEST_STATUS会发现STATUS为INACTIVE或ERROR。
- 主库必须用：
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) - 备库若配置
LOG_ARCHIVE_DEST_1本地归档，才用(ONLINE_LOGFILES,STANDBY_ROLE) -
DB_UNIQUE_NAME值必须与备库DB_UNIQUE_NAME参数完全一致（区分大小写），否则V$DATAGUARD_STATS里transport_lag持续增长，且SELECT DEST_ID, STATUS FROM V$ARCHIVE_DEST_STATUS中STATUS为ERROR
备库监听没配UR=A，主库连不上，状态永远是DEFERRED
主库LGWR进程要通过网络把redo推送到备库的LNS接收端，而Oracle默认监听拒绝来自主库的非受限连接。没有UR=A，备库监听直接拒绝连接，主库V$ARCHIVE_DEST_STATUS中对应DEST_ID的STATUS会是DEFERRED或ERROR，日志里反复出现TNS-12514或ORA-16057: DGID not found。
- 检查备库
$ORACLE_HOME/network/admin/tnsnames.ora中服务名条目，必须含(UR=A)： standby_db = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = standby-host)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = orcl) (UR=A)))- 重启备库监听：
lsnrctl reload，再查V$MANAGED_STANDBY，应能看到RFS进程状态为IDLE或RECEIVING
验证是否真跑在ASYNC模式，别只看参数
即使LOG_ARCHIVE_DEST_2写了ASYNC，若备库没启动Redo Apply、归档目录满、或网络抖动，主库仍可能因超时临时切换为本地归档，造成误判。必须结合动态视图确认实时行为。
- 查主库：
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 FROM V$MANAGED_STANDBY WHERE PROCESS IN ('RFS', 'MRP0')—— 至少要有RFS在RECEIVING，MRP0可选（异步模式不要求实时应用） -
V$DATAGUARD_STATS中transport_lag和apply_lag非零且波动是正常现象，不是故障；若长期为+00 00:00:00反而可疑（可能误配SYNC）
最容易被忽略的是：ASYNC模式下，主库不等备库，但备库自身状态（如磁盘满、DB_RECOVERY_FILE_DEST空间不足、ARCH进程卡住）会导致归档堆积、RFS停止接收，最终主库V$ARCHIVE_DEST_STATUS变成ERROR并开始报错。所以ASYNC不是“配完就不管”，而是要把备库的归档消费能力真正稳住。
