oracle 11G direct path read 很美也很伤人

direct path read

在11g中,全表扫描可能使用direct path read方式,绕过buffer cache,这样的全表扫描就是物理读了。

在10g中,都是通过gc buffer来读的,所以不存在direct path read的问题。

  direct path read较高的可能原因有:

  1. 大量的磁盘排序操作,order by, group by, union, distinct, rollup, 无法在PGA中完成排序,需要利用temp表空间进行排序。 当从临时表空间中读取排序结果时,会产生direct path read.

  2. 大量的Hash Join操作,利用temp表空间保存hash区。

  3. SQL语句的并行处理

  4. 大表的全表扫描,在中,全表扫描的算法有新的变化,根据表的大小、高速缓存的大小等信息,决定是否绕过SGA直接从磁盘读Oracle11g取数据。而10g则是全部通过高速缓存读取数据,称为table scan(large)。11g认为大表全表时使用直接路径读,可能比10g中的数据文件散列读(db file scattered reads)速度更快,使用的latch也更少。

  大量的direct path read等待时间最可能是一个应用程序问题。 direct path read事件由SQL语句驱动,这些SQL语句执行来自临时的或常规的表空间的直接读取操作。 当输入的内容大于PGA中的工作区域时,带有需要排序的函数的SQL语句将排序结果写入到临时表空间中,临时表空间中的排序顺序串随后被合并,用于提供最终的结果。读取排序结果时,Oracle会话在direct path read等待事件上等待。DB_FILE_DIRECT_IO_COUNT初始化参数可能影响direct path read的性能。

  一个隐含参数:

  _serial_direct_read = false 禁用direct path read

  _serial_direct_read = true 启用direct path read

  alter sytem set "_serial_direct_read"=never scope=both sid=‘*‘; 可以显着减少direct path read


看起来很美 当是它带来另外个等待事件,那就是要把缓存中的脏数据刷回数据文件中。激发check point 事件,DBWR写的任务很频繁。

大量的读IO导致IO缓慢,缓慢的IO又让DBWR写得更慢,同时check point事件会阻塞 DML。 在OLTP方面是很严重的事故。

因为应用程序存在大量的全表查询的语句。

oracle 11G direct path read 很美也很伤人,古老的榕树,5-wow.com

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。