随缘惜情1. 问题现象：一套RAC突然“半身不遂”
先交代一下现场。这套Oracle RAC跑的是19.16版本，双节点，操作系统是Oracle Linux 7.9，私网用的双千兆网卡绑定，走的是active-backup模式。这套库在机房跑了快两年，平时一直很稳，直到那天下午2点多，值班同事打电话过来，说应用侧开始间歇性报ORA-12570和ORA-03113，部分会话连接被重置。
我登录服务器检查，第一眼扫过去，两个节点的crsctl status resource -t显示集群资源一切正常，crsctl check cluster也是All OK。这里就有意思了——从应用侧看数据库确实在报错，但集群层面看起来什么事都没有。这个“表面正常”的状态本身就是最大的异常信号。
再往细里看去，问题开始浮出水面。
code复制crsctl stat res -t -init | grep -i gipc
gipc这个进程在init资源组里显示的是ONLINE，但它的状态那一栏带了一个括号备注，后面跟着一串INTERNAL ERROR之类的字样。其实对于RAC来说，gipc进程在刚启动或者网卡切换配置的瞬间，出现过短暂的INTERNAL状态并不稀奇，但如果它一直停留在那个状态不恢复，那问题就大了。这说明集群私网通信的内部通道已经处于“假活”状态——进程没死，但通讯能力已经废了。
紧接着我查了/var/log/oracle下的gipcd.log，果然里面刷满了类似这样的报错：
code复制2024-11-05 14:15:22.786: [GIPC][73793792]gipcmodNetworkBind: failed to bind to address 192.168.1.10, errno 22
2024-11-05 14:15:22.786: [GIPC][73793792]gipcmodOracleBind: failed
看到errno 22（EINVAL）基本就能确认，gipc在尝试绑定私网IP的时候出了问题。这个问题如果不尽快处理，下一步就是节点被集群驱逐（eviction），或者整个集群做 fence 重启。
所以这里是第一个踩坑点：排查RAC问题不能只看crsctl check cluster那一行OK到底的输出，Oracle自己的健康检查在私网通信故障时往往会短暂“失明”。必须逐项看进程状态、告警日志和gipc的详细日志，三个地方互相印证，才能看到真实情况。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 定位思路：从“进程假活”一路追到网卡层
既然确认了是gipc通讯异常，下一步就是沿着私网通信链路逐层往下找。
先说清楚这里面的逻辑链。RAC节点之间的心跳要走私网，私网通信由集群软件底层维护。在19c这套架构里，gipc进程负责建立和维护节点间的通信端点，它是整个私网通信的“底座”。gipc下面直接用socke