LNS卡在SENDREQ等待备库ACK，本质是SYNC+AFFIRM模式下备库未返回落盘确认，根因集中于备库RFS未接收、SRL缺失、防火墙拦截动态端口或密码文件不一致，须按主库配置→备库接收→网络认证顺序排查。
LNS进程卡在 SENDREQ 等待备库ACK，基本就是SYNC模式下传输链路断了，不是网络慢，是根本没收到响应。别急着调参数或重启，先定位是不是备库压根没在收。
查主库是否真在用SYNC+AFFIRM
这是最常被忽略的起点：很多DBA以为自己配的是ASYNC，其实LOG_ARCHIVE_DEST_2里悄悄开着AFFIRM。
- 执行
SELECT TRANSMIT_MODE, AFFIRM, DELAY FROM V$ARCHIVE_DEST WHERE DEST_ID = 2; - 若
TRANSMIT_MODE = 'SYNC'且AFFIRM = 'YES'，那LNS必须等备库落盘ACK才能返回——这一步就决定了它会不会卡 -
DELAY非零值（比如DELAY=30）说明配置了延迟应用，但不会导致LNS卡在SENDREQ，可暂不关注
确认备库RFS是否真在接收
LNS等不到ACK，大概率是备库RFS没拿到日志、或拿到了但写不进SRL——不是网络不通，是备库侧“接不住”。
- 登录备库，查
V$MANAGED_STANDBY：SELECT PROCESS, STATUS, SEQUENCE# FROM V$MANAGED_STANDBY WHERE PROCESS IN ('RFS', 'MRP'); - 如果RFS状态是
IDLE或CONNECTED但SEQUENCE#长时间不更新，说明没收到日志；如果是WAIT_FOR_LOG或APPLYING_LOG，说明至少收到了 - 再查
V$STANDBY_LOG：SELECT COUNT(*) FROM V$STANDBY_LOG;结果为0？那就没建SRL——RFS收到日志后无处可写，LNS永远等不到ACK
防火墙拦了LNS动态端口
tnsping通、sqlplus能连，不代表LNS能传日志。LNS初始连接走1521，后续数据流会协商一个30000–65535之间的随机端口，这个端口不走tnsnames.ora，防火墙只开1521就等于没开。
- 主库查传输状态：
SELECT STATUS, ERROR FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;若STATUS为ERROR且ERROR含ORA-12170，高度可疑 - 备库执行
netstat -an | grep :[3-6][0-9]{4} | grep，看有没有ESTABLISHED连接——没有就基本坐实被拦 - 临时关防火墙验证：
systemctl stop firewalld（CentOS）或ufw disable（Ubuntu），若日志立刻开始传输，立即加规则：firewall-cmd --permanent --add-port=30000-65535/tcp
密码文件不一致或ORA-16191认证失败
这不是传输慢，是LNS根本连不上备库。报错ORA-16191: User not authorized to log on to standby database时，V$ARCHIVE_DEST_STATUS里ERROR列可能为空，但LNS进程在V$PROCESS里状态异常（比如BACKGROUND但SPID为0）。
- 主备库都执行
orapwd file=$ORACLE_HOME/dbs/orapw$ORACLE_SID password=<sys_pwd> force=y format=12</sys_pwd>，确保密码文件版本和内容一致 - 检查备库
remote_login_passwordfile参数是否为EXCLUSIVE：SHOW PARAMETER remote_login_passwordfile - 确认主库
LOG_ARCHIVE_DEST_2中SERVICE指向的TNS别名，在备库监听器里真实注册了对应服务名（lsnrctl status里能看到）
真正卡住LNS的，往往不是配置多复杂，而是备库缺SRL、防火墙漏端口、密码文件没同步这三件事里的一件。排查顺序必须是：先看主库配了什么（SYNC+AFFIRM？），再看备库在不在收（RFS状态+V$STANDBY_LOG），最后才动网络和认证。跳过前两步直接改NET_TIMEOUT或调LGWR，只会掩盖问题。
