10.3.4 direct path read and direct path read temp
当一个会话是从磁盘读buffer 直接到PGA(相对于buffer cache 在SGA), 它在这个事件上
如果I/O 子系统不支持异步I/Os, 那么每个等待对应物理读请求。
如果 I/O 子系统支持异步I/O, 然后处理是可以 重叠执行度请求和处理blocks 在PGA里。
当处理尝试访问一个block 在PGA ,block 没有从磁盘读取。
它然后执行一个等待请求 和更新统计信息对于这个事件。
因此,等待的次数是和读请求的次数是不相同的
检查 v$session_wait 参数列:
p1:File_id 对于读的请求
p2: 开始block_id 对于读请求
p3: 读的块数
10.3.4.1 原因
这种情况发生在下面的情况:
1. 排序是太大的 来放入到内存, 一些排序的数据是直接写出到磁盘。
这个数据是随后被读回,使用直接读
2.并行slaves 是用于扫描数据
3.server 进程是处理buffer 快于系统可以返回的buffers, 这个表明一个过载的I/O系统
10.3.4.2 Actions：
file_id 显示如果 读是对于一个对象 在TEMP 表空间(在磁盘上排序) 或者全表扫描通过并发slaves.
这个等待是最大的等待对于大的数据仓库。 然而,如果负载不是一个设计支持系统负载的,然后检查为什么这个状态是发生的
10.3.4.2.1 磁盘排序
检验 SQL语句当前通过session 经历等待来看 什么导致了排序。
查询V$TEMPSEG_USAGE 来找到SQL语句 在进行排序。
也从v$sesstat 查询统计信息对于session来决定排序的大小。
查看如果它是可能降低排序通过优化SQL语句。
如果WORKAREA_SIZE_POLICY设置为手动,然后考虑增加 SORT_AREA_SIZE 对于系统(如果排序不是太大的)
或者 对于单个进程。
10.3.4.2.2 Full Table Scans:
如果表是定义一个高度的并行读, 然后设置可以倾斜的让优化器使用全表扫描。
检查 object 被读取使用直接路径读取。
如果 全表扫描是一个正确的工作部分,然后确认I/O 子系统是恰当的并发度。