DG SYNC模式下LNS卡在SENDREQ等待备库ACK是最典型阻塞现象，表现为主库提交变慢、log file sync飙升、LNS与LGWR-LNS等待高企而本地写正常，根因通常为备库接收异常、防火墙拦截动态端口、密码文件不一致或MRP进程未运行/卡住。
主库LNS进程卡在SENDREQ等待备库ACK
这是DG SYNC模式下最典型的阻塞现象：主库提交变慢、log file sync飙升到几十毫秒，AWR里LNS wait on SENDREQ和LGWR-LNS wait on channel同时高企，而log file parallel write却只有1ms左右——说明本地写磁盘没问题，瓶颈纯在传输链路。
实操建议：
- 立刻查主库
V$ARCHIVE_DEST：执行SELECT TRANSMIT_MODE, AFFIRM, DELAY FROM V$ARCHIVE_DEST WHERE DEST_ID = 2;，若TRANSMIT_MODE = 'SYNC'且AFFIRM = 'YES'，就是它了 - 别急着调网络或存储，先确认备库是否真在接收：登录备库，查
V$MANAGED_STANDBY中RFS进程状态是否为WAIT_FOR_LOG或APPLYING_LOG；再看V$STANDBY_LOG是否有可用组（空结果=没建SRL） - 若业务允许少量数据丢失（如报表库、开发环境），直接改为主库参数：
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=standby_db ASYNC NOAFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=standby_db' SCOPE=BOTH; - 如果必须用SYNC，务必确保备库已建足够数量的
STANDBY REDO LOG（至少比在线日志多一组），否则RFS无法落盘，LNS就永远等不到ACK
防火墙拦了LNS协商的动态高端口
tnsping通、sqlplus连得上1521，不代表LNS能传日志。LNS初始连接走监听端口，但后续实际日志流会协商一个动态端口（通常30000–65535），这个端口不走tnsnames.ora，防火墙若只开了1521，LNS就会卡在连接建立后、数据发送前的阶段。
实操建议：
- 主库查传输状态：
SELECT STATUS, ERROR FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;，若STATUS为ERROR或DEFERRED，ERROR列为空或含ORA-12170，高度可疑 - 备库执行
netstat -an | grep :[3-6][0-9]{4}，看是否有来自主库IP的ESTABLISHED连接——没有就基本坐实被拦 - 临时关闭备库防火墙验证：
systemctl stop firewalld（CentOS）或ufw disable（Ubuntu），若日志立刻开始传输，立即加规则 - 生产环境放行规则必须是段：
firewall-cmd --permanent --add-port=30000-65535/tcp，不能只开单个端口——LNS每次重连都可能换端口
ORA-16191导致LNS根本连不上备库
这不是传输慢，是认证失败。LNS进程以SYS身份远程登录备库时被拒，报错ORA-16191: User not authorized to log on to standby database，此时V$ARCHIVE_DEST_STATUS.ERROR会明确写出该错误，且V$MANAGED_STANDBY里LNS状态可能是CONNECTED但BLOCK#长期不动。
实操建议：
- 别查监听、别调参数，先盯密码文件：
orapwd describe file=$ORACLE_HOME/dbs/orapw<sid></sid>，主备两端输出必须逐行一致，尤其USERNAME列和SYSDBA值 - 确认两端
remote_login_passwordfile均为EXCLUSIVE（SHARED或NONE都不行），RAC环境需加SID='*'批量修改 - 12c+版本注意大小写：备库密码文件里的
SYS密码必须和主库完全一致（含大小写），改过ALTER USER SYS IDENTIFIED BY后必须用orapwd重建并全量分发 - 替换前必须
shutdown immediate备库——Oracle会缓存旧密码文件句柄，热替换无效
备库MRP进程静默停止或应用卡住
LNS能发、RFS能收，但主库归档持续增长，备库数据却不更新——问题不在传输侧，而在应用侧。V$MANAGED_STANDBY里MRP0进程可能状态为NOT APPLYING、WAIT_FOR_LOG但SEQUENCE#长期不涨，或者压根查不到MRP0行。
实操建议：
- 先确认MRP是否真在跑：
SELECT PROCESS, STATUS, SEQUENCE# FROM V$MANAGED_STANDBY WHERE PROCESS = 'MRP0';，无结果就手动启：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT; - 若有MRP0但SEQUENCE#不动，立刻查备库
alert.log，重点搜ORA-00600、ORA-01110、corruption、undo，常见于坏块、UNDO表空间异常或控制文件时间戳错乱 - 检查
V$ARCHIVE_GAP：有缺口说明RFS根本没收到日志；无缺口但数据不同步，说明MRP卡在某条日志上，不是传输问题 - 别忽略基础项：备库
LOG_ARCHIVE_DEST_1路径是否满？权限是否为oracle:oinstall？用了NFS的话是否加了noac选项？这些都会让MRP在应用时挂住
真实环境里，LNS阻塞往往不是单一原因。比如你看到LNS wait on SENDREQ，第一反应是改ASYNC，但如果底层是防火墙拦端口或密码文件不一致，改了也没用。排查时按“认证→网络→传输配置→应用”顺序推进，比凭经验瞎猜快得多。
