oracle数据库最小io交换单元,ORACLE数据库服务器IO高的分析方案和案例探讨

前言

笔者在为数据中心提供Oracle第三方服务的过程中接触过很多系统/存储管理员，发现很多SA对ORACLE数据库缺乏足够的了解，导致在处理综合问题时容易各说各话，因此才有了写这一个系列文章的想法，本意是尽可能用大白话为大家普及一些常见问题所需的理论，辅以几个实际的案例分析，希望对大家以后的工作有所帮助。

言归正传，在部署了ORACLE数据库的服务器上，我们大家或多或少的遇到过下列情况：

1. 业务系统运行缓慢，作为系统管理员需要检查包括IO在内的系统资源，这时系统管理员、存储管理员可能得到DBA(数据库管理员)的反馈说，IO的响应时间很慢，达到了30毫秒以上，要求解决。但存储管理员检查又不存在热点盘的情况，系统的IO量就是很大，除了使用更多的RAID组来重新分布数据、更换为更高端的存储外，似乎没有太好的办法；

2. 我们可能通过iostat和sar -d命令观察到磁盘的busy很高、每秒的IOPS很高、每秒的IO读写量很大、HBA卡的流量很高等危险的现象；

3. IO响应时间长，到底是导致业务慢的原因还是结果？

4. IOPS很高、IO读写量很大，到底是原因还是结果？

5. 除了硬件的扩容或升级，难道没有别的解决方法么？

6. 如何识别ORACLE服务器上的IO来源，如何判断这些IO是否是有效IO，怎么消除无效IO？

7. 作为系统管理员和存储管理员需要掌握哪些数据库简单技能才不会在出现IO问题时处于被动的局面？

8. ORACLE DBA评判IO是否有性能问题的标准是什么？

9. ORACLE数据库的IO有什么特点？哪些IO是比较关键，是必须保障性能的？

我们将通过理论和实际案例穿插介绍的方式为大家进行讲解和分享，希望对大家有所启发。

本文是系列的第一篇。需要说明的是，由于篇幅有限，会暂时省略掉部分在过程中实际发生但与本主题不是那么密切的内容，如UNDO、checkpoint等内容。

同时考虑到AIX专家俱乐部可能更多的是系统/存储管理员，因此会有部分科普的内容，水平较好的ORACLE DBA可以自行跳到案例探讨环节。对于没有真正做过DBA的同学来说，ORACLE可能稍微有点难，但只要静下心来花点时间去主动了解了，那就不难了。

慧眼识珠--服务器磁盘这么繁忙，到底是谁干的？

出一个问题时段的AWR报告，将awr报告对应的html文件下载到PC终端

用IE等浏览器打开，查找”SQL ordered by Reads”部分，如下图所示

可以看到：

1) 排名第一的SQL语句，占了整个数据库服务器IO的99.79%

2) 一共执行了8次，每次执行发生的IO是2，129，053个BLOCK，一个BLOCK是8K，即每次执行该SQL，将发生2，129，053*8K=16.24G

知识点：

BLOCK是ORACLE数据文件的最小分配单元，类似LV的PP，数据就存储在BLOCK中，一个BLOCK可以存储几十到几百条不等的用户表的数据

是不是很简单？

当然，大家也可以用操作系统的命令也可以看到进程级的IO分布情况。

例如Linux环境下通过pidstat -d 可以监控哪个进程IO消耗较高。

当然，采用操作系统方式查看进程级别的IO分布的方式的缺点是很显然的，更可怕的是，这表明你依然在把数据库当黑盒子来看待，进程具体在做什么？为什么IO那么高？

我们需要继续往前一步。

谨记于心--ORACLE DBA判断IO有性能问题的标准

知识点：

一般来说，如果单个IO的响应时间在20毫秒以内，是可以接受的，较好的性能应该在10个毫秒以下，越低越好。超过20毫秒的单个IO响应时间，则可认为性能不佳，需要做调优。需要说明的是，对于IO次数只有个位数的文件，IO超过20毫秒，也是可以接受的，因为在存储层面不容易被cache。

通过OS和数据库AWR报告两个方式均可以判断IO是否有问题，建议以OS方式为准。

操作系统方式

sar –d 2 10的输出中，avwait和avserv两列之和即为IO的响应时间(AIX环境)，单位为毫秒。LINUX环境下有区别，IO的响应时间为AVWAIT列。

可以看到：

hdisk4上单个IO的响应时间达到4000多毫秒和2000多毫秒，远远大于20毫秒，IO性能到了无法忍受的地步，需要尽快分析是否存储存储cache被关闭，硬盘是否出现故障、链路是否出现问题等情况。

数据库AWR报告方式

下图的Av Rd(MS)表示单次读的毫秒数，即为单个IO的响应时间。可以看到，在0.01毫秒，远远低于20毫秒，IO性能非常的好！(能达到整个性能，往往是在文件系统缓存中被缓存了)

下图的Av Rd(MS)表示单次IO读的毫秒数，即为单个IO的响应时间。可以看到，大部分数据文件的IO响应时间超过40毫秒，远远大于20毫秒，IO性能不理想，在对存储进行扩容或者升级前，应该先好好分析IO是否是无效IO，是否可以消除无效IO！通过SQL优化消除无效IO，可以有效保护存储等硬件的投资，满足未来多年的业务发展，而不是盲目扩容。