如何监控集群 interconnect_ping与traceroute验证心跳通畅-Oracle-PHP中文网

Oracle RAC中不存在interconnect_ping命令，正确验证私网连通性需用cluvfy comp nodecon、系统级ping/traceroute（指定源IP）及OCR/voting disk路径检查，避免混淆旧版调试脚本与实际工具。

oracle rac 集群里压根没有叫 interconnect_ping 的命令——这是很多人被文档误导后反复折腾的起点。实际用的是 oracle 自带的 oifcfg 查网卡配置、cluvfy comp nodecon 做连通性验证，或者直接用系统级工具模拟心跳流量。

常见错误现象：在节点上敲 interconnect_ping -h 报“command not found”，或从 MOS 文档里复制粘贴失败，本质是混淆了内部诊断脚本名和可执行命令。

真正能跑起来的验证方式只有三种：cluvfy comp nodecon -n all -verbose（官方推荐）、ping + traceroute 手动测私网、用 cvuqdisk 检查仲裁盘路径是否可达
cluvfy 会自动识别私网网段（通过 oifcfg getif），但前提是 OCR 中网卡配置正确；如果私网绑了多个子网，它可能只选一个去测
别信某些博客写的“修改 /etc/oracle/oci.conf 启用 interconnect_ping”，那是旧版 Oracle 10g 的调试残留，11g+ 已废弃

直接在节点上跑 traceroute 192.168.10.2（假设是另一节点私网 IP）大概率走不通，因为 Linux 默认路由表不包含私网条目，或者策略路由把包扔给了公网网卡。

使用场景：确认两个节点间私网三层是否可达，尤其跨交换机、VLAN 或有防火墙时。

先用 ip route get 192.168.10.2 看内核选哪张网卡出包，如果不是私网卡（比如显示 dev eth0 而你私网在 eth2），就得强制指定源地址
正确写法是：traceroute -s 192.168.10.1 192.168.10.2（-s 指定源 IP，确保走私网）
如果仍超时，检查 iptables -L -t raw 是否 DROP 了 ICMP，RHEL7+ 还要确认 firewalld 的 public zone 没把私网网段误加进去

RAC 心跳对延迟敏感，ping 返回 “64 bytes from …” 只说明二层通了，掩盖了真实问题：比如丢包率 0.5%、RTT 从 0.2ms 突增到 12ms，都可能引发 CSS 误驱逐节点。

性能影响：CSS 心跳超时默认是 3 秒（_css_heartbeattimeout），但底层依赖的是 sub-second 级的 UDP 包往返，持续 >5ms 抖动就会抬高 miss rate。

实操建议用：ping -c 100 -i 0.1 -W 1 192.168.10.2 | grep "time=" | awk '{print $7}' | cut -d= -f2 | sort -n | tail -10 —— 抓最后 10 个延迟值看毛刺
对比 ethtool eth2 输出中的 Speed 和 Duplex，半双工或 100Mbps 强制协商会放大抖动，必须设为 1000baseT/Full
别用 fping 替代，它默认发 ICMP timestamp，某些交换机 ACL 会拦截，而 Oracle 心跳用的是普通 echo request

看起来 crsctl check crs 显示 “CRS-4638: Oracle High Availability Services is online”，但节点莫名重启，日志里却没报 CSS 通信错误——这时候八成是 OCR/voting disk 访问异常，被误判为心跳断裂。

容易踩的坑：运维只盯着私网 ping/traceroute，却忘了多路径存储、NFS 挂载、ASMLIB 权限这些底层依赖。

查 crsctl query css votedisk 输出的路径，然后手动 ls -l 看属主是否为 grid:oinstall，权限是否为 640
如果是 ASM diskgroup，运行 asmcmd lsdg 看 State 是 MOUNTED，且 Offline Disks 为 0
用 strace -e trace=open,connect,sendto crsctl check crs 2>&1 | grep -E "(ORA-|failed|No such)" 可快速定位是网络还是文件层失败

事情说清了就结束