scan监听“能ping通但tnsping超时”大概率是ip冲突，scan vip被标记为dup；需用arping验证地址唯一性，查交换机mac表确认是否多端口出现同一mac；同时排查dns负向缓存、ss验证端口监听真实性及系统参数tcp_max_syn_backlog设置。
SCAN监听“能ping通但tnsping超时”大概率是IP冲突
SCAN VIP被标记为DUP（duplicate）是最隐蔽也最常被忽略的根因。srvctl status scan_listener显示running，lsnrctl status LISTENER_SCAN1卡在“Connecting to …”，但ip addr show里SCAN地址却带DUP标识——这说明局域网内已有设备响应同一IP。
验证方法很简单：
- 在每个RAC节点执行
arping -D -I <em>public_if_name</em> <em>scan_vip</em>（如arping -D -I ens33 10.10.10.44），返回“Received reply”即确认冲突 - 查交换机MAC表：
show mac address-table | include <em>scan_vip_mac</em>，若MAC出现在多个端口，基本可断定是虚拟机克隆或二层环路导致 -
crsctl stat res -t和olsnodes -s完全不报错，因为CRS只管资源注册，不管底层ARP层是否干净
客户端反复tnsping失败但nslookup正常？先查DNS负向缓存
DNS负向缓存（Negative Caching）会让“查无此名”的结果被递归DNS服务器缓存数小时，期间所有对SCAN名的解析请求都被直接拒绝——应用层表现为间歇性失联，日志里却找不到Oracle错误。
快速定位步骤：
- 在应用服务器上运行
dig rac-scan.example.com @8.8.8.8 +norecurse，绕过本地DNS直连公网权威服务器；若能拿到全部3个A记录，而nslookup rac-scan.example.com只返回一个或超时，就是负向缓存作祟 - 查本地DNS服务配置：
bind看max-ncache-ttl，dnsmasq看neg-ttl，默认常设为3600秒 - 临时缓解可加
/etc/hosts静态映射（仅限测试），长期方案必须把负向缓存TTL压到30秒以内
监听进程没挂但端口没监听？ss比netstat更可靠
netstat -tlnp | grep :1521可能漏掉已绑定但未完成三次握手的socket，尤其在高并发短连接场景下。RAC中SCAN监听器常因瞬时连接风暴触发内核限制，表现为lsnrctl status正常但nc -zv <em>scan_ip</em> 1521失败。
更准的验证方式：
- 用
ss -tlnp 'sport == :1521'（Linux）或Get-NetTCPConnection -LocalPort 1521（PowerShell）确认监听状态，ss能捕获处于SYN-RECEIVED状态的半连接 - 检查
/proc/sys/net/ipv4/tcp_max_syn_backlog和net.core.somaxconn是否过小（默认常为128），在RAC节点上建议调至2048以上 - 观察
$GRID_HOME/log/<node>/agent/oraagent_grid.log</node>中是否有Failed to bind address或Too many open files类记录，这类错误不会进listener.log
改完listener.ora别急着重启服务，先reload再status
RAC环境里直接在Windows服务管理器点“重启”或srvctl stop/start scan_listener，极大概率失败——因为tnslsnr进程启动即退出时，CRS不会输出具体原因，只会回滚状态。
正确操作顺序：
- 先在任一节点用
srvctl config scan确认当前SCAN配置，再用srvctl config scan_listener核对监听器绑定地址 - 手动进入
lsnrctl，执行reload LISTENER_SCAN1（注意指定名称），失败时会明确提示语法错误行号，比如TNS-01155: Incorrectly specified parameter LISTENER - 成功后立刻执行
status LISTENER_SCAN1，重点看Listening Endpoints Summary里的HOST是否为你刚填的FQDN，且ss -tlnp能看见该IP+端口 - 最后才跑
srvctl stop scan_listener && srvctl start scan_listener，避免旧进程残留句柄干扰
SCAN监听的“间歇性”往往不是Oracle本身的问题，而是网络层、DNS层、系统参数层的叠加效应。单独修一个点可能暂时恢复，但只要IP冲突没清、负向缓存没调、backlog没扩，问题就会在下次连接高峰重现。
