配置多个备库时，必须为每个LOG_ARCHIVE_DEST_n设置唯一编号并显式启用对应LOG_ARCHIVE_DEST_STATE_n；LGWR模式下备库需有可写的SRL；SYNC/ASYNC混用时事务行为由保护模式决定；监控应聚焦V$ARCHIVE_DEST_STATUS等动态视图。
LOG_ARCHIVE_DEST_n 配置多个备库目的时，必须用不同编号且显式启用
oracle dg 不支持“自动负载均衡”或“主备自动切换式多路传输”，所谓多路，是指向多个独立备库并行发送重做日志，而非对单个备库做冗余链路。关键在于每个 log_archive_dest_n 必须使用唯一编号（如 log_archive_dest_2、log_archive_dest_3），且对应状态参数 log_archive_dest_state_n 必须设为 enable，否则该路径不会参与传输。
常见错误是只配了多个 LOG_ARCHIVE_DEST_n，但没配或错配 LOG_ARCHIVE_DEST_STATE_n，结果只有第一个生效；或者误以为 ALTERNATE 属性能实现“主备自动 fallback”，其实它仅在当前目的连续失败达 MAX_FAILURE 次后才启用备用目的，不是实时冗余。
LOG_ARCHIVE_DEST_2='SERVICE=stby1 LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=stby1'LOG_ARCHIVE_DEST_3='SERVICE=stby2 LGWR SYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=stby2'ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=enable SCOPE=BOTH;ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_3=enable SCOPE=BOTH;
LGWR 传输模式下，备库必须有 Standby Redo Log（SRL）且目录可写
如果用 LGWR（无论 SYNC 还是 ASYNC）传输，备库没有 SRL 或 SRL 所在目录不可写，RFS 进程会静默失败，日志堆积在主库的 ARCH 目录，但 V$ARCHIVED_LOG 看似正常，V$DATAGUARD_STATS 中 apply_lag 却持续增大——这是最隐蔽的坑。
检查点：登录备库执行 SELECT * FROM V$STANDBY_LOG;，若返回空或状态为 UNASSIGNED，说明 SRL 未创建或未激活；确认 STANDBY_FILE_MANAGEMENT=AUTO，且 DB_CREATE_FILE_DEST 或显式指定的 SRL 路径存在且 Oracle 用户有写权限。
- SRL 组数建议比主库 Online Redo Log 组数多一组（例如主库 3 组，备库建 4 组 SRL）
- 每组 SRL 成员大小必须 ≥ 主库对应 Online Redo Log 组最大成员大小
- 不要依赖
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE自动创建 SRL，它只在首次启动时尝试，失败后不再重试
同步（SYNC）与异步（ASYNC）混用时，主库事务提交行为取决于最小可用 SYNC 目的
主库上同时配置了 LGWR SYNC 和 LGWR ASYNC 目的，并不意味着“部分同步、部分异步”。实际行为由 DG 保护模式决定：MAXIMUM PROTECTION 要求所有 SYNC 目的都写入成功；MAXIMUM AVAILABILITY 允许一个 SYNC 目的失败后降级为异步；MAXIMUM PERFORMANCE 则完全忽略 SYNC 设置，按异步处理。
也就是说，如果你只想要同城强一致 + 异地异步容灾，必须把同城备库配成 LGWR SYNC 并设置保护模式为 MAXIMUM AVAILABILITY，异地备库配成 LGWR ASYNC；若误设为 MAXIMUM PROTECTION，同城网络抖动会导致主库实例直接 shutdown。
- 查看当前模式：
SELECT PROTECTION_MODE, PROTECTION_LEVEL FROM V$DATABASE; - 切换模式需先停用 DG Broker（如有），再用
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {AVAILABILITY|PROTECTION|PERFORMANCE}; -
LGWR SYNC的NET_TIMEOUT建议设为 30–60 秒，太小易误判网络波动，太大拖慢事务响应
多路传输下的性能与监控盲区
主库 LGWR 本身不直传，而是由多个 LNSn 进程分别服务不同目的。当配置 3 个备库时，主库会启动至少 3 个 LNS 进程（每个 instance 对应一组），它们共享 SGA 日志缓冲区，但各自走独立 Oracle Net 连接。这意味着网络带宽、远端监听器并发连接数、备库 RFS 进程处理能力都会成为瓶颈，而 V$SESSION 中只显示 LNSn 进程名，不体现具体服务哪个目的。
真正有效的监控点不是看“是否归档”，而是查：V$ARCHIVE_DEST_STATUS 中 STATUS 是否为 VALID、ERROR 列是否为空；V$MANAGED_STANDBY 中各 LNS/RFS 进程的 STATE 和 SECONDS_IN_WAIT；以及主库 alert.log 里是否有 LNSn started 或 error 1031（密码文件失效）类报错。
- 不要依赖
ARCHIVED_THREAD#和ARCHIVED_SEQ#判断传输进度，它们只反映本地归档完成，不反映远程接收 - 多路场景下，
LOG_ARCHIVE_DEST_n的REOPEN值建议设为 300（5 分钟），避免频繁重连冲击网络 - 若某备库长期延迟，优先查其 RFS 进程是否卡在
WAITING FOR REDO，而非主库 LNS 是否断开
多路重做传输的可靠性不来自“数量堆砌”，而来自每个链路的独立可观测性与故障隔离能力。最容易被忽略的是 SRL 的存在性验证和 LOG_ARCHIVE_DEST_STATE_n 的显式 enable，这两处出问题，再多的目的配置也形同虚设。
