关于IO负载的问题

ALLSTARS_ORACLE

1、OS与ORACLE的IO负载区别在哪里？主要都是指存储的IO指标吗？

     OS的IO负载使用操作系统命令统计，ORACLE的IO负载如何获取，尤其是IO利用率？

2、IO问题一般的解决思路是什么？

     比如分析数据库报告等待事件.........

3、调优的思路和常用手段有哪些？

     比如优化SQL减少物理读/写，条带化存储，文件系统的异步IO、Direct IO等

1. ORACLE的IO负载如何获取，尤其是IO利用率？

不清楚这里IO利用率是具体指什么.
我们从oracle的角度衡量IO负载/性能,可以通过AWR的如下信息去看:

a)  在一段时间内的总共的物理读 (SQL ordered by Reads部分有"Total Disk Reads"指标)
b). 单块读的平均消耗时间 (db file sequential read指标的Avg wait (ms))
c). 多块读的平均消耗时间 (db file scattered read指标的Avg wait (ms))
d). Tablespace或者datafile level平均的读/写时间 (IO Stats部分,关注Av Rd(ms)和Av Buf Wt(ms))
e). logfile的平均写时间(log file parallel write的Avg wait (ms)指标)
f). 还有其它的一些后台的读/写等待事件的Avg wait(ms)指标

需要注意的是:

1. Oracle的performance tuning guide里提到单块读平均时间长于20ms就认为系统有问题了 ->  这其实需要具体情况具体分析,比如一个平时平均读时间只需要5ms的系统,忽然变成需要15ms,那么我们就认为它有问题了.
2. 注意AWR中这些平均的时间metric只是平均值,它可能掩盖了在某一两分钟内发生的IO极端慢的情况.
3. 关于Tablespace或者datafile level平均的读/写时间,假设这个datafile/tablespace的总共读的次数就是很少的,那么因为硬盘需要寻道会花额外的时间,这时候会有很高的Av Rd(ms)和Av Buf Wt(ms) --> 这是正常现象,可以忽略.
4. Oracle认为的物理读包括OS从高速文件缓存中获取数据的情况. 就是说有时候某个db file sequential read只需要花0.1ms就得到,那么很可能是Oracle虽然发起了物理读的请求,但是OS从OS的filesystem cache中发现了它,所以读操作并没有发送到物理硬盘

2. IO问题一般的解决思路是什么？
从多个方面/维度去衡量这个问题

同好的AWR对比
a). 是否Oracle发起了过多的物理读,若是,检查SQL ordered by Reads (注意AWR并不能把所有的物理读的SQL都抓到,比如awr中可能会说Captured SQL account for 50.6% of Total,就是抓到的SQL所做的所有的物理读只占总共物理读的50.6%,剩下的物理读相关的SQL语句,AWR并未捕获)
b). 是否单块读/多块读的平均时间变长
c). 是否datafile的平均读/写时间变长

同OS的监控工具抓到的好的时间段的报告对比:
d). Service Time是否变长
e). Queue size是否变大
f). IO量是否变多
g). 磁盘的利用率(utilization)是否变高，比如从60%到80%  ===> 这里要注意，并不是IO 等待要到100%才说明IO有问题。 假设平时IO等待是15%，而出问题时是30%，那么IO性能就比平时慢的很可观了

还需要注意的是IO并不是一个孤立的OS资源，假设CPU runqueue过高，或者memory使用出现状况，都可能伴随IO变慢的情况。

3. 调优的思路和常用手段有哪些？

a). 调整SQL降低物理读永远都是一个好的方法
b). 条带化存储，文件系统的异步IO、Direct IO 这样的操作并不是在所有的情况下都合适，我们碰到过使用了这些技术反而让数据库变慢的情况。

举例子来说，一个很小的业务系统，数据量只有10几GB，大部分的数据都已经cache在操作系统的文件缓存中；这时候DB发起的单块物理读是很快的，<1ms。
在改为DIO之后，每次DB都需要去硬盘获取数据，这时候DIO反而让事情更糟，单块读可能要>5ms。

所以类似这样的change，一定要好好地做测试;因为它和硬件，应用类型都有关系。这几种方案可能对很多系统有好处,但是Oracle或者DBA并不能知道这个change做下去一定对你的系统有好处。

c). 再加一条，非软文，把datafile放在企业级 SSD 系统里面，有时候IO的瓶颈就会得到缓解。


总之,IO问题它牵扯到了OS，有时候从OS的层面看IO问题就比较复杂了。

我碰到的一个极端例子就是DB/OS层面只能看到IO有问题，但是很难厘清root cause. 往往我们很难依靠存储工程师，只要他们看到存储日志中没有任何报错，就简单的说存储性能没问题。
那个例子最后发现是存储使用的HBA卡上的QueueSize已经很大了，最后将HBA卡从2G升级到4G才解决问题。所以在IO瓶颈发生在HBA卡的IO queuesize上时，DBA和OS administrator有时很难给力...