一、故障概述与系统环境
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 不应重新承载生产业务。
