10.3.4 direct path read and direct path read temp

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 子系统是恰当的并发度。