是，防火墙常拦截LNS/RFS协商的动态高端口（30000–65535），导致归档传输卡顿或超时；虽tnsping和sqlplus能连1521端口，但实际日志流需放行该动态端口范围。
防火墙是否拦了归档传输的动态端口
oracle data guard 日志传输（lns 进程）默认走监听端口（如 1521）建立初始连接，但后续实际归档流传输会协商一个**动态高端口**（通常在 30000–65535 范围），这个端口由主库 lns 和备库 rfs 协商决定，不经过 tnsnames.ora 或 listener.ora 静态配置。很多团队只放行了 1521，却忽略了这一层——tnsping 和 sqlplus 能连，但归档就是卡住或超时。
实操建议：
- 在主库执行
SELECT * FROM v$archive_dest_status WHERE dest_id = 2;，确认STATUS是ERROR或DEFERRED，再查ERROR列内容（常见为ORA-12170或空） - 在备库用
netstat -an | grep :[3-6][0-9]{4}观察是否有 ESTABLISHED 的高段端口连接来自主库 IP - 临时关闭备库防火墙验证（
systemctl stop firewalld或ufw disable），若日志立刻开始传输，基本锁定是动态端口被拦 - 生产环境必须重开防火墙后，添加规则：放行主库网段到备库的
30000–65535/tcp（不要只开单个端口，LNS 每次重连可能换端口）
LOG_ARCHIVE_DEST_n 中误配 SYNC/AFFIRM 导致传输卡死
当主库 LOG_ARCHIVE_DEST_2 含 SYNC 或 AFFIRM 属性，而备库未配置 Standby Redo Logs（SRL），RFS 进程无法即时落盘并返回 ACK，LNS 就会持续等待直至超时（默认 30 秒），最终标记该路径为 DISABLED，并在 alert.log 出现 ARC3: Archivelog destination ... disabled: destination Data Guard configuration error。
实操建议：
- 检查主库参数：
SHOW PARAMETER LOG_ARCHIVE_DEST_2，确认是否含SYNC、AFFIRM、NET_TIMEOUT - 检查备库是否有 SRL：
SELECT GROUP#, THREAD#, SEQUENCE#, ARCHIVED, STATUS FROM V$STANDBY_LOG;—— 若结果为空，说明没建 - 若确需 SYNC 模式，立即在备库添加 SRL：
ALTER DATABASE ADD STANDBY LOGFILE SIZE 200M;（至少比 Online Redo 多一组） - 若只是测试或允许异步，直接改为主库参数：
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=standby_db ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=standby_db' SCOPE=BOTH;
tnsnames.ora 与 listener.ora 服务名不一致引发 ORA-12541
tnsping standby_db 成功 ≠ 日志能传。因为 tnsping 只测监听是否响应，而 LNS 连接时会按 tnsnames.ora 中的 SERVICE_NAME 去请求服务，监听器必须已注册该服务名。常见坑是：tnsnames.ora 写了 SERVICE_NAME = orcl，但监听器只注册了 orcldg（比如静态注册写的是 SID_NAME = orcldg，没配 GLOBAL_DBNAME）。
实操建议：
- 在备库执行：
lsnrctl status，重点看输出中Service "xxx"行是否包含你在tnsnames.ora里写的SERVICE_NAME - 检查备库
$ORACLE_HOME/network/admin/listener.ora，静态注册段应类似：SID_LIST_LISTENER =<br> (SID_LIST =<br> (SID_DESC =<br> (GLOBAL_DBNAME = orcl)<br> (ORACLE_HOME = /u01/app/oracle/product/19c/dbhome_1)<br> (SID_NAME = orcldg)<br> )<br> )
——GLOBAL_DBNAME必须等于tnsnames.ora的SERVICE_NAME - 修改后重启监听：
lsnrctl reload（无需 stop/start） - 主库侧也需双向可连：确保主库
tnsnames.ora有指向备库的条目，且备库tnsnames.ora也有指向主库的条目（尤其 RAC 环境常漏掉反向）
密码文件不一致触发 ORA-16191
主备库必须使用**完全相同的密码文件**（orapw<sid>），否则 RFS 进程无法通过认证登录备库实例，报错 ORA-16191: Primary log shipping client not logged on standby。这个文件不是“内容一样”就行，而是要求二进制完全一致——哪怕只是用 orapwd 重新生成一次，也会因内部时间戳或哈希不同导致失败。
实操建议：
- 确认主备库密码文件路径和权限一致：
ls -l $ORACLE_HOME/dbs/orapw*，注意大小、修改时间、属主 - 最稳妥方式：从主库复制过去：
scp $ORACLE_HOME/dbs/orapw$ORACLE_SID oracle@standby:/u01/app/oracle/product/19c/dbhome_1/dbs/ - RAC 环境下，每个节点都要覆盖；如果用了 ASM 存储密码文件，用
asmcmd cp替代 scp - 验证：在主库用
sqlplus sys/<pwd>@standby_db as sysdba能登录，才算真正通了认证链
动态端口范围、SRL 是否存在、服务名注册一致性、密码文件二进制一致性——这四点任意一个不满足，都会让日志传输静默失败，且错误日志未必直接暴露根因。排查时别只盯 alert.log 里的 ORA 错误，要配合 v$archive_dest_status、lsnrctl status、netstat 交叉验证。
