EN 联系我们加入我们
典型案例
您现在的位置:首页 > 典型案例
【案例分享】Oracle异常宕机的软硬结合跟因追寻


一. 故障场景

序列号:联想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:记录数据库实例主要运行信息

根据上面所呈现的数据库层面的相关日志信息,node dresbdb02从11:09分crs agent等监控进程执行check命令timeout abort等阻塞信息,在11:25分左右宕机,期间集群心跳和私网信息都存在问题,而宕机到启动期间,数据库日志断层,为突然的宕机行为,发生错误和宕机的原因基本上可以判定并不是数据库(CRS)发起,更大的可能是其他因素导致,需要进一步对操作系统等相关日志进行分析。


2. 操作系统(osw)日志分析

Messages 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


日志分析与建议:


在8月5日03:05时,即系统时间11:05期间,出现大量的Unexpected sense: PD 05(e0xfc/s1) 、Consistency Check corrected medium error 的错误,controller发生了几次fatal error/reset事件。

结合整个raid log分析,判断是由于大量的CC校验错误消耗了controller太多的资源,触发了raid controller异常,出现了fatal error事件,随后尝试通过reset去恢复。当raid card出现fatal error后,可能会导致主机hang或重启。

根据IBM/联想的官方文档,对于操作系统是 Redhat、Suse、Esxi,阵列卡是M1215、M5210时,如果使用的是操作系统自带的阵列卡驱动,则可能会造成系统死机、关机、重启等异常现象。建议是使用IBM/Lenovo原厂版本驱动替换操作系统自带的驱动。

另由于M5210在低版本时可能出现较多bug,建议由当前的版本24.9.0-0026升级至最新版24.21.0-0151,并同时升级IMM5.90 UEFI5.40。


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


五. 故障处理

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

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

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

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



六. 经验总结

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

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


版权所有 安图特(北京)科技有限公司 备案号:京ICP备17074963号-1
技术支持:创世网络