首页 > 其他 > 详细

直接路径读取等待事件

时间:2021-03-03 23:07:52      阅读:18      评论:0      收藏:0      [点我收藏+]
直接路径读取等待事件

这个事件DPR在10G是没有的,是11G新等待事件,目的是让全表扫描和快速索引扫描不走SGA,直接从数据文件读到PGA

direct path read的优势

1、采用直接路径读取后,总能保证读取的块数是多块读参数设置的大小,提高了读取的效率

2、大大的降低了对于latch的使用,进而避免了可能导致的latch竞争(cbc latch等)

3、降低了全表扫描对buffer cache的冲击

4、降低了buffer pin的开销,有可能降低buffer busy waits等相关等待

direct path read可能的副作用

1、会发生段一级的检查点(后面详细介绍),因此在查询真正开始执行前,会做这个额外的准备工作。而且可能会造成IO抖动,因为要写脏数据。

2、如果你的表需要频繁的全表扫描读取,还是用传统的读取方式比较好。

3、在MOS中搜索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. 大表的全表扫描,

5。全索引扫描。

在实际应用情况下尤其是OLTP还有混合类型的数据库,没有做到真正的读写分离架构的传统设计模式的C/S数据库。

那些SQL语句执行频繁又大量的全表扫描,全索引扫描。由于没有SGA的缓存,每一次查询都需要从存储读取产生了大量的物理读,最终导致I/O 100%。

由于处理速度慢,CPU又产生了大量的等待队列,所以DB Time也非常高。

另外 大量的表直接路径读会导致段的检查点的触发,把脏块回写到磁盘,如果该表读写也比较频繁的话,那么LGWR写得也多了起来,同时引起控制文件写操作。

在本来繁忙的IO时间里加上日志写,简直雪上加霜了。

直接路径读取等待事件 涉及多个隐含参数和1个事件

第一个隐含参数:

  _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

这个参数类似于总开关,可惜在11.2.0.4下不生效。

第二个隐含参数:

_small_table_threshold 

单位是block, 表小于该块的数量,一定不走直接路径。

第三个隐含参数:

_very_large_object_threshold

当该表大于此倍数是,一定走直接路径。 我这里11.2.0.4 默认值是500 单位不是MB 记住不是MB

那到底是多少大小才呢? 这涉及第3个参数

第四个隐含参数:

_db_block_buffers   

意思是:Number of database blocks cached in memory: hidden parameter

我这里11.2.0.4 值是 1336660 约等于10GB 低于我的BUFFER CACHE 32GB。

公式:_very_large_object_threshold/100*_db_block_buffers

那么第三个应该是 5倍 第4个参数大小,我这里应该是50GB 就必须走直接路径读取。

第五个隐含参数:

__direct_read_decision_statistics_driven

When this parameter is FALSE, the direct path read decision is done based on the segment header’s block count (actual block count).

When TRUE (default in 11.2.0.2+), the direct path read decision is done based on the block count stored in one of the base tables (TAB$, IND$) – the optimizer statistics

意思是说 表的块值是从哪里获取,从统计信息表还是段头呢?

只所以把它拿出来说,因为很多时候统计信息和真实信息不一致,也会导致不必要的直接路径读取。

那么像我这里大于208MB 小于50GB 该怎么办呢?

这就要看另外两个条件了

第一个阀值:脏块阀值,由于direct path read需要出发一个段的检查点,因此脏块太多,刷新脏块可能会导致IO繁忙

第二个阀值:表在内存里的cache率,如果cache率很高,那么还是走传统路径更快

最后一个事件是来关闭

alter system set event= ’10949 trace name context forever, level 1′ scope=spfile;

重启数据库

也可在会话中

alter session set events ‘10949 trace name context forever, level 1‘;

不过这个事件依旧不是强有效果的。它尽量地关闭介于208MB到50GB的表不走直接路径。

这个超级性能BUG 在12.1.0.2 引入自动大表缓存,将BUFFER CACHE 划出部分为大表缓存区

并且统计表和索引的热度,将其放到CACHE 避免频繁DIRECT PATH READ。

ALTER DATABASE NO FORCE FULL DATABASE CACHING;

alter system set db_big_table_cache_percent_target = 90;

视图:

V$Bt_scan_cache;v$Bt_scan_obj_temps

对于使用很广的11.2.0.4朋友来说该怎么办呢?

方法一:关闭它

alter system set event= ’10949 trace name context forever, level 1′ scope=spfile;

alter system set "_serial_direct_read"=false scope=spfile;

方法二:调高下限

alter system set "_small_table_threshold"=262144 scope=spfile; 约2G

方法三:避免统计信息错误

alter system set "__direct_read_decision_statistics_driven"=FALSE scope=spfile;

方法四: KEEP CACHE

ALTER TABLE T STORAGE (BUFFER_POOL KEEP)

我们人工的把一些大表KEEP进BUFFER CACHE,这样类似于12C的大表缓存特效了

alter system set db_keep_cache_size=2G scope=spfile;

KEEP池其实是一块可用内存采用类似循环的算法进行访问。

如果KEEP池里面还有剩余空间,则新的数据会首先使用剩余的空间,如果KEEP池已经存储满了,Oracle会从头开始重用KEEP池。

方法五 对全表尽可能建索引。

建索引比优化SQL来的快!

直接路径读取等待事件

原文:https://blog.51cto.com/15080028/2645886

(0)
(0)
   
举报
评论 一句话评论(0
© 2014 bubuko.com 版权所有 鲁ICP备09046678号-4
打开技术之扣,分享程序人生!
             

鲁公网安备 37021202000002号