解决IO问题的常用方法：
使用Statspack类似的工具对数据库响应时间分析之后，已经表明与IO相关的等待事件限制了系统性能，有许多的方法可以判断这种问题。
接下来的章节会介绍排查等待事件的方法。
有一些方法可以不用管特定的等待事件。在这个章节，会介绍和解释每个方法背后的概念和基本原理。
通过对SQL的调优降低数据库的IO请求：
没有用户SQL使用的数据库只会产生很少甚至不产生IO。最终由数据库产生的IO都会直接或间接地源于用户执行的SQL的本质和数量。
这就意味着通过控制SQL语句产生IO的数量，有可能限制数据库的IO请求。通过调优SQL可以达到这样的目的，让他们的执行计划产生最小的IO操作数量。
在典型的问题场景下，可能只有很少的SQL，由于他的执行计划非最优，导致产生比常用更多的物理IO，降低数据库的整体性能。
从Oracle 10g开始，ADDM通过自动识别最有影响的SQL语句，可以辅助SQL调优过程。然后，SQL调优建议器能够用来自动调整这些语句，降低IO资源消耗。(可以参考Document 262687.1 How to use the Sql Tuning Advisor)。
通过调整实例参数降低数据库的IO请求：
1. 使用内存缓冲限制IO：
数据库需要的IO数量受内存缓冲量的限制，例如Buffer Cache，Log Buffer，不同的Sort Areas等。增大Buffer Cache，可以为数据库进程(逻辑IO)产生提供更多的buffer访问，满足将磁盘(物理IO)读取转为内存读取。如果有更大的内存排序区，那么排序操作期间资源消耗殆尽，导致不得不使用磁盘的临时表空间，这样的可能性就会降低。其它缓存也依照类似的概念工作。
2. 调整多块IO(10g之前)的大小：
独立的多块IO操作大小能够通过实例参数控制。当达到极限值时，相比使用更多更小的IO，使用更少更大的IO时，多块IO会执行得更快，例如，同样传输100Mb的数据，相比每次100Kb的数据传输请求1000次，或者每次10Kb的数据传输10000次，每次1Mb的数据传输100次显然要完成得更快。当达到极限值后，区别就不那么明显了：1Gb的数据传输，每次10Mb大小请求100次(如果操作系统最大IO传输大小限制允许)，可能和一次传输1Gb大小的效率一样。究其原因，是因为一次IO处理的时间主要包括两个组件：
IO创建时间：
对于不同的IO容量基本一致，对于小IO容量则占据总体服务时间的大部分。
IO传输时间：
随着IO容量的增长而增加，对于小IO容量，通常小于IO创建时间。
以上的结果，在10g R2以前，通过配置DB_FILE_MULTIBLOCK_READ_COUNT参数以使数据库可以使用更大、更少的多块IO，来更好地配置实例。
10g R2之后，这个参数会自动设置，不建议人为修改。可参考：Document 841444.1 How To Set DB_FILE_MULTIBLOCK_READ_COUNT in 10g。
操作系统级别的IO优化：
充分利用IO处理能力，例如异步IO，或具有高级功能的文件系统，例如直接IO(绕过操作系统文件缓存)。另一种方法就是提高单次传输允许的最大IO容量限制(参考本文的max_io_size)。
通过使用Oracle ASM(Automatic Storage Manager)平衡数据库IO：
ASM在Oracle 10g中引入。他是一种文件系统，一种卷管理器，内建于数据库内核。他可以自动并行地进行所有磁盘驱动器的负载均衡，防止热点与性能最大化，甚至对于有数据快速更新的环境也适用。它能防止碎片化以至于从来不需要迁移数据回收空间。所有磁盘上的数据可以很好的平衡与条带化。细节也可以参考Document 249992.1 New Feature on ASM (Automatic Storage Manager)。
通过使用条带化，RAID，SAN或NAS平衡数据库IO：
这种方法依赖于存储技术，例如条带化，RAID，存储区域网络(SAN)和网络附加存储(NAS)，他们可以在多物理磁盘之间自动地平衡数据库IO的负载，目的就是避免磁盘争用和IO瓶颈，因为在存储硬件上可能还有未使用的磁盘空间。更多的技术细节可以参考："Optimal Storage Configuration Made Easy" by J. Loaiza，Document 30286.1 I/O Tuning with Different RAID Configurations。
通过在不同的文件系统，控制器和物理设备中手工移动数据库文件，重新分布数据库IO：
这是在缺少高级现代存储技术下的一种方法。目的就是为了分发数据库IO，以至于IO请求中不会有单组磁盘或控制器处于饱和，这里可能还有未使用的磁盘空间。与之前的方法相比，这种方法可能使用起来更困难，通常可能没用。
在大多数据库中IO是肯定存在的。之前介绍的所有方法都考虑后，如果已存系统的性能仍旧不满足，那可以考虑：
通过将旧的数据迁移，降低当前数据库的数据卷容量。
使用更多、更快的硬件。
(未完待续)
