概述

我们在做数据库优化时查看awr报告总是一个有效的办法，从awr可以判断哪些等待事件占比比较重，然后先去优化对应的sql(80%的性能问题都是出在sql上)。但如果sql没问题呢？

优化思路

当我们从awr报告看到等待事件：db file sequential read过多时，一般第一步是会从优化有问题的sql上去入手（SQL ordered by Reads部分或者从 v$sql 视图中找出读取物理磁盘 I/O 最多的几个 SQL 语句），通过优化sql来减少I/0的读取请求。

但是当sql都没多大问题时，这时候我们就需要去检查各个数据文件的 I/O 分布情况了，看是不是有数据文件所在的磁盘存在大量的活动，导致其 I/O 性能很差。这种情况下可以通过查看awr报告中的“File I/O Statistics”部分或者 v$filestat 视图找出热点的磁盘，然后将在这些磁盘上的数据文件移动到那些使用了条带集、RAID 等能实现 I/O 负载均衡的磁盘上去。

下面介绍下涉及到的一些检查命令。

查看各个数据文件的 I/O 分布：

select d.name name, f.phyrds, f.phyblkrd, f.phywrts, f.phyblkwrt, f.readtim, f.writetim from v$filestat f, v$datafile d where f.file# = d.file# order by f.phyrds desc, f.phywrts desc;

这里可以看到数据文件的I/0分布，看是否正常。下面细分到物理段。

查找物理读取最多的索引段和表段

这里我们可以从 v$segment_statistics 视图中找出物理读取最多的索引段或者是表段，通过查看这些数据，可以清楚详细地看到这些段是否可以使用重建或者分区的方法来减少所使用的I/O。

从上面的查询可以看到相应的统计名称，使用下面的查询语句就能得到读取物理 I/O 最多的段：

ps:如果不存在有问题的执行计划导致读取过多的物理 I/O 的特殊 SQL 语句，磁盘的 I/O也分布得很均匀，这种时候可以考虑增大高速缓存区(这里大家根据Buffer Cache Advisory 工具来调整 Buffer Cache就可以了)

关于各个数据文件的IO分布及查找物理读取最多的索引段和表段的方法就介绍到这了，大家也可以自己去测试下。

后面会分享更多关于devops和DBA方面内容，感兴趣的朋友可以关注下！！