与数据文件IO相关的等待事件：
接下来的等待事件是与数据文件的IO操作时产生的。
'db file sequential read'
这是一种最常见的IO相关的等待。大多数情况下，他指的是单块读，例如索引数据块或通过索引访问的表数据块，也能在读取数据文件头块时看到这种等待事件。在更早的版本中，这种等待事件也会产生于从磁盘的排序段通过多快读的方式读入Buffer Cache的连续("sequential")缓冲。
如果这种等待事件占据了大部分的等待时间，可以尝试以下的若干方法：
1. 找到物理读Top前几位的SQL语句(从Statspack或AWR报告的“SQL ordered by Reads”节或V$SQL视图)，进行调优以减少IO请求：
(1) 如果使用了索引范围扫描(Index Range scans)，且索引选择性较差，那么就需要访问比正常情况更多的块。通过强制使用选择性更好的索引，访问同一张表可以读取更少的索引块(花费更少的物理IO)。
(2) 如果索引出现碎片化，可能仍旧会访问更多的块，因为单块包含的索引数据更少。
(3) 如果索引的Clustering Factor非常大，需要访问更多的表数据块，才能在每个索引块上得到行数据。通过重建表，根据特定的索引列对行进行排序，能够降低Clustering Factor，以及每个索引块需要访问的表数据块数量。例如，如果表包含A，B，C和D列，索引是B，D，那么重建表为：CREATE TABLE new AS SELECT * FROM old ORDER BY b,d;
(4) 使用分区以减少每个使用分区剪裁的SQL语句需要访问的索引和表数据块的数量。
2. 如果没有特殊的SQL语句使用了较差的执行计划，但仍旧产生了比正常更多的物理IO，以下情况可能发生：
(1) 特殊的数据文件IO可能处理非常缓慢，原因可能是磁盘的过度访问。这种情况下，查看Statspack的"File I/O Statistics"节(或V$FILESTAT)可以帮我们找到这样的热磁盘，通过手工移动这些数据文件到其它的存储以分散IO，或者充分利用条带化，RAID和其它的技术，自动执行IO负载均衡。
(2) 从Oracle 9.2开始，通过使用来自V$SEGMENT_STATISTICS视图的段统计信息，我们也能找到哪些段(表或索引)存在最多的物理读。然后我们能详细研究下这些段的细节，例如索引是否需要重建或者是否需要使用分区来降低IO。Statspack也可以在level 7级别上产生“段统计信息”的报告。
3. 如果没有SQL使用较差的执行计划，IO也平均地分不到所有磁盘，但响应时间仍旧较长，那么一个大的Buffer Cache缓冲可能有帮助：
在Oracle 8i，用逐渐增长的DB_BLOCK_BUFFERS做个实验。
通过从Statspack中衡量Buffer Cache Hit Ratio，直到没有任何提高为止。
(1) 在Oracle 9i之前的版本，可以使用Buffer Cache Advisory工具(从Statspack报告中可以得到)来调整Buffer Cache的容量。
(2) Oracle 10g之前的版本，ASMM(Automatic Shared Memory Management)能够用来让数据库根据当前负载，自动判断Buffer Cache的最佳容量。(可参考：Document 257643.1 Oracle Database 10g Automated SGA Memory Tuning)
(3) 对于热段，多Buffer Pools的使用可以帮助解决问题，可以将这样的“热”索引和表放到KEEP缓冲池。(可参考：Document 76374.1 Multiple Buffer Pools)
4. 最后，还可以考虑降低经常访问的段中包含的数据量(例如将旧的、不需要的数据移出数据库)，或将这些段移动到更快的磁盘中，以降低其IO所需要的响应时间。
(未完待续)