最大性能模式必须显式配置LOG_ARCHIVE_DEST_n为ASYNC,漏写或误配SYNC会导致主库降级运行;需结合V$ARCHIVE_DEST_STATUS中TRANSMIT_MODE=ASYNC且STATUS=VALID验证,同时注意Broker会覆盖手动配置。
最大性能模式下,异步日志传输不是默认“开启”,而是依赖 LOG_ARCHIVE_DEST_n 中明确写出 ASYNC。漏写或误写为 SYNC 会导致主库实际运行在最高可用甚至最大保护模式,事务提交变慢甚至挂起。
常见错误配置:LOG_ARCHIVE_DEST_2='SERVICE=standby_db SYNC ...' 或 LOG_ARCHIVE_DEST_2='SERVICE=standby_db ...'(省略传输模式)。Oracle 12c 及以后版本中,ASYNC 是默认值,但仅当未指定 SYNC 或 LGWR 时才生效;一旦显式写了 LGWR,就必须同时指定 ASYNC 或 SYNC,否则报错 ORA-16025。
LGWR ASYNC 和 ARCH ASYNC 都合法,但行为不同:前者由 LGWR 触发 LNS 进程实时推送重做流,后者等 ARCn 归档完成后才传归档文件LGWR,必须配 STANDBY_REDO_LOGS,否则备库 RFS 写入失败,日志积压在主库 SGA 中VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) 必须匹配主库角色和日志类型,写成 (STANDBY_LOGFILES,STANDBY_ROLE) 会导致主库根本不发日志DB_UNIQUE_NAME 值需与备库实际 DB_UNIQUE_NAME 完全一致(区分大小写),否则 ALTER SYSTEM SWITCH LOGFILE 后查 V$ARCHIVE_DEST_STATUS 显示 STATUS = INVALID
只看参数配置不可靠。主库上执行 SELECT DEST_ID, STATUS, TRANSMIT_MODE, SYNCHRONIZATION_STATUS FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;,关键字段必须同时满足:
TRANSMIT_MODE 返回 ASYNC(不是 SYNC 或空)STATUS 为 VALID(不是 ERROR 或 DEFERRED)SYNCHRONIZATION_STATUS 为 NOT SYNCHRONIZED 或 SYNCHRONIZED 均可,但不能是 FAILED
备库上运行 SELECT PROCESS, STATUS, THREAD#, SEQUENCE# FROM V$MANAGED_STANDBY;,至少应看到 RFS 状态为 IDLE 或 ACTIVE;若启用了实时应用,还应有 MRP0;若只有 ARCH 进程在运行,说明主库走的是 ARCH 传输路径,不是 LGWR。
网络抖动或备库短暂不可达时,LOG_ARCHIVE_DEST_n 若未设重试机制,会快速进入 ERROR 状态并停止发送,导致归档堆积。这不是异步模式失效,而是配置缺失。
推荐加上重试控制:
REOPEN=60:失败后每 60 秒重试一次(默认 300 秒,太长)MAX_FAILURE=3:最多连续失败 3 次后暂停,避免无意义刷日志LOG_ARCHIVE_DEST_2='SERVICE=standby_db LGWR ASYNC REOPEN=60 MAX_FAILURE=3 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=standby_db'
注意:REOPEN 优先级高于 ALTERNATE;若同时配置,先重试主路径,失败达 MAX_FAILURE 次后才切备用路径。
如果启用 Broker(dgmgrl),所有保护模式和传输模式均由 Broker 统一管理。此时手动修改 LOG_ARCHIVE_DEST_n 中的 ASYNC 不生效,Broker 会按 EDIT DATABASE ... SET PROPERTY LogXptMode='ASYNC' 的值强制覆盖。
检查是否启用 Broker:
V$DATAGUARD_CONFIG,若有记录则 Broker 已启用dgmgrl /,输入 SHOW CONFIGURATION,若返回配置信息即确认启用SHOW DATABASE VERBOSE "primary_db",看 LogXptMode 字段是否为 ASYNC
混用 Broker 和手动参数极易引发冲突,尤其在 switchover 后部分参数被 Broker 自动重写,而 DBA 仍按旧配置排查问题——这是最常被忽略的复杂点。