根本原因是LOG_ARCHIVE_DEST_STATE_n被设为DEFER或ALTERNATE，或ARCn资源被抢占；SYNC模式下任一目标未完成即阻塞COMMIT；VALID_FOR和REOPEN等参数配置不当会导致链路静默失效。
LOG_ARCHIVE_DEST_n 配置多个备库时，为什么总有一个不接收日志？
根本原因通常是 log_archive_dest_state_n 被设为 defer 或 alternate，但没配好触发逻辑；或者主库归档进程（arcn）资源被抢占，优先级没显式控制。
-
LOG_ARCHIVE_DEST_n必须配SYNC/ASYNC+VALID_FOR，否则 RFS 进程在备库可能不启动 - 多个
LOG_ARCHIVE_DEST_n共享同一组 ARCn 进程，默认按配置顺序尝试归档，失败后才轮到下一个 —— 不是并行推送 - 如果某个备库网络延迟高或磁盘慢，ARCn 会卡住，拖慢所有目标；建议用
DELAY参数隔离慢备库，避免阻塞快备库 - 检查
V$ARCHIVE_DEST_STATUS中的STATUS和ERROR字段，比看告警日志更快定位卡点
ASYNC 和 SYNC 混配多个备库，事务提交会不会被拖慢？
会，只要有一个 LOG_ARCHIVE_DEST_n 设了 SYNC，主库 COMMIT 就必须等它写完 standby redo log 才返回 —— 即使其他都是 ASYNC。这不是“多数派”逻辑，而是“任一 SYNC 目标”的强依赖。
- 确认
LOG_ARCHIVE_DEST_n的SYNC是真同步（AFFIRM）还是仅传输（NOAFFIRM）；后者不等写盘，延迟低但有丢数据风险 - 生产环境慎用多个
SYNC；若需多地强一致，应考虑使用 Oracle Data Guard Broker 的Fast-Start Failover，而非靠多 SYNC 归档硬扛 - 用
LOG_ARCHIVE_DEST_n的REOPEN参数控制重试间隔，避免瞬断引发频繁报错和日志刷屏
如何让主库只向指定备库传归档，而不是全量广播？
靠 VALID_FOR 参数过滤，不是靠注释或删配置。Oracle 不会自动跳过未启用的 LOG_ARCHIVE_DEST_n，只要状态是 ENABLE，ARCn 就会尝试连接。
-
VALID_FOR=(ONLINE_LOGFILE,PRIMARY_ROLE)表示只在主库角色、且归档联机日志时生效；备库切为主后，该路径自动失效 - 想实现“A 备库只收主库日志，B 备库只收 A 的日志”，得在 A 上配
LOG_ARCHIVE_DEST_2指向 B，并设VALID_FOR=(STANDBY_LOGFILE,STANDBY_ROLE) - 误删
LOG_ARCHIVE_DEST_n后忘记执行ALTER SYSTEM SET LOG_ARCHIVE_DEST_n='' SCOPE=BOTH，残留空值仍会被 ARCn 扫描，导致 ORA-16057 错误
归档目标太多导致主库 LGWR 压力大，有没有轻量替代方案？
有，但得接受异步性和额外组件。直接堆 LOG_ARCHIVE_DEST_n 是最重的方式，LGWR/ARCn 要维护多个 TCP 连接、序列号、确认包，CPU 和网络开销线性增长。
- 用
LOG_ARCHIVE_DEST_n+LOCATION=SERVICE指向远端监听器，比直连 IP 更易做负载分发，但不能绕过 LGWR 参与 - 真正减压要上
Oracle GoldenGate或Data Pump + 网络文件系统：LGWR 只写本地归档，后续由 Extract 进程读取并投递，解耦归档与传输 - 如果只是为备份容灾，
ARCHIVELOG DELETE INPUT配合 RMAN 备份到共享存储，比维持 5 个LOG_ARCHIVE_DEST_n更稳
多备库场景下，LOG_ARCHIVE_DEST_n 的数量、同步模式、VALID_FOR 组合稍有偏差，就可能让某条链路静默失效，而主库看起来一切正常。最容易被忽略的是 LOG_ARCHIVE_DEST_STATE_n 的隐式继承 —— 修改一个参数后没显式设回 ENABLE，目标就永远停摆。
