记一次 Oracle RAC 节点反复重启：从告警日志到 vmcore 定位 CPU 硬件故障

一、故障概述与系统环境
#

1.1 故障概述
#

2026 年 7 月 12 日至 7 月 14 日，Oracle RAC 数据库节点 sydb2 在运行期间多次突然失联并自动重启。

节点重新启动后，Oracle Clusterware 和数据库实例曾短暂恢复，但随后又出现以下异常：

CRS-4535: Cannot communicate with Cluster Ready Services
CRS-4530: Communications failure contacting Cluster Synchronization Services daemon
CRS-4534: Cannot communicate with Event Manager

Clusterware 初始化资源曾出现以下两类状态：

第一类：

ora.cssd    ONLINE
ora.asm     ONLINE
ora.ctssd   ONLINE
ora.crsd    INTERMEDIATE
ora.evmd    INTERMEDIATE

第二类：

ora.cssd    OFFLINE
ora.asm     OFFLINE
ora.ctssd   OFFLINE
ora.crsd    OFFLINE
ora.evmd    OFFLINE

经 Oracle 数据库告警日志、Linux 启动记录、审计日志、kdump、vmcore、vmcore-dmesg.txt、Oracle Clusterware 日志以及 Lenovo BMC/XCC 硬件事件综合分析，最终确认：

sydb2 服务器 CPU1/Socket1 处理器子系统发生不可纠正的 Machine Check Exception。Linux 内核检测到处理器上下文已经损坏后触发 Kernel Panic，kdump 保存 vmcore，随后系统自动重启。

Oracle 数据库、ASM、Clusterware 和 RAC 服务均为硬件故障发生后的被动中断对象。

重启后出现的 CSSD 网络心跳缺失、CRSD Policy Engine 无法初始化等问题，属于服务器多次异常复位及硬件不稳定背景下的次生故障现象。

1.2 系统环境
#

项目	信息
系统名称	XXX
数据库架构	Oracle RAC 双节点
数据库版本	Oracle Database 11.2.0.4
Grid Infrastructure	Oracle GI 11.2.0.4
故障节点	`sydb2` / `infodb2`
正常节点	`sydb1` / `infodb1`
操作系统	CentOS Linux 7
内核版本	`3.10.0-1160.el7.x86_64`
服务器型号	Lenovo ThinkServer SR660 V2
BIOS 版本	XWE108K-1.92
CPU 型号	Intel Xeon Gold 5318N
CPU 架构	双路、96 个逻辑 CPU
内存	约 512GB
Oracle SGA	约 248GB
公网接口	`ens9f0`
私网接口	`ens9f3`
节点 1 私网	`100.1.1.1/24`
节点 2 私网	`100.1.1.2/24`
OCR/Voting	ASM 磁盘组 `+OCRVOTE`

二、故障现象
#

2.1 节点在短时间内多次自动重启
#

通过 last -x、who -b、uptime -s 以及 /var/crash 目录核对，发现 sydb2 在不到 25 小时内至少发生 9 次异常重启。

序号	内核异常及 vmcore 时间	主机后续启动时间
1	2026-07-12 14:49:04	2026-07-12 14:51
2	2026-07-12 17:10:11	2026-07-12 17:12
3	2026-07-12 18:02:29	2026-07-12 18:04
4	2026-07-12 19:44:40	2026-07-12 19:46
5	2026-07-13 06:28:03	2026-07-13 06:30
6	2026-07-13 10:29:44	2026-07-13 10:31
7	2026-07-13 11:46:08	2026-07-13 11:48
8	2026-07-13 12:13:44	2026-07-13 12:15
9	2026-07-13 15:06:55	2026-07-13 15:08

每次 vmcore 生成后约两分钟，服务器完成重新启动，符合 kdump 保存内存转储后自动重启的特征。

2.2 Oracle 实例随主机重启反复启动
#

alert_infodb2.log 中发现 9 次：

Starting ORACLE instance (normal)

对应时间为：

2026-07-12 14:53:48
2026-07-12 17:16:10
2026-07-12 18:08:15
2026-07-12 19:50:34
2026-07-13 06:33:53
2026-07-13 10:35:36
2026-07-13 11:52:14
2026-07-13 12:19:36
2026-07-13 15:12:46

每次 Oracle 实例启动均发生在 Linux 主机启动后约 3～4 分钟。

实例启动前未发现对应的：

Shutting down instance
Database closed
Database dismounted
Instance shutdown complete

说明数据库进程不是通过正常关闭流程退出，而是随操作系统突然中断。

2.3 Linux 没有正常关机记录
#

Linux Audit 中存在连续的：

SYSTEM_BOOT

但在相应时间之前没有对应的：

SYSTEM_SHUTDOWN

同时未发现管理员执行以下命令的审计记录：

reboot
shutdown
poweroff
halt
init 6
systemctl reboot

现场表现为非正常系统中断，而不是人工重启或正常操作系统关机。

2.4 每次异常重启前均生成 vmcore
#

/var/crash 中存在 9 组完整的：

vmcore
vmcore-dmesg.txt

单个 vmcore 大小约为 1.9～2.2GB。

该现象说明系统经历了以下过程：

运行内核发生致命异常
        ↓
Kernel Panic
        ↓
进入 kdump crash kernel
        ↓
保存 vmcore
        ↓
系统自动重启

如果只是突然断电，通常无法连续完整保存多份约 2GB 的 vmcore。

2.5 vmcore 中出现明确的 CPU 致命错误
#

不同 vmcore-dmesg.txt 中反复出现两类硬件错误。

第一类为 CPU 直接上报的 Machine Check Exception：

CPU 38: Machine Check Exception: 5 Bank 0
Bank 0: f2000040000f040a

PROCESSOR 0:606a6
SOCKET 1
APIC 5c
microcode d0003d1

Machine check: Processor context corrupt
Kernel panic - not syncing: Fatal machine check

第二类为 BIOS/固件通过 APEI/GHES 上报：

Hardware error from APEI Generic Hardware Error Source

event severity: fatal
fru_text: Socket1
section_type: general processor error
error_type: 0x08
micro-architectural error
processor_id: 0x5c

Kernel panic - not syncing: Fatal hardware error!

多次事件均集中在：

Socket1
APIC 0x5c / 0x5d
Bank 0
micro-architectural error
Processor context corrupt

2.6 BMC/XCC 记录 CPU1 不可纠正错误
#

Lenovo BMC/XCC 的 System Event Log 中记录：

CPU1_Status
Critical
Configuration Error
System_MCERR
Critical
State Asserted
CPU1_Status
Critical
Machine Check Exception (Uncorrectable)

BMC 中的 CPU1_Status 与 Linux vmcore 中的 Socket1 完全对应。

2.7 重启后 Clusterware 无法完整恢复
#

主机启动日志显示操作系统、ASMLib、网络服务及 Oracle High Availability Services 能够启动。

但后续 Clusterware 曾出现：

Oracle High Availability Services is online
Cluster Synchronization Services is online
Cannot communicate with Cluster Ready Services
Cannot communicate with Event Manager

对应资源状态为：

ora.crsd   INTERMEDIATE
ora.evmd   INTERMEDIATE

另一次启动后，CSSD 也无法加入集群，导致 ASM、CRSD 和数据库资源全部保持 OFFLINE。

三、排查过程
#

3.1 从 Oracle 告警日志确认数据库不是重启源头
#

首先检查 infodb2 实例告警日志中的启动记录：

grep -n "Starting ORACLE instance" alert_infodb2.log

共发现 9 次实例启动。

继续检查是否存在正常关闭：

grep -nE \
"Shutting down instance|Instance shutdown complete|Database closed|Database dismounted|ALTER DATABASE CLOSE" \
alert_infodb2.log

结果显示，多次启动之前没有对应的正常关闭记录。

继续检索 Oracle 内部致命错误：

grep -nE \
"ORA-00600|ORA-07445|ORA-29740|ORA-29702|terminating instance|Instance terminated|PMON terminating|LGWR terminating" \
alert_infodb2.log

未发现能够解释整台服务器自动重启的 Oracle 内部错误。

告警日志中虽存在以下信息：

ORA-28545
ORA-02063
Fatal NI connect error 12170
Checkpoint not complete

但这些分别属于数据库链路、远端连接、网络连接超时及日志切换压力问题，无法触发 Linux 整机重启。

该阶段确认：

Oracle 实例是随主机异常中断的受影响对象，而不是导致操作系统重启的源头。

3.2 核对主机启动时间与 Oracle 启动时间
#

执行：

uptime -s
who -b
last -x | head -50

其中一次输出为：

uptime -s
2026-07-13 15:09:00

who -b
system boot  2026-07-13 15:08

last -x 显示：

reboot system boot  Mon Jul 13 15:08
reboot system boot  Mon Jul 13 12:15
reboot system boot  Mon Jul 13 11:48
reboot system boot  Mon Jul 13 10:31
reboot system boot  Mon Jul 13 06:30
reboot system boot  Sun Jul 12 19:46
reboot system boot  Sun Jul 12 18:04
reboot system boot  Sun Jul 12 17:12
reboot system boot  Sun Jul 12 14:51

将主机启动时间与 Oracle 启动时间比对后发现，两者逐一对应，Oracle 均在主机启动后约 3～4 分钟自动拉起。

因此不是 Oracle 进程反复崩溃后由 Clusterware 单独重启，而是整台主机反复重新启动。

3.3 检查 Linux 审计日志，排除人工重启
#

查询管理员命令：

ausearch -m USER_CMD \
  -ts 07/12/2026 14:00:00 \
  -te 07/13/2026 15:20:00 -i \
| egrep -i \
'reboot|shutdown|poweroff|halt|init 6|systemctl reboot|systemctl poweroff'

结果：

<no matches>

查询启动和关机事件：

ausearch -m SYSTEM_BOOT,SYSTEM_SHUTDOWN \
  -ts 07/12/2026 14:00:00 \
  -te 07/13/2026 15:20:00 -i

结果中存在多条：

type=SYSTEM_BOOT

但对应时间之前没有：

type=SYSTEM_SHUTDOWN

进一步检查 Oracle Clusterware Lastgasp：

ls -lah --full-time /etc/oracle/lastgasp
file /etc/oracle/lastgasp/*
strings /etc/oracle/lastgasp/* 2>/dev/null

结果显示文件时间仍为 2024 年，未留下本次故障时间的 Clusterware 主动重启记录。

该阶段排除了：

常规人工 reboot；
正常 systemd shutdown；
有明确 Lastgasp 证据的 Clusterware 主动重启。

3.4 检查 kdump 状态和 vmcore
#

检查 kdump：

systemctl status kdump -l
kdumpctl status

输出显示：

kdump.service - Crash recovery kernel arming
Active: active (exited)

kexec: loaded kdump kernel
Starting kdump: [OK]

以及：

Kdump is operational

检查 ABRT：

abrt-cli list

其中一次记录为：

Directory:
/var/spool/abrt/vmcore-127.0.0.1-2026-07-13-15:06:55

检查 /var/crash：

find /var/crash -maxdepth 3 -type f -ls

发现 9 组 vmcore，与 9 次系统重启逐一对应。

vmcore 时间	下一次启动时间	时间差
07-12 14:49:04	07-12 14:51	约 2 分钟
07-12 17:10:11	07-12 17:12	约 2 分钟
07-12 18:02:29	07-12 18:04	约 2 分钟
07-12 19:44:40	07-12 19:46	约 2 分钟
07-13 06:28:03	07-13 06:30	约 2 分钟
07-13 10:29:44	07-13 10:31	约 2 分钟
07-13 11:46:08	07-13 11:48	约 2 分钟
07-13 12:13:44	07-13 12:15	约 2 分钟
07-13 15:06:55	07-13 15:08	约 2 分钟

时间关系证明每次都是生产内核先崩溃，kdump 保存现场后主机才重新启动。

3.5 分析 `vmcore-dmesg.txt`
#

以最新一次 vmcore 为例：

F=/var/crash/127.0.0.1-2026-07-13-15:06:55/vmcore-dmesg.txt

grep -nEi -B30 -A120 \
'Kernel panic|not syncing|Machine Check|MCE|Hardware Error|APEI|GHES|Socket1|Processor context corrupt|Fatal' \
"$F"

输出中明确出现：

event severity: fatal
fru_text: Socket1
section_type: general processor error
error_type: 0x08
micro-architectural error
processor_id: 0x5c
Kernel panic - not syncing: Fatal hardware error!

对全部 vmcore 进行批量检查：

for f in /var/crash/*/vmcore-dmesg.txt
do
    echo "===== $f ====="

    grep -nEi \
    'Kernel panic|Machine Check|MCE|Hardware Error|APEI|GHES|Socket1|Processor context corrupt|Fatal' \
    "$f" | tail -100
done

多份 vmcore 中重复出现：

CPU 38
Bank 0
Socket1
APIC 0x5c 或 0x5d
CPUID 0x606a6
microcode 0xd0003d1
Processor context corrupt
Fatal machine check

部分转储中 RIP 位于：

huge_pmd_share
huge_pte_alloc

但同时被标记为：

RIP !INEXACT!

这表示 Machine Check 可能异步上报，RIP 只是错误被检测到时正在执行的代码位置，不能据此判断 HugePages 是根因。

真正跨多次事件稳定重复的是：

Socket1
Bank 0
APIC 0x5c / 0x5d
micro-architectural error
Processor context corrupt

3.6 使用 BMC/XCC 进行硬件侧交叉验证
#

检查 Lenovo BMC/XCC System Event Log，发现：

CPU1_Status
Critical
Configuration Error
System_MCERR
Critical
State Asserted
CPU1_Status
Critical
Machine Check Exception (Uncorrectable)

BMC 记录中的 CPU1 与 Linux 中的 Socket1 相互对应。

因此形成以下证据闭环：

BMC/XCC
CPU1 Machine Check Exception (Uncorrectable)
        ↓
Linux vmcore
Socket1 / APIC 0x5c、0x5d / Bank 0
        ↓
Processor context corrupt
        ↓
Kernel panic
        ↓
kdump 保存 vmcore
        ↓
系统自动重启

3.7 核对重启后的 Clusterware 状态
#

主机重启后执行：

export GRID_HOME=/u01/app/11.2.0/grid
export PATH=$GRID_HOME/bin:$PATH

crsctl check crs
crsctl stat res -t -init

曾出现：

CRS-4638: Oracle High Availability Services is online
CRS-4535: Cannot communicate with Cluster Ready Services
CRS-4529: Cluster Synchronization Services is online
CRS-4534: Cannot communicate with Event Manager

对应资源状态：

ora.asm    ONLINE
ora.cssd   ONLINE
ora.ctssd  ONLINE
ora.crsd   INTERMEDIATE
ora.evmd   INTERMEDIATE

进程虽存在：

ps -ef | egrep \
'ohasd.bin|ocssd.bin|octssd.bin|asm_pmon_\+ASM2|crsd.bin|evmd.bin' \
| grep -v grep

但 crsd.bin 长时间无法完成初始化。

检查 CRSD 日志：

tail -300 \
/u01/app/11.2.0/grid/log/sydb2/crsd/crsd.log

关键输出：

Initializing OCR

proprioo: for disk 0 (+OCRVOTE)
id match (1)
need recover (0)

Master host name [sydb1]
Attempting to connect to master at address [sydb1:...]

gipcretKeyNotFound
Policy Engine is not initialized yet!

说明：

本地 OCRVOTE 可以读取；
OCR 不需要恢复；
CRSD 在连接节点 1 OCR Master 时未能完成 GIPC 初始化；
Policy Engine 长时间保持未初始化状态。

3.8 检查 CSSD 网络心跳异常
#

后续一次启动时，CSSD 无法加入现有集群。

检查：

egrep -in \
'has a disk HB|no network HB|Local Join|sending join|takeover aborted' \
/u01/app/11.2.0/grid/log/sydb2/cssd/ocssd.log \
| tail -500

反复出现：

node 1, sydb1, has a disk HB, but no network HB

同时：

Node sydb1, number 1, is in an existing cluster with disk state 3
takeover aborted due to cluster member node found on disk
sending join msg to all nodes

这说明 sydb2 可以正常读取 sydb1 写入 Voting Disk 的磁盘心跳，但当时未能建立 CSS 网络心跳。

3.9 对私网、防火墙和网卡进行验证
#

节点 2 的私网配置：

ip addr show ens9f3
ip route show
ip route get 100.1.1.1 from 100.1.1.2
ip neigh show dev ens9f3

结果：

ens9f3 UP
100.1.1.2/24

100.1.1.0/24 dev ens9f3
src 100.1.1.2

100.1.1.1 dev ens9f3

100.1.1.1
lladdr d4:04:e6:0f:27:97
REACHABLE

节点 1 的 Oracle 私网定义：

oifcfg getif

结果：

ens9f0  138.20.1.0  global  public
ens9f3  100.1.1.0   global  cluster_interconnect

双向 Ping 正常：

0% packet loss
延迟约 0.2～0.3ms

ARP 正常：

Unicast reply from 100.1.1.1
[D4:04:E6:0F:27:97]

检查防火墙：

systemctl is-active firewalld
systemctl is-enabled firewalld

结果：

unknown
disabled

检查 iptables：

iptables -L -n -v
iptables -t raw -L -n -v
iptables -t mangle -L -n -v

结果均为：

policy ACCEPT

无 DROP 或 REJECT 规则。

检查网卡：

ethtool -S ens9f3 | egrep -i \
'error|drop|miss|crc|frame|fifo|timeout|reset|fault|buffer'

结果：

rx_fcs_errors: 0
rx_align_errors: 0
rx_frame_too_long_errors: 0
rx_in_length_errors: 0
rx_out_length_errors: 0
tx_mac_errors: 0
tx_carrier_sense_errors: 0
tx_errors: 0
rx_errors: 0

检查 UDP：

nstat -az | egrep -i \
'Udp|InErrors|RcvbufErrors|SndbufErrors|InCsumErrors'

关键结果：

UdpInDatagrams       107982
UdpOutDatagrams       50805
UdpInErrors               0
UdpRcvbufErrors           0
UdpSndbufErrors           0
UdpInCsumErrors           0

因此检查时点未发现：

防火墙阻断；
持续性二层或三层网络中断；
网卡 CRC 或物理层错误；
UDP 缓冲区溢出；
UDP 校验错误；
私网 IP 或路由错误。

CSSD 日志中的网络心跳缺失是真实发生的，但现有检查无法证明存在持续性的网络设备故障。

结合服务器已经确认的 CPU1/Socket1 不可纠正硬件错误，更合理的判断是：

CSSD、GIPC 和 CRSD 初始化异常属于主机硬件不稳定、多次 Kernel Panic 和异常复位后的次生表现。

四、根因结论
#

4.1 主根因
#

本次故障的主根因为：

sydb2 服务器 CPU1/Socket1 处理器子系统存在不可纠正硬件故障。

主要证据包括：

Machine Check Exception
Machine Check Exception (Uncorrectable)
System_MCERR
Socket1
CPU1
APIC 0x5c / 0x5d
Bank 0
micro-architectural error
Processor context corrupt
Fatal machine check
Fatal hardware error

4.2 故障机制
#

完整故障过程为：

CPU1/Socket1 发生不可纠正硬件错误
        ↓
CPU MCE 或 BIOS APEI/GHES 上报错误
        ↓
Linux 判断 Processor context corrupt
        ↓
Kernel panic - Fatal machine check
        ↓
kdump 保存 vmcore
        ↓
服务器自动重启
        ↓
Oracle Clusterware、ASM 和数据库实例被动中断
        ↓
部分启动过程中出现 CSSD/GIPC/CRSD 初始化异常

4.3 根因判断边界
#

现有证据能够明确证明 CPU1/Socket1 是主机反复重启的根因。

CSSD 日志中的：

has a disk HB, but no network HB

说明当时 Clusterware 网络心跳确实没有建立，但后续检查未发现持续性私网、防火墙、网卡或 UDP 协议栈异常。

因此，本报告不将网络问题列为本次事故的主根因，而将其归类为硬件不稳定及多次异常复位后的次生故障现象。

五、影响范围及处置建议
#

5.1 影响范围
#

本次故障造成以下影响：

sydb2 节点多次非计划退出。
infodb2 数据库实例多次突然中断。
RAC 服务发生漂移，客户端连接可能出现短时间中断。
Clusterware 资源曾长时间处于 OFFLINE 或 INTERMEDIATE。
节点重启后 CSSD、ASM、CRSD 无法稳定恢复。
多次 Kernel Panic 增加文件系统、Clusterware 本地状态及数据库恢复风险。
在硬件修复前，节点仍存在随时再次重启的风险。

5.2 立即处置建议
#

确认 sydb1 上数据库和业务服务正常：

crsctl stat res -t
srvctl status database -d infodb
srvctl status service -d infodb

停止并禁用节点 2 数据库实例：

srvctl stop instance \
  -d infodb \
  -i infodb2 \
  -o immediate

srvctl disable instance \
  -d infodb \
  -i infodb2

在 sydb2 停止并禁用 Clusterware：

crsctl stop crs -f
crsctl disable crs

硬件未修复前，不应再让 sydb2 承载生产数据库实例。

5.3 保留故障现场
#

保留以下材料：

/var/crash/*/vmcore
/var/crash/*/vmcore-dmesg.txt
Oracle alert_infodb2.log
Grid Infrastructure 日志
Linux audit 日志
/var/log/messages*
BMC/XCC System Event Log
XCC FFDC

由于 ABRT 存在容量限制，可能自动清理旧 vmcore，应及时备份：

mkdir -p /backup/sydb2_vmcore
cp -a /var/crash/* /backup/sydb2_vmcore/

5.4 硬件处置建议
#

向 Lenovo 提交硬件工单，要求重点检查：

Socket1/CPU1；
CPU 插槽；
主板；
CPU 供电模块；
CPU 散热系统；
BIOS/UEFI；
XCC/BMC；
CPLD；
CPU microcode；
CPU 与主板之间的信号链路。

工单中应提供以下关键词：

CPU1 Machine Check Exception (Uncorrectable)
System_MCERR
Socket1
APIC 0x5c / 0x5d
Bank 0
Processor context corrupt
Fatal machine check

优先由 Lenovo 根据 XCC FFDC、SEL 和硬件诊断结果决定更换：

Socket1 CPU
或
系统主板

5.5 修复后的验证要求
#

硬件维修或更换完成后，应进行以下验证：

导出并保留维修前 BMC SEL 和 FFDC。
运行 CPU、内存及主板硬件诊断。
检查是否仍出现 MCE、APEI、GHES 或 MCERR。
进行至少 24～72 小时 CPU 和内存压力测试。
检查 /var/crash 是否新增 vmcore。
启动 Clusterware，验证 CSSD 双节点成员关系。
验证两节点私网和 HAIP。
验证 Voting Disk 和 OCR。
验证 ASM 磁盘组。
验证数据库实例启动和 RAC 服务漂移。
稳定观察后再恢复生产承载。

六、最终结论
#

本次故障通过多层日志形成完整证据链：

Oracle 告警日志
确认数据库实例突然中断，无正常关闭记录
        ↓
Linux 启动记录
确认主机在短时间内多次重新启动
        ↓
Linux 审计日志
排除人工 reboot 和正常 shutdown
        ↓
kdump 和 vmcore
确认每次重启前均发生 Kernel Panic
        ↓
vmcore-dmesg
确认 Socket1/CPU1 Fatal Machine Check
        ↓
Lenovo BMC/XCC
确认 CPU1 Machine Check Exception (Uncorrectable)

最终定性为：

Oracle RAC 节点 sydb2 多次异常重启，是由 Lenovo 服务器 CPU1/Socket1 处理器子系统不可纠正硬件错误引起。Linux 内核检测到处理器上下文损坏后触发 Kernel Panic，kdump 保存转储并自动重启。Oracle RAC、ASM、Clusterware 和数据库实例均为被动中断。

重启后出现的 CSSD 网络心跳缺失、GIPC 连接失败和 CRSD Policy Engine 无法初始化，属于服务器持续硬件不稳定及多次异常复位后的次生故障表现，不应作为本次事故的首要根因。

在 CPU1/Socket1 相关硬件完成维修、更换并通过稳定性测试之前，sydb2 不应重新承载生产业务。

一、故障概述与系统环境#

1.1 故障概述#

1.2 系统环境#

二、故障现象#

2.1 节点在短时间内多次自动重启#

2.2 Oracle 实例随主机重启反复启动#

2.3 Linux 没有正常关机记录#

2.4 每次异常重启前均生成 vmcore#

2.5 vmcore 中出现明确的 CPU 致命错误#

2.6 BMC/XCC 记录 CPU1 不可纠正错误#

2.7 重启后 Clusterware 无法完整恢复#

三、排查过程#

3.1 从 Oracle 告警日志确认数据库不是重启源头#

3.2 核对主机启动时间与 Oracle 启动时间#

3.3 检查 Linux 审计日志，排除人工重启#

3.4 检查 kdump 状态和 vmcore#

3.5 分析 vmcore-dmesg.txt#

3.6 使用 BMC/XCC 进行硬件侧交叉验证#

3.7 核对重启后的 Clusterware 状态#

3.8 检查 CSSD 网络心跳异常#

3.9 对私网、防火墙和网卡进行验证#

四、根因结论#

4.1 主根因#

4.2 故障机制#

4.3 根因判断边界#

五、影响范围及处置建议#

5.1 影响范围#

5.2 立即处置建议#

5.3 保留故障现场#

5.4 硬件处置建议#

5.5 修复后的验证要求#

六、最终结论#