oracle 19c中默认日志传输模式为async，但必须显式配置log_archive_dest_2为async且valid_for、db_unique_name等参数严格匹配，否则主库会降级为sync导致阻塞；需通过v$archive_dest_status和v$managed_standby交叉验证transmit_mode=async且status=valid。
Oracle 19c 中默认的 Data Guard 日志传输模式是 ASYNC，但必须显式配置且依赖多个参数协同生效；不配或配错会导致归档失败、ARCH 进程卡住、备库日志停滞，甚至主库因归档无法完成而挂起（尤其当 log_archive_dest_2 不可用时）。
log_archive_dest_2 必须显式启用 ASYNC 并指定 service
log_archive_dest_2 是控制主库向备库发送重做日志的核心参数。只设 service=xxx 不够，必须明确加 async，否则 Oracle 默认按 SYNC 处理（即使文档说“默认 async”，实际行为受 valid_for 和角色影响）。
-
log_archive_dest_2='service=orcldg async valid_for=(online_logfiles,primary_role) db_unique_name=orcldg'—— 正确：指明仅在主库角色下对在线日志异步传输 - 漏掉
async：主库会尝试同步等待备库确认，若备库不可达或网络延迟高，LGWR可能阻塞，引发性能抖动甚至事务超时 -
valid_for写成(all_logfiles,all_roles)：可能导致备库自己归档时循环写入该路径，引发归档风暴 -
db_unique_name值必须与备库实际DB_UNIQUE_NAME完全一致（区分大小写），否则ALTER SYSTEM SWITCH LOGFILE后查v$archive_dest_status会显示ERROR
standby_file_management 必须设为 AUTO
物理备库启用日志应用（ALTER DATABASE RECOVER MANAGED STANDBY DATABASE）后，主库新增数据文件（如 CREATE TABLESPACE）需自动同步到备库。若 standby_file_management=MANUAL，备库会报 ORA-01111、ORA-01110 错误，MRP 进程中断。
- 执行
ALTER SYSTEM SET standby_file_management=AUTO SCOPE=BOTH;（主备库都设，但仅备库生效） - 设为
AUTO后，主库创建的数据文件会通过重做流传递，备库自动创建同名文件（路径需提前存在或用db_create_file_dest统一管理） - 若备库文件系统路径与主库不一致，需配合
DB_FILE_NAME_CONVERT参数映射，否则AUTO会直接失败
tnsnames.ora 和监听必须支持 UR=A
备库监听必须能接受来自主库的连接请求，且连接字符串中必须含 (UR=A)（Unrestricted），否则主库连不上备库的 LGWR 进程，log_archive_dest_2 状态始终为 DEFERRED 或 ERROR。
- 备库
tnsnames.ora中服务名条目要带(UR=A)：(CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = orcl) (UR=A)) - 主库的
tnsnames.ora里指向备库的别名（如ORCLDG）也必须包含该字段 - 监听器需加载静态注册：在
listener.ora的SID_LIST_LISTENER中添加备库的SID_DESC，GLOBAL_DBNAME设为备库的DB_UNIQUE_NAME（不是SERVICE_NAME） - 改完监听后必须
lsnrctl reload，不能只stop/start，否则静态注册不生效
验证 ASYNC 是否真正生效
光看参数没用，得从三处交叉验证：归档目标状态、归档日志传输记录、备库日志应用延迟。
- 主库查
SELECT STATUS, ERROR, TRANSMIT_MODE FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;——STATUS应为VALID，TRANSMIT_MODE为ASYNC - 主库查
SELECT NAME, DESTINATION, TRANSMIT_MODE FROM V$ARCHIVE_DEST WHERE DEST_ID = 2;—— 确认TRANSMIT_MODE显示ASYNC - 备库查
SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK# FROM V$MANAGED_STANDBY WHERE PROCESS IN ('RFS','MRP0');——RFS应持续接收新日志，MRP0应在应用；若SEQUENCE#长期不更新，说明传输卡在 RFS 层 - 注意：
V$DATAGUARD_STATS中的apply_lag和transport_lag单位是秒，但它们反映的是“最后一条日志”的延迟，不能代表实时吞吐能力
ASYNC 模式下最易被忽略的是网络抖动和防火墙策略：哪怕只丢一个 TCP 包，RFS 进程就可能 hang 住数分钟，ARCH 进程随之积压。建议在主备间用 tcpdump 抓包比对 LGWR → RFS 流量是否连续，而不是只依赖 Oracle 视图。
