这是另一种常见的等待事件。他产生于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;
对于全索引快速扫描:
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;
在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的响应时间。
(未完待续)