VIP漂移后ping通但数据库连不上，是因为监听器未在新节点注册该VIP，lsnrctl status查不到对应端口监听，TCP连接被拒绝；VIP资源只负责IP漂移，不触发监听器自动注册。
为什么VIP漂移后ping通但数据库连不上
不是VIP没切过去，而是新节点上监听器根本没为这个VIP启动服务。lsnrctl status里查不到对应地址的监听端口，TCP连接直接被拒绝。Oracle RAC的VIP资源只负责IP地址漂移，不负责监听器注册——这是两个独立动作。
常见现象包括：
- 客户端tnsnames.ora写的是
HOST=rac1-vip，节点1宕机后，VIP飘到节点2，但连接仍超时 -
crsctl stat res -t显示ora.rac1.vipONLINE on rac2，但netstat -tlnp | grep :1521看不到该VIP监听 - 手动在节点2上执行
srvctl start listener -n rac2也无效，因为默认监听器只绑定本节点VIP
检查VIP绑定网卡是否与OCR记录一致
VIP必须绑定在公网网卡上，且OCR中记录的网卡名、子网必须和OS实际配置严格匹配。网卡故障后常出现OCR残留旧配置，导致VIP启动失败或绑定到错误接口（比如私网卡）。
操作步骤：
- 用
oifcfg getif -global确认当前OCR记录的public网卡名（如bond0）和子网 - 用
ifconfig或ip a核对OS层面该网卡是否存在、IP是否UP、子网掩码是否一致 - 若不一致，先停VIP：
srvctl stop vip -n rac1，再用srvctl modify nodeapps -n rac1 -A rac1-vip/255.255.255.0/bond0更新 - 特别注意：如果网卡重命名（如eth0→bond0），必须同步更新OCR，否则
crs_start会静默失败
监听器不自动注册VIP的修复方法
VIP漂移后监听器不自动注册，本质是LOCAL_LISTENER参数未动态适配。不能靠改listener.ora硬编码，而要让实例自己感知当前VIP。
正确做法：
- 确保每个节点的
LOCAL_LISTENER参数指向本节点VIP，例如：ALTER SYSTEM SET LOCAL_LISTENER='(ADDRESS=(PROTOCOL=TCP)(HOST=rac1-vip)(PORT=1521))' SCOPE=BOTH; - 检查
REMOTE_LISTENER是否设为SCAN地址（如rac-scan:1521），这是SCAN Listener做连接路由的前提 - 重启监听器后，执行
lsnrctl services，确认输出中包含该VIP地址对应的service_name条目 - 若仍无注册，检查
tnsnames.ora中rac1-vip解析是否准确，避免DNS缓存或/etc/hosts错配
网卡故障后VIP无法启动的底层排查点
网卡物理恢复后VIP仍不启动，大概率卡在ARP或MAC缓存层面——新节点接管VIP时，交换机或同网段主机ARP表还指向原MAC，导致ICMP可达但TCP不通，甚至VIP资源自身启动失败。
关键验证项：
- 在新节点执行
arping -c 3 -I bond0 rac1-vip，确认能收到响应；若超时，说明ARP未刷新 - 在客户端或同网段主机执行
arp -a | grep rac1-vip，看MAC是否已更新为新节点网卡MAC - 临时清空交换机对应端口的ARP缓存（需网络权限），或等待2~3分钟让老化机制生效（实测常见延迟）
- 不要依赖
ifconfig看到VIP就认为OK，用ip addr show bond0确认VIP是否真在secondary地址列表里
