Exadata中，某块griddisk的性能下降，导致整个磁盘组的IO受到影响

前段时间， 一个朋友分享了Exadata上的一个案例，结论是：当ASM磁盘组中的某个griddisk的IO性能远低于同一磁盘组的其他griddisk时，会导致该ASM磁盘组的整体IO都受到影响。 以前只遇到过Exadata闪存卡出现故障时，可能导致整个ASM磁盘组的IO性能受到影响的案例，像这样某个griddisk的IO低下导致整个ASM磁盘组IO受到影响的案例还未遇到过。故记录下来。

 

1. 案例概述。 某客户的一套经分系统运行在Exadata上，每晚都会做大量的数据加工操作，运行的SQL语句基本上都是多表关联，然后就是分组、排序等等这些操作，典型的OLAP系统，所以IO消耗极大。正常的时候，虽然IO操作的平均延时也比较大，但系统还算可以正常运行， 突然某天，存储节点上有块机械磁盘出现损坏后，整个业务系统就出现堵塞，IO表现非常差。（需要说明，虽然有一块机械盘损坏 ，当此时并未触发整个ASM磁盘组的rebalance操作，故排除ASM rebalance导致IO性能下降）

 2. 分析AWR报告

 系统的压力还是比较大的。

 基本上是物理读写，差不多每秒7GB的IO读写。如果是传统架构的ORACLE，估计数据库早就挂了。

 从等待事件来看，问题就出在IO上，IO读写的平均延时都高达几百ms了。

AWR报告中的一些其他信息就不过多说明了，直接说与结论相关的信息。

 该朋友发现除了损坏的那个机械磁盘处于missing状态之外，还有另外两块磁盘的IO性能处于异常状态。分别为：CD_10 和 CD_02。这两块磁盘的平均等待时间远高于其他的磁盘。

 

3. 处理办法：

最终，将CD_10 和 CD_02 这两个celldisk上所有的griddisk全部置于inactive状态，也即将这些磁盘临时踢出ASM磁盘组。 整个IO性能立即恢复到正常水平，业务系统的堵塞情况很快消失。

 

思考： 这个故障最终能得到解决，19C新版本数据库对AWR的特性增强是有很大的帮助的，可以从AWR报告中很直观地看到Exadata自身的一些问题。 然而11.2.0.4老版本的AWR报告中，就不存在Exadata相关的性能指标。当怀疑Exadata自身出现问题时，就需要额外收集Exadata性能相关的metric进行分析，这对于一些不是很精通Exadata的技术人员而言，明显增大的故障的分析难度。