'db file scattered read'
这是另一种常见的等待事件。他产生于Oracle从磁盘读取多个块到Buffer Cache中非连续("scattered")缓存的时候。这种读一次最大值是DB_FILE_MULTIBLOCK_READ_COUNT。这种典型场景像全表扫描(Full Table Scans)和全索引快速扫描(Fast Full Index
scans)。
如果这个等待事件占据大部分等待时间，下面的方法可以用到：
1. 找到执行全表扫描或全索引快速扫描的SQL语句，进行调优以确保这些扫描是必须的，而不是非最优执行计划导致的。
从Oracle 9i开始，新的V$SQL_PLAN视图可以帮上忙：(忽略在这些查询结果中的数据字典SQL)
对于全表扫描：
select sql_text from v$sqltext t, v$sql_plan p
where t.hash_value=p.hash_value and p.operation='TABLE ACCESS'
and p.options='FULL'
order by p.hash_value, t.piece;
where t.hash_value=p.hash_value and p.operation='TABLE ACCESS'
and p.options='FULL'
order by p.hash_value, t.piece;
对于全索引快速扫描：
elect sql_text from v$sqltext t, v$sql_plan p
where t.hash_value=p.hash_value and p.operation='INDEX'
and p.options='FULL SCAN'
order by p.hash_value, t.piece;
where t.hash_value=p.hash_value and p.operation='INDEX'
and p.options='FULL SCAN'
order by p.hash_value, t.piece;
在Oracle 8i，对于这种等待事件，通过查询V$SESSION_EVENT可以找到执行多块读的session，然后使用SQL Tracing跟踪这些session的SQL。另外，物理读Top前几位的SQL语句也能用来研究，判断他们的执行计划是否包含了全表扫描或全索引快速扫描。
2. 在这样最优执行计划就是多块读扫描的场景，可以通过调整多块IO的容量进行调优，需要修改实例参数DB_FILE_MULTIBLOCK_READ_COUNT，计算：DB_BLOCK_SIZE x DB_FILE_MULTIBLOCK_READ_COUNT
= 系统的max_io_size。
(可参考：
Document 30712.1 Init.ora Parameter "DB_FILE_MULTIBLOCK_READ_COUNT" Reference
Document 1037322.6 WHAT IS THE DB_FILE_MULTIBLOCK_READ_COUNT PARAMETER?)
正如之前所说的，从Oracle 10g R2开始，DB_FILE_MULTIBLOCK_READ_COUNT初始化参数现在可以自动调优，当未显示设置时可以使用一个默认值。这个默认值和可以高效执行的最大IO容量相关。参数值依赖于平台，对于大多数平台是1MB。因为参数是以块表示的，所以也可以设置为一个和可以高效执行的最大IO容量相当的值(被标准块容量切分)。
3. 因为使用全表扫描和全索引快速扫描的块会放到Buffer Cache取代链的最少最近使用端，有时使用多Buffer Pools，将这些段放到KEEP池中都会有所帮助。(可参考：Document 76374.1 Multiple Buffer Pools)
4. 使用分区能够降低作为分区剪裁扫描数据的数量，限制段分区的扫描子集。
5. 最后，可以考虑最长访问的段包含的数据数量(通过将旧的、不需要的数据移出数据库)，或将这些段移动到新的、更快的磁盘，以降低IO的响应时间。
(未完待续)