小案例分享，11G新特性引发的严重性能问题【附AWR截图】

ahdong2007

如果表的dml操作很多的话，direct path read同样会造成大量的i/o

每次读时，都需要从buffer cache刷脏数据到disk。

huanhuanlove

写错了吧  应该是 event 10949吧

ORA-10949: Disable autotune direct path read for full table scan

ysping

学习

zabll

我有点疑问，就是一看到什么DIRECT PATH之类的东西，首先想到的就是什么排序之类的东西，LZ怎么一下就定位到是由于全表读造成的?

而且200个SESSION做DIRECT PATH READ比200个SESSION做全表读坏在什么地方？

  谢谢

ahf000

zabll 发表于 2012-1-16 16:42
我有点疑问，就是一看到什么DIRECT PATH之类的东西，首先想到的就是什么排序之类的东西，LZ怎么一下就定位到 ...

11g新特性加上经验

棉花糖ONE

zabll 发表于 2012-1-16 16:42
我有点疑问，就是一看到什么DIRECT PATH之类的东西，首先想到的就是什么排序之类的东西，LZ怎么一下就定位到 ...

1.10g以后排序的等待事件是direct path read temp,或者综合变得指标都能看出来(sort disks,或者根据ash找到 sql,都能判断出是不是全表扫描引起的)
2.direct path read就不能放到buffer cache里,就导致大量物理读,而频繁访问的一些表很容易被缓存,减少大量物理读
3.direct path read也会引起object checkpoint,导致额外的磁盘写操作

AndyChan

路过。非常关注sql tuning advisor 与direct path 的影响。

maclean

在Oracle 11g版本中串行的全表扫描可能使用直接路径读取(direct path read)的方式取代之前版本中一直使用的DB FILE SCATTERED READ, 显然direct path read具备更多的优势：

1. 减少了对栓的使用，避免可能的栓争用

2.物理IO的大小不再取决于buffer_cache中所存在的块；试想某个8个块的extent中1,3,5,7号块在高速缓存中，而2,4,6,8块没有被缓存，传统的方式在读取该extent时将会是对2,4,6,8块进行4次db file sequential read,这是一种十分可怕的状况，其效率往往要比单次读取这个区间的所有8个块还要低得多，虽然Oracle为了避免这种情况总是尽可能的不缓存大表的块(读入后总是放在队列最冷的一端);而direct path read则可以完全避免这类问题，尽可能地单次读入更多的物理块。

当然直接路径读取也会引入一些缺点：

1.在直接路径读取某段前需要对该对象进行一次段级的检查点(A segment checkpoint).

2.可能导致重复的延迟块清除操作(我们假设你了解delayed block cleanout是什么).



可以利用10949 事件来避免采用直接路径读取方式

ALTER SESSION SET EVENTS '10949 TRACE NAME CONTEXT FOREVER,level 1';



From http://www.oracledatabase12g.com ... yed-block-read.html

yangtingkun

很好的案例分享

lhy12315

感谢分享