网卡恢复后需手动触发Clusterware网络重发现并校验oifcfg与HAIP配置：先crsctl stop/start crs，再oifcfg setif更新网卡，放行169.254.0.0/16防火墙规则，确保私网MTU一致且cvuqdisk依赖的ASM就绪。
网卡 down 后 crsctl check cluster 显示节点不可达怎么办
oracle rac 的 clusterware 不会自动感知物理网卡重连或驱动重载，哪怕 ifconfig 或 ip link show 已显示网卡状态为 up，crsctl 仍可能持续报 “crs-4638: oracle high availability services is online” 但节点间无法通信。根本原因是 clusterware 在启动时读取并缓存了网络配置（尤其是 ocrconfig -showbackup 中记录的网络拓扑），后续不主动 re-scan。
实操建议：
- 先确认网卡是否真通：用
ping -I <em>public_ifname</em> <em>other_node_public_ip</em>和ping -I <em>private_ifname</em> <em>other_node_private_ip</em>分别测试，避免只看UP状态就误判 - 强制触发 Clusterware 网络重发现：运行
crsctl stop crs -f（所有节点依次执行，非并行！），再crsctl start crs；注意不要用crsctl restart crs，它跳过网络初始化阶段 - 检查 OCR 中记录的网卡名是否与当前
ip link输出一致：运行oifcfg getif，若返回空或旧网卡名（如eth0但实际已是ens192），需先oifcfg delif -global清空，再oifcfg setif -global <em>new_ifname</em>/<em>subnet</em>:public重新注册
私网网卡恢复后 cvuqdisk 报错或 cluvfy comp nodecon 失败
私网不通是 RAC 最典型的“假活”场景：CRS 进程在跑，VIP 漂移正常，但节点间心跳丢包，最终触发 evictions。而 cvuqdisk（CVU 依赖的共享磁盘校验模块）在私网异常时会反复重试连接，导致 cluvfy 卡住或直接失败。
实操建议：
- 不要等
cluvfy自动超时，手动加-verbose参数定位卡点：cluvfy comp nodecon -n all -verbose，重点关注输出中 “Checking interface xxx on subnet” 后是否 hang 住 - 确认私网 MTU 是否一致：RAC 要求所有节点私网接口 MTU 完全相同（通常 1500），用
ip link show <em>priv_if</em> | grep mtu核对，不一致会导致 ICMP 包被静默丢弃，ping看似通但 GI 心跳失败 -
cvuqdisk报 “Unable to open /dev/oracleasm/…” 本质是 ASM 实例未就绪，此时应先查crsctl stat res -t | grep asm，而非重装 cvuqdisk
ocrcheck 成功但 crsctl stat res -t 显示 ora.cluster_interconnect.haip OFFLINE
HAIP（High Availability IP）是 11.2+ RAC 私网冗余的关键组件，它不依赖物理网卡绑定，而是由 Clusterware 在私网子网上动态分配一个虚拟 IP（如 169.254.x.x）。一旦底层私网接口恢复但 HAIP 未重建，节点间仍无法通信，ora.cluster_interconnect.haip 就会卡在 OFFLINE。
实操建议：
- 检查 HAIP 子网是否被系统防火墙拦截：RHEL/CentOS 7+ 默认启用
firewalld，需放行 169.254.0.0/16 流量，命令：firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="169.254.0.0/16" accept'，然后firewall-cmd --reload - 手动触发 HAIP 重建（谨慎）：仅当确认私网已通且
oifcfg正确时，执行crsctl stop res ora.cluster_interconnect.haip -init，再crsctl start res ora.cluster_interconnect.haip -init；切勿在私网未通时强启，会加剧脑裂风险 - 验证 HAIP 是否生效：在任一节点执行
oifcfg getif应看到类似eth1 192.168.10.0 global cluster_interconnect,asm，且ip addr show中能查到 169.254.x.x 地址
网卡恢复后 VIP 没漂回原节点，或 SCAN VIP 无法解析
VIP 是绑定在网卡上的，网卡 down 期间 VIP 会被移到其他节点；但网卡恢复后，Clusterware 默认不会自动“漂回”，除非该节点重启 CRS 或手动干预。SCAN VIP 则依赖 DNS 或 GNS，网卡故障常伴随本地 /etc/resolv.conf 或 GNS 配置失效。
实操建议：
- 强制 VIP 回迁（仅限业务低峰）：
srvctl relocate vip -n <em>target_node</em> -i <em>vip_name</em>；注意 vip_name 是srvctl config vip -n <em>node</em>返回的完整名称（如rac1-vip），不是 IP - SCAN VIP 解析失败优先查本地 DNS 设置：确认
/etc/resolv.conf中 nameserver 指向的是 GNS 地址（如 192.168.10.254）或外部 DNS，且该 DNS 确实已配置 SCAN 名称的 A 记录（非 CNAME） - 临时绕过 DNS 测试：用
nslookup <em>scan_name</em> <em>gns_ip</em>直接查 GNS，若通但系统解析不通，大概率是resolv.conf被 NetworkManager 覆盖，需设PEERDNS=no并重启 network 服务
网卡恢复不是终点，Clusterware 对网络状态的“记忆”比操作系统更顽固。最容易被忽略的是 oifcfg 缓存和 HAIP 子网的防火墙策略——这两处不处理，即使 ping 通、ifconfig up，RAC 依然算“半瘫痪”。
