一. 故障场景

序列号：联想6241QEA_06FF412

操作系统版本：Redhat7.6

时间差：8小时

阵列卡：M5210

阵列卡微码版本：24.9.0-0026

阵列卡驱动：megaraid_sas  07.705.02.00-rh1

IMM：5.8

UEFI：4.9

系统名称：dresbdb02

架构信息：RAC - RAC 的 ADG架构

生产版本：Oracle 19.6

DB版本：Database Release Update : 19.6

OS版本：Red Hat Enterprise Linux Server release 7.6(Maipo)

于8月5日上午11点25分左右发生系统宕机

二. 故障现象

1. 11：25分左右，dresbdb02 linux操作系统宕机。

2. 日志显示在12：07分左右进行了启动os（客户手工启动）

3. 12：36分左右，因存在持续报错信息，客户联系请求到现场支持。

4. 下午1点到达现场，此时dresbdb02又发生宕机（后续看日志是在12：52分左右宕机）

5. 下午3点，主机工程师到达现场，后续进行检查硬件和换盘相关操作（硬件监控存在硬盘相关告警）。

6. 下午6点，换完盘启动os后，检查集群状态和相关日志正常。

三. 数据库和OS分析

1. 数据库日志进行查看分析

CRS Alert.log：记录CRS运行的主要信息

以上日志信息可以看出，相应的时间点已经出现crs agent等进程，执行check命令timeout abort等阻塞信息，此时的数据库或者OS便已经存在某些问题。

后续日志一直存在着调取资源timeout和abort的相关信息。

这里可以明确看出，节点2dresbdb02在os手工重启后，当前节点一直便存在问题，后续分析中也有相关佐证。

Ocssd.trc：集群的心跳进程日志

Gipcd.trc：集群中所有的私网网卡相关日志

节点2的日志显示相关时间点私网网卡信息不太正常，比较慢，非常不稳定（正常为rank 99）

DB alert log：记录数据库实例主要运行信息

iostat log：记录io相关信息

Psstat log：记录进程相关信息

从相关系统监控日志信息可以看到，首先在宕机之前的相应时段，OS便已经存在问题，出现了与磁盘相关的异常信息，进一步证明了原因并非为数据库导致（数据库并不可能导致OS相关命令的执行问题）。在OS日志上也存在信息断层情况，结合当时情况（磁盘硬件信息告警与换盘后集群状态恢复正常），可初步判断为硬件（磁盘相关）问题。

四. RAID LOG分析

检查Raidlog记录如下：

Firmware Package Build = 24.9.0-0026

Driver Name = megaraid_sas

Driver Version = 07.705.02.00-rh1

因为微码版本较低，不确定是否已经产生badblock。建议升级微码后，再观察是否出现badblock记录，若有badblock，则在备份数据后，必须低格全部硬盘再重做阵列。

五. 故障处理

1. 协调系统停机时间，升级微码

2. 升级微码后需要升级对应操作系统的官方驱动

3. 在业务部署前建议安装官方兼通的操作系统版本

若再发生Unexpected sense，需尽快移除硬盘，否则可能依旧会导致系统hung。

六. 经验总结

经过多层面分析，在进行raid log分析后可以得出定论，raid大量的CC校验错误消耗了controller太多的资源，触发了raid controller异常，因此出现了fatal error事件，并尝试通过reset去恢复。当raid card出现fatal error后，可能会导致主机hang或重启。

所有机器出厂时自带的微码，是当时节点最完善的版本。后期，研发工程师会逐渐修复、添加、完善。所以建议定期检查官网，获取更新版本，若有重大风险的，及时进行计划升级。