35.由于磁盘故障导致的OracleRAC acfsload进程异常中断问题排查

1.环境说明

Oracle19.6.RAC ,redhat7.6 

2023-08-05上午11:09分突然出现告警日志acfsload进程启动失败。后续又导致集群重启，且当前节点重启失败。

2.问题分析

(1)磁盘IO分析

2023-08-05 11:04:46  磁盘IO等待。

（2）2023-08-05 11:09:21

 

%iowait=18.09  W_await=12.8s

W_await:平均每次设备I/O请求操作的等待时间(ms) ,dm-3磁盘每写入成功一次需要13s;

svctm：表示平均每次设备I/O操作的服务时间（以毫秒为单位）。对于普通硬盘来说，该时间通常不应该超过20ms。如果svctm的值与await很接近，表示几乎没有I/O等待，磁盘性能很好，如果await的值远高于svctm的值，则表示I/O队列等待太长，系统上运行的应用程序将变慢；

Await=12823ms Svctm=7468ms

（3）2023-08-05 11:09:56 集群开始告警

（4） 2023-08-05 11:14:14 IO延迟依然存在

 

（5）2023-08-0511:09:20

总共80个逻辑CPU,个别CPU的%IOwait=100

%iowait:表示等待进行I/O所使用的CPU的百分比。

 IO等待的CPU=%17.5   LOAD AVERAGE=14.21

 CPU的IO等待最高29%。

 CPU的负载达到:14,不算高。

 

（6）2023-08-05-11:19:53

每秒写入7K,每写入一次需要等待:23.7s; 这里磁盘有问题。

正常磁盘的读写都是几十M/s;磁盘写入慢可能是没有开启磁盘的高速缓存。或磁盘损坏。或磁盘阵列卡损坏。

 （7）2023-08-05 11:22:08 每秒写入很小，但是发生磁盘IO等待

（8） 2023-08-05 11:23:56 持续写入慢，IO等待严重

（）

 

正常普通机械SAS磁盘未开启高速缓存：写入速度约为:3M/s

正常普通机械SAS磁盘开启高速缓存：写入速度约为:130M/s

当前磁盘:sda 每秒写入108k,发生等待。

2号集群节点：Sda/dm-2/dm-3/dm-5/dm-6/dm-7 写入非常少,IO不大,但是等待极高。即数据无法落盘。

1号集群节点，未见明显IO等待。

写入等待持续高:

（9）2023-08-05 11:25:27 节点2被踢出集群。

（10） 2023-08-05 12:09:43 手工启动节点2;

 （11）2023-08-05 12:17 GIPC内部失败

2023-08-05 12:17:39.930 :GIPCXCPT:3421177600:  gipcInternalConnectSync: failed sync request, addr 0x7f21c00058b0 [00000000000003cd] { gipcAddress : name 'clsc://(ADDRESS=(PROTOCOL=ipc)(KEY=SYSTEM.evm.acceptor.auth)(GIPCID=00000000-00000000-0))', objFlags 0x0, addrFlags 0x4 }, ret gipcretConnectionRefused (29)
2023-08-05 12:17:39.941 :GIPCXCPT:3421177600:  gipcConnectSyncF [EvmConConnect : evmgipcio.c : 235]: EXCEPTION[ ret gipcretConnectionRefused (29) ]  failed sync connect endp 0x7f21c0004430 [00000000000003c6] { gipcEndpoint : localAddr 'clsc://(ADDRESS=(PROTOCOL=ipc)(KEY=)(GIPCID=00000000-00000000-0))', remoteAddr 'clsc://(ADDRESS=(PROTOCOL=ipc)(KEY=SYSTEM.evm.acceptor.auth)(GIPCID=00000000-00000000-0))', numPend 0, numReady 0, numDone 0, numDead 0, numTransfer 0, objFlags 0x0, pidPeer 0, readyRef (nil), ready 0, wobj 0x7f21c00074e0, sendp 0x7f21c0007290 status 13flags 0xa108871a, flags-2 0x0, usrFlags 0x30020 }, addr 0x7f21c00058b0 [00000000000003cd] { gipcAddress : name 'clsc://(ADDRESS=(PROTOCOL=ipc)(KEY=SYSTEM.evm.acceptor.auth)(GIPCID=00000000-00000000-0))', objFlags 0x0, addrFlags 0x4 }, flags 0x8000000
2023-08-05 12:17:39.941 : CLSCEVT:3421177600: (:CLSCE0047:)clsce_publish_internal 0x5577f71dd1e0 EvmConnCreate failed with status = 13, try = 0
2023-08-05 12:17:39.941 :GIPCXCPT:3421177600:  gipcInternalConnectSync: failed sync request, addr 0x7f21c0002ee0 [00000000000003de] { gipcAddress : name 'clsc://(ADDRESS=(PROTOCOL=ipc)(KEY=SYSTEM.evm.acceptor.auth)(GIPCID=00000000-00000000-0))', objFlags 0x0, addrFlags 0x4 }, ret gipcretConnectionRefused (29)
2023-08-05 12:17:39.941 :GIPCXCPT:3421177600:  gipcConnectSyncF [EvmConConnect : evmgipcio.c : 235]: EXCEPTION[ ret gipcretConnectionRefused (29) ]  failed sync connect endp 0x7f21c0003690 [00000000000003d7] { gipcEndpoint : localAddr 'clsc://(ADDRESS=(PROTOCOL=ipc)(KEY=)(GIPCID=00000000-00000000-0))', remoteAddr 'clsc://(ADDRESS=(PROTOCOL=ipc)(KEY=SYSTEM.evm.acceptor.auth)(GIPCID=00000000-00000000-0))', numPend 0, numReady 0, numDone 0, numDead 0, numTransfer 0, objFlags 0x0, pidPeer 0, readyRef (nil), ready 0, wobj 0x7f21c00023b0, sendp 0x7f21c003e430 status 13flags 0xa108871a, flags-2 0x0, usrFlags 0x30020 }, addr 0x7f21c0002ee0 [00000000000003de] { gipcAddress : name 'clsc://(ADDRESS=(PROTOCOL=ipc)(KEY=SYSTEM.evm.acceptor.auth)(GIPCID=00000000-00000000-0))', objFlags 0x0, addrFlags 0x4 }, flags 0x8000000
2023-08-05 12:17:39.942 : CLSCEVT:3421177600: (:CLSCE0047:)clsce_publish_internal 0x5577f71dd1e0 EvmConnCreate failed with status = 13, try = 1
2023-08-05 12:17:39.953 : default:3651779840: clsu_load_ENV_levels: Failure to retrieve ORA_DAEMON_LOGGING_LEVELS environment variable [-1] [21104].

Bug 29416851  由此bug引起，Doc ID 29416851.8

已经在19.6.0.0.200114 (Jan 2020) OCW Release Update Revision(OCW RU)

29416851 升级补丁包是这个,已经在当前的版本中有了,但是依然报这个错误。

 

12:09分:手工启动集群后，通过与现场人员沟通，夯死很久才启动，且不久又自动宕机。且发现一块磁盘有问题，下午5点后更换磁盘，正常启动集群。

12:25分:GIPCD进程请求保存信息全部失败。

后续GIPCD集群私网管理进程持续报保存信息失败。

2023-08-05 12:37:45 此报错信息一致持续到这个时间点。

（12） 2023-08-05 12:37:45.419 :GIPCGEN:225855232:  gipcRequestSaveInfo: error during completion of  req 0x7f8ff806f2c0

gipcd进程的请求失败夯死

gipcd进程的请求失败夯死，导致ocssd服务失败，ocssd服务失败最终导致集群重启和数据库重启。发生问题的dump core分析

2023-08-05 12:38分:core-dresbdb02-1001-gipcd.bin-30316-1691210294

core文件的内容和集群的日志相同,都是gipcd进程访问失败。

gipcd进程异常中断，导致CSSD进程中断，最终导致节点重启。

（13）分析服务器异常重启前coredump文件内容：

 Core文件里面的日志:物理存储访问失败，本地集群注册表OLR写入失败

 （14）2023-08-05 12:37 gipcd进程夯死

 

gipcd进程 经历一个错误异常码是:6

orarootagent 无法执行命令

（15）2023-08-05 12:38 集群启动

（16） 2023-08-05 12:41 数据库启动

 

（17）上面的报错过程总结如下：

2023-08-05 12:17分及之后的过程。

1).gipcd 进程无法保存信息成功,并多次尝试保存请求但并未成功

2).gipcd 进程夯死

3).由于gipcd进程夯死导致cssd时钟同步服务失败

4).时钟同步服务失败导致集群重启

5).集群重启，数据库重启。

GIPCD进程失败导致集群重启的依据如下:

Oracle企业版:12.1.0.2 及以后的版本。

Doc ID 2785447.1

 （18）历史出现问题时的coredump

可以看到历史也是gipcd进程或者ocssd进程失败。

 （19）总结如下

按照时间线进行梳理可以发现：
在2023-08-05 11:09分之前SDA/DM-2/DM-3/DM-5/DM-6/DM7 几块盘写入持续IO等待较高，但没有接下来的时间高。DM的开头的其他几块盘无写入IO。
在2023-08-05 11:09分及之后持续保持较高的IO等待,达到写入一次需要13s,0.85K/s写入速度明显异常。
在2023-08-05 11:09 同时出现集群告警启动:acfs_load进程异常终止,并伴随其他告警。
在2023-08-05-11:19:53 IO写入等待达到23s写入一次,7K/s的速度,磁盘写入速度明显出现异常并持续。
在2023-08-05 11:25 节点2退出集群,并伴随GIPCD进程请求保存信息失败的日志。
在2023-08-05 11:25~2023-08-05 12:09 这中间没有日志,集群失败后未启动。
在2023-08-05 12:07 重启服务器，重启服务器并发现一块磁盘异常。
在2023-08-05 12:09 人工启动集群节点2,并夯死很久才启动
在2023-08-05 12:17 gipcInternalConnectSync: failed sync request
在2023-08-05 12:25分:GIPCD进程请求保存信息全部失败,后续GIPCD集群私网管理进程持续报保存信息失败。
在2023-08-05 12:37:45 GIPCD进程报错信息一致持续到这个时间点。同时伴有gipcd的coredump文件显示,物理存储访问失败，OLR本次注册文件写入失败等信息。
在2023-08-05 12:41 数据库启动
在2023-08-05 12:50 ASM实例关机或失败,数据库关机或失败。
在2023-08-05 16:08 又重启服务器,此时应该是尝试重启或者更换磁盘结束后重启。
与现场人员沟通更换磁盘差不多4-5点钟。
在更换磁盘后集群正常启动。

小结:
磁盘IO明显出现异常，数据无法及时写入，并伴随集群出现异常，最终发现磁盘损坏。
正常SAS机械磁盘未开启高速缓存功能:写入速度:3M/s
正常SAS机械磁盘开启高速缓存功能:写入速度:130M/s
当前磁盘的写入速度:1K/s~600K/s。

• （20）处理方法

• 根据之前的日志分析,Sda/dm2/dm-3/dm-5/dm-6/dm-7 这几块盘都有写入性能问题，其他盘未写入，可以推断写入性能相似，ASM存储里面的盘写入IO3M/s写入不大且稳定。如果机器接近维保时间的结束,则意味着磁盘可能确实达到寿命，需要更换。如果未过维保期，则使用fio工具测试磁盘的写入性能，并开启磁盘的高速缓存功能，以达到更好的写入效率，或检查RAID配置是否最佳。Sda/dm2/dm-3/dm-5/dm-6/dm-7这几块盘需要重点检查。理清楚这些盘对应哪些目录或文件系统。
  节点1在相同时间内暂未发现磁盘IO性能差,因为写入太小看不出来。
  
  
  
  
  
  
  

  3.总结

• 在这个案例中，不仅有磁盘的物理损坏，同时还存在RAID卡问题导致的整体的本地磁盘写入慢的问题。所以，磁盘RAID阵列卡的失败，可以导致写入性能问题，同时导致服务器重启，以及集群的重启。所以在数据库的运维中也需要定期观察写入性能的变化，方式磁盘阵列卡的失败，导致的磁盘损坏及停机。

• 好在当前库只是RAC的备RAC库，不是主库，所以允许适当的停机。