RAC 节点"自己重启"通常不是操作系统的问题，而是集群件判定该节点失联后主动 fence。判断依据只有一条：CRS alert 里有没有 CSSD 的驱逐记录（CRS-1632 移除节点，其他节点随后记 CRS-5504 node down）。有，就是集群行为；没有，才去查主机层 panic、IPMI、硬件看门狗。
本文的案例是一套三节点 RAC：2026-01-08 21:59:28 起，qwdb01 与 qwdb02 同时观测到与 qwdb03 的私网心跳丢失，按 50% → 75% → 90% 的阈值倒计时，21:59:43 将 qwdb03 移出集群；qwdb03 重启后在 22:05 重新加入。三个节点的心跳地址都在 172.16.2.0/24 网段，最终定位为私网网络波动。
结论先行
- 直接原因：私网心跳（172.16.2.17 / .18 / .19）短时中断，超过 CSSD 的 misscount 阈值，qwdb03 被驱逐。
- 排除项：CRS/CSS/EVM 日志无表决异常；原文未记录主机 panic、共享存储或 ASM 报错。
- 影响面：qwdb03 上的实例被终止，剩余两节点完成 reconfiguration 后继续提供服务；qwdb03 于 22:05 重新加入。
- 处置方向：私网与公网物理隔离、链路冗余、关闭私网防火墙、监控私网丢包与延迟，而不是调大 misscount 掩盖问题。
节点重启的常见原因
排查前先分清五类原因，它们的证据落在不同日志里：
- 节点监控问题：OCSSD 进程异常，节点被误判失效。看
oclsomon.log与 CSSD 日志。 - 网络心跳丢失：私网连续丢包达到阈值，集群判定节点失效并驱逐。看 CRS alert 的 CRS-1612/1611/1610/1632。
- 配置问题：IPMI 配置错误、节点标识符不一致、私网网卡绑错，导致节点间通信异常。
- 资源瓶颈：CPU、内存耗尽导致 CSSD 无法及时调度，心跳超时。
- 软件缺陷：GI 版本已知 bug，需要对照 MOS 与补丁说明。
需要固定收集的材料：
$ORACLE_BASE/diag/crs/<节点名称>/crs/trace/alert.log
oprocd.log（/etc/oracle/oprocd/*.log.* 或 /var/opt/oracle/oprocd/*.log.*）
$ORACLE_BASE/diag/log/<节点名称>/cssd/oclsomon/oclsomon.log
Oracle OSWatcher 报告
注意第一行的路径写法：实际环境里常见的是 $ORACLE_BASE/diag/crs/<节点>/crs/trace/alert.log，本例为 /data/u01/app/grid/diag/crs/qwdb01/crs/trace/alert.log。
现场日志
节点 1（qwdb01）
# less /data/u01/app/grid/diag/crs/qwdb01/crs/trace/alert.log
2026-01-08 21:59:20.580 [OCSSD(23784)]CRS-7503: The Oracle Grid Infrastructure process 'ocssd' observed communication issues between node 'qwdb01' and node 'qwdb03', interface list of local node 'qwdb01' is '172.16.2.17:12321;', interface list of remote node 'qwdb03' is '172.16.2.18:24992;'.
2026-01-08 21:59:21.886 [OCSSD(23784)]CRS-7503: The Oracle Grid Infrastructure process 'ocssd' observed communication issues between node 'qwdb01' and node 'qwdb03', interface list of local node 'qwdb01' is '172.16.2.17:12321;', interface list of remote node 'qwdb03' is '172.16.2.18:24992;'.
2026-01-08 21:59:27.047 [EVMD(21795)]CRS-7503: The Oracle Grid Infrastructure process 'evmd' observed communication issues between node 'qwdb01' and node 'qwdb03', interface list of local node 'qwdb01' is '172.16.2.17:63661;', interface list of remote node 'qwdb03' is '172.16.2.18:63357;'.
2026-01-08 21:59:28.940 [OCSSD(23784)]CRS-1612: Network communication with node qwdb03 (3) has been missing for 50% of the timeout interval. If this persists, removal of this node from cluster will occur in 14.290 seconds
2026-01-08 21:59:29.264 [CRSD(93014)]CRS-7503: The Oracle Grid Infrastructure process 'crsd' observed communication issues between node 'qwdb01' and node 'qwdb03', interface list of local node 'qwdb01' is '172.16.2.17:33043;', interface list of remote node 'qwdb03' is '172.16.2.18:59057;'.
2026-01-08 21:59:35.943 [OCSSD(23784)]CRS-1611: Network communication with node qwdb03 (3) has been missing for 75% of the timeout interval. If this persists, removal of this node from cluster will occur in 7.290 seconds
2026-01-08 21:59:40.946 [OCSSD(23784)]CRS-1610: Network communication with node qwdb03 (3) has been missing for 90% of the timeout interval. If this persists, removal of this node from cluster will occur in 2.290 seconds
2026-01-08 21:59:43.252 [OCSSD(23784)]CRS-1632: Node qwdb03 is being removed from the cluster in cluster incarnation 538289042
2026-01-08 21:59:43.391 [OCSSD(23784)]CRS-1601: CSSD Reconfiguration complete. Active nodes are qwdb01 qwdb02 .
2026-01-08 21:59:43.413 [CRSD(93014)]CRS-5504: Node down event reported for node 'qwdb03'.
2026-01-08 21:59:49.486 [CRSD(93014)]CRS-7503: The Oracle Grid Infrastructure process 'crsd' observed communication issues between node 'qwdb01' and node 'qwdb03', interface list of local node 'qwdb01' is '172.16.2.17:33043;', interface list of remote node 'qwdb03' is '172.16.2.18:59057;'.
2026-01-08 21:59:52.852 [CRSD(93014)]CRS-2773: Server 'qwdb03' has been removed from pool 'Generic'.
2026-01-08 21:59:52.854 [CRSD(93014)]CRS-2773: Server 'qwdb03' has been removed from pool 'ora.pmssc'.
2026-01-08 21:59:53.213 [GIPCD(21985)]CRS-7503: The Oracle Grid Infrastructure process 'gipcd' observed communication issues between node 'qwdb01' and node 'qwdb03', interface list of local node 'qwdb01' is '172.16.2.17:64838;', interface list of remote node 'qwdb03' is '172.16.2.18:56551;'.
2026-01-08 21:59:53.214 [GIPCD(21985)]CRS-7503: The Oracle Grid Infrastructure process 'gipcd' observed communication issues between node 'qwdb01' and node 'qwdb03', interface list of local node 'qwdb01' is '172.16.2.17:64838;', interface list of remote node 'qwdb03' is '172.16.2.18:56551;'.
2026-01-08 21:59:53.383 [OCTSSD(91470)]CRS-7503: The Oracle Grid Infrastructure process 'octssd' observed communication issues between node 'qwdb01' and node 'qwdb03', interface list of local node 'qwdb01' is '172.16.2.17:25962;', interface list of remote node 'qwdb03' is '172.16.2.18:43119;'.
2026-01-08 22:01:30.186 [OLOGGERD(298834)]CRS-8500: Oracle Clusterware OLOGGERD process is starting with operating system process ID 298834
2026-01-08 22:05:05.694 [OCSSD(23784)]CRS-1601: CSSD Reconfiguration complete. Active nodes are qwdb01 qwdb02 qwdb03 .
2026-01-08 22:05:09.912 [OCSSD(23784)]CRS-1735: Fence request issued for an entity node 3 with a timeout of 180000.
2026-01-08 22:05:27.392 [CRSD(93014)]CRS-2772: Server 'qwdb03' has been assigned to pool 'Generic'.
2026-01-08 22:05:27.393 [CRSD(93014)]CRS-2772: Server 'qwdb03' has been assigned to pool 'ora.pmssc'.
2026-01-08 22:09:13.342 [OHASD(3505)]CRS-7505: Bootstap connection with node 'qwdb03' considered dead because of idle connection.
2026-01-08 23:20:11.542 [CRSD(93014)]CRS-7503: The Oracle Grid Infrastructure process 'crsd' observed communication issues between node 'qwdb01' and node 'qwdb02', interface list of local node 'qwdb01' is '172.16.2.17:33043;', interface list of remote node 'qwdb02' is '172.16.2.19:42168;'.
2026-01-08 23:20:13.545 [CRSD(93014)]CRS-7503: The Oracle Grid Infrastructure process 'crsd' observed communication issues between node 'qwdb01' and node 'qwdb02', interface list of local node 'qwdb01' is '172.16.2.17:33043;', interface list of remote node 'qwdb02' is '172.16.2.19:42168;'.
节点 2（qwdb02）
# less /data/u01/app/grid/diag/crs/qwdb02/crs/trace/alert.log
2026-01-08 21:59:13.881 [OCSSD(28956)]CRS-7503: The Oracle Grid Infrastructure process 'ocssd' observed communication issues between node 'qwdb02' and node 'qwdb03', interface list of local node 'qwdb02' is '172.16.2.19:26103;', interface list of remote node 'qwdb03' is '172.16.2.18:24992;'.
2026-01-08 21:59:14.551 [OCSSD(28956)]CRS-7503: The Oracle Grid Infrastructure process 'ocssd' observed communication issues between node 'qwdb02' and node 'qwdb03', interface list of local node 'qwdb02' is '172.16.2.19:26103;', interface list of remote node 'qwdb03' is '172.16.2.18:24992;'.
2026-01-08 21:59:21.890 [EVMD(11242)]CRS-7503: The Oracle Grid Infrastructure process 'evmd' observed communication issues between node 'qwdb02' and node 'qwdb03', interface list of local node 'qwdb02' is '172.16.2.19:28036;', interface list of remote node 'qwdb03' is '172.16.2.18:63357;'.
2026-01-08 21:59:28.480 [OCSSD(28956)]CRS-1612: Network communication with node qwdb03 (3) has been missing for 50% of the timeout interval. If this persists, removal of this node from cluster will occur in 14.760 seconds
2026-01-08 21:59:36.484 [OCSSD(28956)]CRS-1611: Network communication with node qwdb03 (3) has been missing for 75% of the timeout interval. If this persists, removal of this node from cluster will occur in 6.760 seconds
2026-01-08 21:59:41.034 [OCSSD(28956)]CRS-1610: Network communication with node qwdb03 (3) has been missing for 90% of the timeout interval. If this persists, removal of this node from cluster will occur in 2.210 seconds
2026-01-08 21:59:43.391 [OCSSD(28956)]CRS-1601: CSSD Reconfiguration complete. Active nodes are qwdb01 qwdb02 .
2026-01-08 21:59:52.200 [GIPCD(25804)]CRS-7503: The Oracle Grid Infrastructure process 'gipcd' observed communication issues between node 'qwdb02' and node 'qwdb03', interface list of local node 'qwdb02' is '172.16.2.19:45441;', interface list of remote node 'qwdb03' is '172.16.2.18:56551;'.
2026-01-08 21:59:52.201 [GIPCD(25804)]CRS-7503: The Oracle Grid Infrastructure process 'gipcd' observed communication issues between node 'qwdb02' and node 'qwdb03', interface list of local node 'qwdb02' is '172.16.2.19:45441;', interface list of remote node 'qwdb03' is '172.16.2.18:56551;'.
2026-01-08 21:59:59.422 [CLSECHO(391041)]ACFS-9544: Invalid files or directories found: 'missing[], extra[3.10.0-693 3.10.0-514 3.10.0-229 3.10.0-327 3.10.0-123]'
2026-01-08 22:01:30.180 [OLOGGERD(255205)]CRS-8500: Oracle Clusterware OLOGGERD process is starting with operating system process ID 255205
2026-01-08 22:01:48.052 [CVUD(322172)]CRS-10051: CVU found following errors with Clusterware setup : PRVG-11826 : DNS resolved IP addresses "" for SCAN name "szyxgl-scan" not found in the name service returned IP addresses "192.168.61.4"
日志怎么读
驱逐的倒计时
两节点的时间线几乎一致，只是起点差 0.5 秒：
2026-01-08 21:59:28.940 [OCSSD(23784)]CRS-1612: Network communication with node qwdb03 (3) has been missing for 50% of the timeout interval. If this persists, removal of this node from cluster will occur in 14.290 seconds
2026-01-08 21:59:29.264 [CRSD(93014)]CRS-7503: The Oracle Grid Infrastructure process 'crsd' observed communication issues between node 'qwdb01' and node 'qwdb03', interface list of local node 'qwdb01' is '172.16.2.17:33043;', interface list of remote node 'qwdb03' is '172.16.2.18:59057;'.
2026-01-08 21:59:35.943 [OCSSD(23784)]CRS-1611: Network communication with node qwdb03 (3) has been missing for 75% of the timeout interval. If this persists, removal of this node from cluster will occur in 7.290 seconds
2026-01-08 21:59:40.946 [OCSSD(23784)]CRS-1610: Network communication with node qwdb03 (3) has been missing for 90% of the timeout interval. If this persists, removal of this node from cluster will occur in 2.290 seconds
2026-01-08 21:59:43.252 [OCSSD(23784)]CRS-1632: Node qwdb03 is being removed from the cluster in cluster incarnation 538289042
2026-01-08 21:59:43.413 [CRSD(93014)]CRS-5504: Node down event reported for node 'qwdb03'.
从 21:59:28.940 开始通信中断，ocssd 持续检测到与 qwdb03 的通信丢失，占比从 50%、75%、90% 一路推进，到 21:59:43 将节点剔除集群。qwdb03 节点重启后重新加入集群，cssd 检测活跃节点恢复。
这组 CRS-1612/1611/1610 就是"判决书"：它说明集群不是"发现节点挂了"，而是"主动把节点踢了"。如果日志里只有 CRS-7503 而没有这三条倒计时，才需要考虑主机侧原因。
三个节点都在报通信问题
qwdb01、qwdb02、qwdb03 均出现通信问题，心跳 IP（私网 IP）172.16.2.17 / 172.16.2.18 / 172.16.2.19 网段是本次节点重启的故障核心。
涉及进程：CRSD、OCSSD、GIPCD、EVMD 等集群关键进程均观测到通信异常。
注意这里的一个细节：报错的是"两个节点之间"，而不是"某个节点自身"。三个节点两两之间都有 CRS-7503，说明不是单块网卡故障，而是整个私网网段出现了短时抖动或拥塞。
22:05 的重新加入与 fence
qwdb03 在 22:05:05 重新加入，紧接着 22:05:09 出现：
2026-01-08 22:05:09.912 [OCSSD(23784)]CRS-1735: Fence request issued for an entity node 3 with a timeout of 180000.
CRS-1735 是 fence 请求，出现在节点重新加入之后，通常被解读为对旧 incarnation 的隔离动作：先确保旧节点上的进程不会同时访问共享存储。它容易被误读为"又出故障"，实际更可能是保护流程的一部分；具体语义以目标 GI 版本文档为准。
两条与本次故障无关的告警
2026-01-08 21:59:59.422 [CLSECHO(391041)]ACFS-9544: Invalid files or directories found: 'missing[], extra[3.10.0-693 3.10.0-514 3.10.0-229 3.10.0-327 3.10.0-123]'
2026-01-08 22:01:48.052 [CVUD(322172)]CRS-10051: CVU found following errors with Clusterware setup : PRVG-11826 : DNS resolved IP addresses "" for SCAN name "szyxgl-scan" not found in the name service returned IP addresses "192.168.61.4"
- ACFS-9544 是 ACFS 驱动模块与内核版本不匹配的提示，与本例无关，但说明该节点的 ACFS 组件长期未维护。
- PRVG-11826 是 CVU 对 SCAN 名称解析的检查告警：DNS 返回的地址与名称服务中的记录不一致。它不影响本次重启，但会掩盖真正的集群配置问题，建议一并修掉。
为什么 15 秒就够
从日志能反推出这套集群的判定节奏：
21:59:28.940 50% → 剩余 14.290 秒
21:59:35.943 75% → 剩余 7.290 秒
21:59:40.946 90% → 剩余 2.290 秒
21:59:43.252 驱逐
三段剩余时间加上已经流逝的部分，总窗口约 28.6 秒，与常见的 misscount=30 配置吻合；实际值以 crsctl get css misscount 为准。CSSD 不是在"确认节点死了"之后才动作，而是在心跳连续缺失达到阈值时就判定失联——这是为了防止脑裂必须付出的代价：宁可错杀一个活节点，也不能让两个节点同时认为自己持有集群。
因此"节点只断了几秒网就重启"不是异常，而是设计行为。要降低误杀概率，只能从网络质量入手，而不是把 misscount 调大。调大之后，真故障时的隔离窗口同步变长，共享存储的并发写风险更高。
先分清 fence 与 reboot
节点重启有两条完全不同的路径，日志特征也不同：
- 集群驱逐（本例）：CRS alert 里有 CRS-1612/1611/1610 倒计时，随后 CRS-1632 移除节点，其他节点记录 CRS-5504 node down。节点上的
ohasd收到 fence 请求后重启主机。 - 主机自身故障：
dmesg有 panic、OOM、硬件报错，或 IPMI 事件日志有看门狗触发；CRS alert 里没有倒计时，只有重启后的启动记录。
如果先看 dmesg 没发现异常，就以为"主机没问题"，会漏掉真正的驱逐证据。正确顺序是先看 CRS alert 有没有 CRS-1632，再看主机日志。
私网问题的取证方法
网络团队反馈"私网波动"之后，还需要把结论落到可复现的证据上，否则下次还会发生：
# 交换机侧：确认故障时段端口是否有 CRC、pause 帧、广播风暴
# 主机侧：连续采样 10 分钟，观察丢包是否呈周期性
ping -c 600 -i 0.1 -s 1400 172.16.2.18 | tail -5
# 网卡侧：队列丢弃与错误计数
ethtool -S <私网网卡> | egrep -i "drop|error|crc|fifo"
# 内核侧：确认没有 bond 切换、链路 flap
dmesg -T | egrep -i "bond|link is (up|down)|nic"
# 集群侧：确认私网网卡被正确识别，且没有混入公网
oifcfg getif
判读时注意三点：
ping的丢包率必须与故障时段对齐。事后测不出丢包，不代表当时没有；要在交换机上查端口计数器。ethtool -S的 drop 计数持续增长，说明队列溢出，通常是突发流量或网卡/驱动问题，不是 Oracle 的问题。oifcfg getif里如果私网接口同时承担 public 角色，或者两个网卡在同一子网，心跳路径就会与业务流量互相干扰。
时间同步为什么也要查
CSSD 的心跳判定依赖本机时钟推进。如果节点间时间差过大，日志时间戳会互相错位，把 21:59 的事件显示成 22:0x，给因果分析制造假象。本例三个节点的时间戳基本对齐，可以排除这一项；但排查清单里仍应保留 chronyc tracking，因为它是低成本、高信息量的一条命令。
Oracle 对节点时间差的要求通常表述为小于 500ms。超过之后，除日志错位外，部分依赖时间的集群操作也会出现异常。
三个时间参数不要混用
与节点驱逐相关的时间参数有三个，含义不同：
crsctl get css misscount # 心跳丢失多少秒后判定节点失联
crsctl get css reboottime # 判定失联后，等待多久再重启节点
crsctl get css disktimeout # I/O fencing 的超时时间
misscount 决定"多快踢人"，reboottime 决定"踢了之后多久重启"，disktimeout 决定"隔离动作等多久"。三者都调大，不会让网络变好，只会把不确定性往后推。只有在跨机房、跨长距交换机等确有高延迟的场景，才按厂商建议调整，并同步评估脑裂风险。
排查清单
按顺序执行，前一步没有结论再进下一步：
# 1. 集群资源与节点状态
crsctl stat res -t
crsctl stat res -t -init
olsnodes -n -s
# 2. CSSD 心跳与私网配置
crsctl get css misscount
oifcfg getif
oifcfg iflist
# 3. 私网连通性与丢包（在其余节点上对故障节点执行）
ping -c 100 -i 0.01 172.16.2.18
netstat -i
ethtool -S <私网网卡> | egrep -i "drop|error|crc"
# 4. 时间同步
chronyc tracking
ntpq -p
# 5. 主机层
dmesg -T | egrep -i "panic|oom|watchdog|ipmi"
判读要点：
crsctl get css misscount给出的是秒数，CRS-1612 里的"14.290 seconds"是剩余时间，不是阈值本身。ping -i 0.01用 10ms 间隔压私网，比默认 1s 更容易暴露抖动。ethtool -S的 drop/error/crc 计数如果在增长，问题在链路或网卡，不在 Oracle。chronyc tracking的 offset 超过 500ms 时，集群日志的时间戳会互相错位，给对齐分析制造假象。
处置建议
- 私网与公网物理隔离，使用冗余网卡/链路聚合。
- 配置可靠 NTP/PTP 时间同步，确保节点时间差 < 500ms。
- 关闭私网防火墙，或放通集群所需端口。
- 监控私网延迟、丢包率，提前预警网络故障。
补充两点：不要用调大 misscount 的方式"解决"心跳丢失，那只会把节点驱逐推迟，让脑裂窗口变长；网络侧排查完成后，应在变更窗口内做一次 crsctl stop crs / start crs 的滚动演练，确认私网切换路径正常。
节点回来之后要确认什么
节点重新加入集群不等于故障闭环。按下面顺序确认，任何一项不通过都不要把节点交回业务：
# 1. 集群成员与资源状态：三个节点都应是 ACTIVE，ora.* 资源在各自节点 ONLINE
olsnodes -n -s
crsctl stat res -t
# 2. ASM 磁盘组：确认没有因节点重启进入 resync，且磁盘全部 MEMBER
asmcmd lsdg
asmcmd lsdsk --discovery
# 3. 数据库实例：确认实例已注册到 SCAN 监听，服务在两个节点上都可用
srvctl status database -d <db_unique_name> -v
lsnrctl status
# 4. 告警日志：确认实例做了崩溃恢复，且没有后续的 ORA-00600 / ORA-7445
adrci> show alert -tail 100
重点看两处：实例启动日志里是否有 "Instance recovery" 及其完成时间；ASM 是否有 NOTE: rebalance 或磁盘 offline 记录。节点被 fence 的瞬间，它上面的实例是非正常终止的，重新加入后必然要经历一次崩溃恢复，恢复时长取决于当时的脏块量。
如果节点反复重启，不要每次都按"网络抖动"结案。连续两次以上应升级为独立故障单，收集 oclsomon.log、OSWatcher 与交换机端口计数器，按 GI 版本对照 MOS 的节点驱逐类问题。
监控项建议
这类故障的共同点是"日志里证据齐全，但没人看"。把下面几项纳入日常监控，成本很低：
- CRS alert 中 CRS-1612/1611/1610/1632/5504 的实时告警，任意一条出现即通知 DBA。
- 私网网卡的丢包率与 CRC 错误计数，按 5 分钟粒度采集，阈值建议从基线浮动判断，而不是固定值。
- 节点间心跳延迟，可用
ping或gipcd自身统计做补充。 - 节点重启次数与
ohasd启动记录，用于识别"重启了但没报障"的隐性事件。
最后一条尤其容易被忽略：本例中 qwdb03 在 22:05 已经回到集群，如果没有人工翻日志，这次驱逐很可能只留下一条"主机重启"的监控记录。
待核对
- 原文节点 2 日志开头有一行
026-03-11 11:15:22.718的记录，日期与本次故障（2026-01-08）不符，疑为抓取时的串行残留，本文已略去；如需引用请回原 HTML 核对。 - CRS-1735 的 fence 对象与超时值（180000）来自原文，具体语义以目标 GI 版本官方文档为准。
- "私网网络波动"为网络团队反馈结论，原文未附交换机侧日志；对外发布前建议补一份链路监控截图。
原文首发于微信公众号「止水研习社」。
文章评论