Exadata自动磁盘擦洗和修复特性对IO的影响

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

案例概要

客户的一套业务系统,刚刚从传统的架构迁移至Exadata上,在某一天早上8点开始,客户发现Exadata上机械磁盘的IO使用率突然增长至60%以上,并且这一现象一直持续,严重影响了业务系统的IO响应,具体如下图所示。


 Exadata上机械磁盘的IO使用率

客户表示最近的业务未明显变化,并且早晨8点还没到业务高峰期,从图中可以看出,磁盘的IO使用率,从8点整开始,突然爆涨好多倍。

问题分析

从EM12c上Exadata的监控来分析当前IO的使用情况,如下图所示。


 Exadata上机械磁盘的IOPS和MBPS

从上图可以看出,从早上8点开始,磁盘的IOPS虽然有所增长,但仍然是非常低,然而MBPS部分却突然大幅增长。这可以说明磁盘正在经历顺序读的IO请求,而不是随机读的IO请求。

既然磁盘IO被占用了60%多,那么我们有必要清楚,这些IO到底被哪个数据库占用了。进一步检查发现,磁盘的IO占用率基本全是_OTHER_DATABASE_部分,而在该Exadata上的另外两个核心生产数据库的IO使用率反而比较少。具体如下图所示。


 Exadata上所有数据库的IO占用率

这就比较奇怪了,_OTHER_DATABASE_部分占用如此大的IO,那么具体有哪些工作是包含在_OTHER_DATABASE_部分中的?

下面,我们继续细分_OTHER_DATABASE_部分的IO,如下图所示。


 Exadata上_OTHER_DATABASE_数据库的IO占用详情

从图表可以看出,_OTHER_DATABASE_.CELL_DISK_SCRUB部分占用了全部的MBPS。从CELL_DISK_SCRUB关键字,我们可以看出这是在做磁盘的擦洗工作。默认情况下,这个工作会两周执行一次。

下面,我们来进行验证当前是否有磁盘擦洗操作正在运行。

  • 检查存储节点的alert日志,最新的日志如下所示。

从存储节点的alert日志可以看出,在当天的早上8点整,针对12块celldisk开始发起磁盘擦洗操作。

  • 继续检查磁盘擦洗操作相关的设置,信息如下。

从以上的磁盘擦洗操作相关设置可以看出,磁盘擦洗操作默认在8点开始执行,每两个星期执行一次。

解决方案

从上面的信息可以看出,正是由于磁盘擦洗操作导致了IO使用率突长,我们可以选择调整该特性的发起时间,或选择关闭该特性。

如果一个磁盘擦洗操作已经自动发起,但是它严重影响了数据库的IO性能,该如何停止正在进行的磁盘擦洗工作呢,可以通过如下命令。

它将停止当前正在运行的磁盘擦洗作业,并且以后也不会再进行磁盘擦洗工作。

通过命令修改磁盘擦洗工作的频率,具体命令如下。

注意,修改工作频率的有效选项只有:daily、weekly、biweekly和NONE,NONE选项即立即停止当前正在运行的擦洗作业。

通过命令修改磁盘擦洗操作的开始时间,比如立即执行磁盘擦洗工作,具体命令如下。

或者,指定某个具体的时间执行,比如凌晨2点,具体命令如下。

根据每天的高低峰期,重新合理设置磁盘擦洗操作的开始时间。

未经允许不得转载:Oracle一体机用户组 » Exadata自动磁盘擦洗和修复特性对IO的影响

相关推荐