Exadata IO响应延时案例分析

个人简介:石云华,Exadata中国用户组联合创始人,2019年被ORACLE官方授予ACE称号。毕业后一直从事Oracle数据库第三方运维服务工作,拥有十余年电信运营商、保险、税务、电力行业核心系统数据库运维经验。现就职于北京海天起点技术服务股份有限公司,oracle数据库专家组成员,Exadata部门负责人。个人著作有《Exadata实施运维指南》,另外一本《Oracle Exadata性能优化》即将面世。

案例概要:

这个案例还是来自于我们的一个Exadata客户,该客户的Exadata经历了几次IO性能问题后,他们对IO的性能表现就异常地关注,IO性能稍稍有点风吹草动,就希望能尽快找到原因,其实这也能理解,要将问题扼杀在摇篮里。

有一天,客户在监控EM12C时,突然发现有一个时间点,cell02存储节点的机械硬盘平均响应时间出现了一个峰值,高达500k毫秒。客户想清楚为什么会出现这个峰值,是否会影响到数据库。

案例分析及处理:

查看EM12C中IO指标

存储节点cell01和存储节点cell02的平均响应时间,如图10.11所示。

图10.11(a) cell01平均响应时间 图10.11(b) cell02平均响应时间

可以看出,在2015年10月18号下午左右,cell02存储节点的底层机械硬盘的平均响应时间的确出现过峰值,而其它存储节点的响应时间则相对平稳。

分析数据库日志

在cell02存储节点的机械硬盘响应时间出现峰值的时刻,数据库alert日志中也记录了如下错误信息。

从以上数据库alert日志可以看出,是磁盘disk RECOC1_CD_06_DM01CELADM02出现IO异常。于是数据库发生了redirect操作,从镜像磁盘DATAC1_CD_08_DM01CELADM01中重新读取数据块。

针对以上日志信息,MOS文档《ORA-27626: Exadata error : 2201 (IO cancelled due to slow/hung disk)》(Doc ID 1925661.1)有进一步的解释,这是存储软件11.2.3.3.1版本之后的一个新特性(Exadata I/O Latency Capping),存储软件会自动取消读取慢的操作,然后将这个读取数据块的操作重新指向镜像数据块上。更多地,ORACLE是把这些信息当作警告信息,而不是故障信息。有一个单独的补丁(19014915)可屏蔽掉这些警告信息,但这些信息无害,其实建议保留这些信息。

分析存储软件日志

下面,需要分析的是为什么数据库在读取主数据块时会出现IO异常?查看CELL02存储节点的存储管理软件alert日志,具体日志内容如下。

从上面cell02存储节点的alert日志可以看出,在18号14点02分左右,该存储节点提示CELLDISK(CD_06_dm01celadm02)上的GRIDDISK(DATAC1_CD_06_dm01celadm02)出现了4次读取错误。

检查griddisk状态

检查cell02存储节点griddisk的IO错误信息,具体命令如下。

从上面的命令输出也可以看出,该CELL02存储节点只有一个GRIDDISK出现IO错误,并且正好出现了4次IO错误,这个GRIDDISK也即DATAC1_CD_06_DM01CELADM02。

检查物理磁盘状态

检查cell02存储节点上所有机械硬盘的IO错误信息,具体命令如下。

从上面的输出可以看出,该存储节点中有一块盘出现了介质错误,而正是这个出现介质错误的磁盘上的griddisk出现了IO异常。

由此可以看出,是由于底层的物理磁盘出现IO故障导致,导致需要访问的数据块无法响应IO请求,所以会出现IO峰值。

案例解决方案:

Cell02存储节点的LUN 0_6这块磁盘已经出现介质错误,说明这块磁盘可能接近损坏,需要关注,但暂时无需更换,因为到达一定的阀值,存储管理软件会自动地将该磁盘标记为”故障磁盘”。

未经允许不得转载:Oracle一体机用户组 » Exadata IO响应延时案例分析

相关推荐