数据库IO子系统是数据库健康运行的十分关键的子系统。我们该如何对Gaussdb 100的数据库IO进行健康诊断呢？
在这套环境中，我们为DBIO健康诊断设置了9条诊断路径，其中四条内部诊断路径分别为：数据库IO指定时间窗口总量分析
数据库IO指定时间窗口等待事件分析
指定时间间隔内IOPS指标趋势分析
指定时间间隔内MBPS指标趋势分析
还有五条是外部诊断路径（也叫直接关联诊断，关联诊断路径是在怎段过程中直接诊断路径发现可能存在的诊断路径，是在诊断过程中自动添加的；除此之外，当然还有间接关联诊断，间接关联诊断是通过“智能标签”来进行临时手工匹配的，并不是自动组合的诊断路径），当内部诊断路径并不能明确的指出问题在哪或者诊断过程中发现了其他需要诊断的问题的时候，就会引出直接关联的直接诊断路径：
分析服务器IO设备的IO情况
物理读较多的TOP SQL
数据库负载情况分析
GaussDB 100数据库会话分析
分析数据库实例情况
我们用一个实际案例来看一看这个分析是如何进行的。首先我们来看IO总量的分析：
可以看出设备的IO延时是正常的，IOMB（吞吐量）是169M每秒，算比较高了，不过由于使用的是SSD设备，因此，对于本设备的能力来说，被评定为中等负载。IOPS指标的平均值超过5000次，根据设备基线评定为巨大。从第一个诊断项看出，设备IO延时正常，量比较大。此时我们无法定位问题，不过起码说明物理设备的IO延时是正常的。我们继续往下看：
从IO相关的等待事件，单块读和多块读的情况看，多块读的数量较多，诊断工具提示：说明系统中存在大量全表扫描或全索引扫描的SQL,需进一步分析逻辑读较高和物理读较高的SQL,或者交给开发商检查应用从单块读与多块读的延时上看，多块读的平均值虽然在正常范围内，不过最大值超过了设备的基线：
数据库IO等待事件db file scattered read 的最大等待时间超过了其基线指标值20.0ms,当前的指标为34.16ms,系统的IO性能可能存在问题而单块读的指标是正常的，这种情况在ORACLE数据库中很少见，gaussdb 100为什么会出现这种情况，还需要进一步的研究。从这里我们已经看到了一定的问题了。再继续看下去：
从IOPS的趋势分析来看，工具发现IOPS在这段时间内是急剧上升状态：既然是急剧上升，那么我们有必要去看看数据库的负载了，通过相关的关联诊断路径我们可以看到系统的负载情况：
工具发现数据库的负载的很多指标项都处于异常状态，在这种情况下我们可以去继续检查下TOP SQL的情况了：
可以看出大量的SQL在出现问题的时间区间里的执行次数极高，产生了大量的IO。至此，我们可以十分确定的认为当前的IO异常是因为应用负载大幅增加导致。
最后修改时间：2020-03-11 14:05:16
文章转载自
白鳝的洞穴，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
