v$archive_dest_status中status为valid却报错，因valid仅表示参数语法正确，并不反映路径真实可用性；真实问题需查failure字段、delay_mins增长趋势及实测写权限，sync/affirm配置下备库缺失srl或global_dbname不匹配亦会导致循环断连。
日志传输频繁断开不是网络不稳定导致的，而是主库归档链路中某个 LOG_ARCHIVE_DEST_n 目标持续不可用，触发 Oracle 强制重试与降级逻辑，最终表现为“断开—重连—再断开”的循环。
为什么 v$archive_dest_status 里 STATUS 是 VALID 却还在报错？
VALID 只表示参数语法正确、数据库能解析该配置，不代表路径真实可用。真实瓶颈藏在传输行为里：
- 查最近失败记录：
SELECT DEST_ID, FAILURE, TIMESTAMP FROM V$ARCHIVE_DEST_STATUS WHERE FAILURE IS NOT NULL ORDER BY TIMESTAMP DESC—— 多数断开始于某次ORA-16038（归档写入失败）或ORA-19809（FRA 空间超限） - 看延迟是否持续增长：
SELECT DEST_ID, DELAY_MINS FROM V$ARCHIVE_DEST_STATUS—— 若DELAY_MINS > 0且每分钟递增，说明 LNS 进程卡在发送环节，不是备库收不到，是主库根本没发出去 - 别信
ls -l看目录存在就放心 —— 用su - oracle -c "touch /path/to/arch/test.$$ && rm /path/to/arch/test.$$"实测写权限，NFS 挂载点尤其要加-o hard,intr参数
LOG_ARCHIVE_DEST_n 配了 SYNC 或 AFFIRM，但备库没建 Standby Redo Logs 会怎样？
主库 LGWR 会一直等 ACK，超时后主动断开连接并标记目标为 ERROR，下次日志切换时重试，形成“断—连—断”节奏。这不是配置错误，是 Oracle 的保护性中断。
- 确认备库是否启用 SRL：
SELECT GROUP#, THREAD#, BYTES FROM V$STANDBY_LOG—— 返回空行即未建 - 检查主库参数：
SHOW PARAMETER LOG_ARCHIVE_DEST_2—— 若含SYNC或AFFIRM，但备库无 SRL，则必须改用ASYNC NOAFFIRM - 临时验证：在主库执行
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=standby_db ASYNC NOAFFIRM' SCOPE=BOTH，观察v$archive_dest_status中ERROR是否清空
tnsping 和 sqlplus 都通，为什么 LGWR 就连不上备库？
tnsping 只验证监听器存活，sqlplus 测试的是动态服务注册；而 LGWR 使用静态注册的 GLOBAL_DBNAME，它必须等于备库的 DB_UNIQUE_NAME（不含域名），否则直接拒绝连接。
- 在备库查真实值：
SELECT DB_UNIQUE_NAME FROM V$DATABASE - 在备库检查监听器静态注册：
lsnrctl status | grep -A 5 "Services Summary"—— 找到Service "xxx"，那个xxx必须和上一步查出的DB_UNIQUE_NAME完全一致（大小写、下划线都算） - 若不一致，修改备库
$ORACLE_HOME/network/admin/listener.ora中GLOBAL_DBNAME值，并重启监听：lsnrctl reload - 主库
tnsnames.ora中对应 SERVICE 条目，其SERVICE_NAME字段不能填实例名或域名，只能填这个GLOBAL_DBNAME
最易被忽略的是：备库监听器重启后，lsnrctl status 显示服务 READY，但 GLOBAL_DBNAME 仍沿用旧值——因为 Oracle 监听器不会自动重读 listener.ora 中已注册的服务，必须显式 lsnrctl reload 或 lsnrctl stop && lsnrctl start。
