11g direct path read 等待事件的实验分析

最新推荐文章于 2021-05-25 11:32:37 发布
最新推荐文章于 2021-05-25 11:32:37 发布
阅读量162 收藏
点赞数
上次，进行过一次11g direct path read等待事件的初步探讨，现在，就以我的一次实验来完善这个等待事件的研究：

Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE 查看隐含参数 _small_table_threshold

SELECT A.KSPPINM PARAMETER, A.KSPPDESC DESCRIPTION, B.KSPPSTVL SESSION_VALUE,

C.KSPPSTVL INSTANCE_VALUE

FROM X$KSPPI A, X$KSPPCV B, X$KSPPSV C

WHERE A.INDX = B.INDX AND A.INDX = C.INDX AND

--SUBSTR(A.KSPPINM, 1, 1) = '_' and

a.KSPPINM ='_small_table_threshold'

ORDER BY A.KSPPINM ;

小表的定义值为734个block大小。

PARAMETER         DESCRIPTION                                      SESSION_VALUE   INST

------------------------------ ------------------------------------------------------------ --------------- ----

_small_table_threshold   lower threshold level of table size for direct reads     734               734

 

当表的规模大于5倍小表阀值时候

SQL> create table TT(c1 number, c2 char(2000), c3 char(2000), c4 char(2000));

SQL> insert into TT

  2  select level, 'x', 'x', 'x'

  3  from dual connect by level <= 10 + 5*&sth;

Enter value for sth: 734

old   3: from dual connect by level <= 10 + 5*&sth

new   3: from dual connect by level <= 10 + 5*734

 

3680 rows created.

 

SQL>  select bytes/1024/1024 MB ,SEGMENT_TYPE from dba_segments where segment_name='TT' and wner='SYS';

 

        MB SEGMENT_TYPE

---------- ------------------------------------------------------

        29 TABLE

 

SQL> alter system flush buffer_cache;

alter session set events '10046 trace name context forever, level 8';

select count(*) from TT;

 

可以看到跟踪事件中，以直接路径读进行全表扫描

WAIT #7: nam='db file sequential read' ela= 32539 file#=1 block#=33064 blocks=1 obj#=14517 tim=18808750986

WAIT #7: nam='direct path read' ela= 15931 file number=1 first dba=33065 block cnt=127 obj#=14517 tim=18808769895

WAIT #7: nam='direct path read' ela= 24746 file number=1 first dba=247040 block cnt=128 obj#=14517 tim=18808795968

WAIT #7: nam='direct path read' ela= 17911 file number=1 first dba=247168 block cnt=128 obj#=14517 tim=18808815059

…

而执行

alter system flush buffer_cache;

alter session set events '10046 trace name context forever, level 8';

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

select count(*) from TT;

见到的就是另一番景象，数据库采用离散读来进行全表扫描。

WAIT #7: nam='SQL*Net message to client' ela= 7 driver id=1111838976 #bytes=1 p3=0 obj#=14517 tim=18746048764

WAIT #7: nam='db file scattered read' ela= 832 file#=1 block#=33065 blocks=7 obj#=14517 tim=18746049844

WAIT #7: nam='db file scattered read' ela= 712 file#=1 block#=33072 blocks=8 obj#=14517 tim=18746051116

WAIT #7: nam='db file scattered read' ela= 577 file#=1 block#=33080 blocks=6 obj#=14517 tim=18746052075

WAIT #7: nam='db file sequential read' ela= 289 file#=1 block#=33087 blocks=1 obj#=14517 tim=18746052647

…

现在开始验证表大小与_very_large_object_threshold的比较，对10949事件的影响。

 

查看隐含参数_very_large_object_threshold，这里的单位为MB

SELECT A.KSPPINM PARAMETER, A.KSPPDESC DESCRIPTION, B.KSPPSTVL SESSION_VALUE,

C.KSPPSTVL INSTANCE_VALUE

FROM X$KSPPI A, X$KSPPCV B, X$KSPPSV C

WHERE A.INDX = B.INDX AND A.INDX = C.INDX AND

--SUBSTR(A.KSPPINM, 1, 1) = '_' and

a.KSPPINM =' _very_large_object_threshold'

ORDER BY A.KSPPINM ;

 

PARAMETER

--------------------------------------------------------------------------------

DESCRIPTION

--------------------------------------------------------------------------------

SESSION_VALUE

--------------------------------------------------------------------------------

INSTANCE_VALUE

--------------------------------------------------------------------------------

_very_large_object_threshold

upper threshold level of object size for direct reads

500

500

 

理论上表的大小小于500M还是会自动使用直接路径读，10949事件也可以禁止直接路径读。因此直接增加表的size到超过500MB：

SQL> insert into TT

  2  select level, 'x', 'x', 'x'

  3  from dual connect by level <= 10 + 5*&sth;

Enter value for sth: 10000

old   3: from dual connect by level <= 10 + 5*&sth

new   3: from dual connect by level <= 10 + 5*10000

 

50010 rows created.

 

SQL> select bytes/1024/1024 MB ,SEGMENT_TYPE from dba_segments where segment_name='TT' and wner='SYS'

        MB SEGMENT_TYPE

---------- ------------------------------------------------------

       856 TABLE

 

此时验证10949事件能否阻止直接路径读：

SQL> alter system flush buffer_cache;

SQL> alter session set events '10949 trace name context forever, level 1';

 

SQL> select count(*) from TT;                                       10:21执行

 

  COUNT(*)

----------

109115

 

*** 2011-07-08 10:21:02.115

WAIT #2: nam='SQL*Net message from client' ela= 40831353 driver id=1111838976 #bytes=1 p3=0 obj#=14509 tim=9243629861

CLOSE #2:c=0,e=15,dep=0,type=1,tim=9243630106

=====================

PARSING IN CURSOR #1 len=23 dep=0 uid=0 ct=3 lid=0 tim=9243630258 hv=3499053100 ad='27ef3938' sqlid='9330tqb88yn1c'

select count(*) from TT

END OF STMT

PARSE #1:c=0,e=50,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=3133740314,tim=9243630254

EXEC #1:c=0,e=136,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=3133740314,tim=9243630577

WAIT #1: nam='SQL*Net message to client' ela= 6 driver id=1111838976 #bytes=1 p3=0 obj#=14509 tim=9243630667

WAIT #1: nam='db file scattered read' ela= 32813 file#=1 block#=33225 blocks=7 obj#=14509 tim=9243663820

WAIT #1: nam='db file scattered read' ela= 854 file#=1 block#=33232 blocks=8 obj#=14509 tim=9243665083

WAIT #1: nam='db file scattered read' ela= 692 file#=1 block#=33240 blocks=8 obj#=14509 tim=9243666078

…

显然并没有令10949事件失效。

 

现在看表的大小超过5倍buffer cache的试验：

算出5倍buffer大小为1480M。

增加表size

SQL> select bytes/1024/1024 MB ,SEGMENT_TYPE from dba_segments where segment_name='TT' and wner='SYS';

 

        MB SEGMENT_TYPE

---------- ------------------------------------------------------

      1670 TABLE

 

SQL> alter system flush buffer_cache;

SQL> alter session set events '10949 trace name context off';

SQL> select count(*) from TT;                                 10:26

  COUNT(*)

----------

209125

 

SQL> alter system flush buffer_cache;

SQL> alter session set events '10949 trace name context forever, level 1';

SQL> select count(*) from TT;                                   10:31

  COUNT(*)

----------

    209125

 

*** 2011-07-08 10:31:02.503

WAIT #2: nam='SQL*Net message from client' ela= 68444968 driver id=1111838976 #bytes=1 p3=0 obj#=14509 tim=9844017130

CLOSE #2:c=0,e=15,dep=0,type=3,tim=9844017436

=====================

PARSING IN CURSOR #1 len=23 dep=0 uid=0 ct=3 lid=0 tim=9844017611 hv=3499053100 ad='27ef3938' sqlid='9330tqb88yn1c'

select count(*) from TT

END OF STMT

PARSE #1:c=0,e=58,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=3133740314,tim=9844017607

EXEC #1:c=0,e=130,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=3133740314,tim=9844017928

WAIT #1: nam='SQL*Net message to client' ela= 8 driver id=1111838976 #bytes=1 p3=0 obj#=14509 tim=9844018021

WAIT #1: nam='db file sequential read' ela= 30665 file#=1 block#=33224 blocks=1 obj#=14509 tim=9844048839

WAIT #1: nam='direct path read' ela= 50296 file number=1 first dba=33225 block cnt=55 obj#=14509 tim=9844100911

WAIT #1: nam='direct path read' ela= 29366 file number=1 first dba=92672 block cnt=128 obj#=14509 tim=9844132883

。。。

 

无论10949事件有没有开启；天王老子都不能阻止全表扫描采用直接路径读的方式了。

 

看来 10949 事件还是有其局限性，但是话说回来，对一个如此大的表采用直接路径读，也是无奈的办法，而对这么个大表，最根本的还是建立索引，不走全表扫描还是主要的方法。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/24582392/viewspace-705133/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/24582392/viewspace-705133/

ctcml02642
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
oracle关闭直接路径读,Oracle 直接路径读取等待事件
weixin_28366353的博客
04-03 1357
直接路径读取等待事件这个事件DPR在10G是没有的，是11G新等待事件，目的是让全表扫描和快速索引扫描不走SGA，直接从数据文件读到PGAdirect path read的优势1、采用直接路径读取后，总能保证读取的块数是多块读参数设置的大小，提高了读取的效率2、大大的降低了对于latch的使用，进而避免了可能导致的latch竞争(cbc latch等)3、降低了全表扫描对buffer cache的...
【故障处理】队列等待之TX 等待事件处理.docx
07-09
队列等待之TX - allocate ITL entry引起的死锁处理 Buffer busy waits异常等待事件分析与处理。 Buffer latch异常等待事件分析与处理。 Db file parallel read异常等待事件...Direct path read异常等待事件分析与处理。
一份11gR2 rac awr报告的简单分析
数据库天地
08-24 435
昨晚网友发来一份awr报告，希望帮忙分析一下。由于其他信息都没有，仅仅只有一份awr，鉴于目前有大多的朋友还不太熟悉或者说不知道如何去进行awr的分析。我这里就拿这个awr来进行分析，当抛砖引玉了。首先申请，网上分析awr的文章不少，大家也都可以参考一下。 首先来看awr前面部分信息，了解下系统的版本，以及大概判断下系统负载如何。 从上面信息我们可以得出如下结论： —-数据库是一...
Oracle direct path read相关隐含参数
开源世界
05-25 344
In 10g, serial table scans for “large” tables go through the buffer cache (by default). Oracle 10G，默认时，即使对表全表扫描也会先缓存到buffer cache中，parallel方式除外 In 11g or higher, there has a been a change in the rules that choose between using ‘direct path reads’ and reads
oracle set path,Oracle 11g全表扫描以Direct Path Read方式执行
weixin_32005771的博客
04-02 232
Oracle 11g全表扫描以Direct Path Read方式执行在Oracle Database 11g中有一个新特性，全表扫描可以通过直接路径读的方式来执行(Direct Path Read)，这是一个合理的变化，如果全表扫描的大量数据读取是偶发性的，则直接路径读可以避免大量数据对于Buffer Cache的冲击。当然对于小表来说，Oracle允许通过Buffer Cache来进行全表扫描...
Oracle 11g全表扫描以Direct Path Read方式执行
haiross的专栏
08-12 598
在Oracle Database 11g中有一个新特性，全表扫描可以通过直接路径读的方式来执行（Direct Path Read），这是一个合理的变化，如果全表扫描的大量数据读取是偶发性的，则直接路径读可以避免大量数据对于Buffer Cache的冲击。 当然对于小表来说，Oracle允许通过Buffer Cache来进行全表扫描，因为这可能更快，也对性能影响不大。 小表受到隐含参数：_s
pkg-cache(v2.6).zip
05-07
node10-win-x64> Fetching base Node.js binaries to PKG_CACHE_PATH fetched-v10.17.0-win-x64 [ ] 0%> Error! getaddrinfo ENOENT github-production-release-asset-2e65be.s3.amazonaws....
数据库性能监控
10-28
#Core session logical reads ...direct path read direct path write #Network Traffic bytes sent via SQL*Net to client bytes received via SQL*Net from client SQL*Net roundtrips to/from client
深入解析Oracle.DBA入门进阶与诊断案例
10-13
9.5.3　direct path read/write(直接路径读/写)　444 9.5.4　日志文件相关等待　453 9.5.5　Enqueue(队列等待)　458 9.5.6　Latch Free(闩锁释放)　462 9.5.7　Oracle 10g/11g Latch机制的变化　467 第10章　性能...
oracle数据泵使用详解
01-24
- **数据库升级**：在Oracle数据库升级时，如从10G升级到11G，可使用数据泵进行数据迁移。 - **数据同步**：对于前置库和其他数据库的数据同步，尤其是大量一次性导入的数据，数据泵是理想选择。 - **表结构修改*...
oracle 11g禁用和强制direct path read
weixin_34256074的博客
08-20 393
一般在混合型环境中，大表在进行全表扫描或者走并行的时候一般会出现direct path read等待事件，如果在OLTP或者纯粹的DSS环境中，出现大量的direct path read直接路径读取，这样就有问题了，尤其是一些流水线的批处理系统中，会导致大量的free buffer wait等（因为direct path reads会导致oracle执行object level checkpoin...
Oracle 数据库禁止全表访问的时候direct path read
okhymok的博客
12-08 722
一般在OLAP环境中，大表在进行全表扫描的时候一般会出现direct path read等待事件，如果在OLTP环境中，出现大量的direct path read直接路径读取，这样就有问题了。一般在OLTP中，都是事物型的sql，如果想sql执行效率，那么最好从内存当中读取数据，直接从数据文件中读取，后果可想而知了。这里就可能需要我们禁用direct path read。 第一种方法：使用1
ORALE11g Direct Path Read可能影响性能
DRAGON
01-16 409
在Oracle Database 11g中有一个新特性，全表扫描可以通过直接路径读的方式来执行（Direct Path Read），这是一个合理的变化，如果全表扫描的大量数据读取是偶发性的，则直接路径读可以避免大量数据对于Buffer Cache的冲击。 当然对于小表来说，Oracle允许通过Buffer Cache来进行全表扫描，因为这可能更快，也对性能影响不大。 小表受到隐含参数：
02 井道机械设备安装质量管理.doc
06-26
02 井道机械设备安装质量管理.doc
【流程管理】公司流程管理手册（49页）.doc
最新发布
06-26
【流程管理】公司流程管理手册（49页）.doc
CV入门教程，附源代码.pdf
06-26
计算机视觉（Computer Vision, CV）是人工智能领域的一个重要分支，它研究如何使计算机从数字图像或视频中提取、分析和理解信息。本教程将带您走进计算机视觉的世界，从基础概念到实际应用，逐步深入。 二、基础概念 图像与视频：图像是静态的视觉信息，而视频是连续的图像序列。 像素：图像的基本单元，由红、绿、蓝（RGB）三种颜色分量组成。 灰度图像：只有亮度信息，没有颜色信息的图像。 特征：图像中用于描述和区分不同物体的信息，如边缘、角点、纹理等。
麦肯锡-TCL股份有限公司管理整合咨询-组织设计方案（146页 PPT）.ppt
06-26
麦肯锡-TCL股份有限公司管理整合咨询-组织设计方案（146页 PPT）.ppt
oracle 常见的33个等待事件
09-09
Oracle数据库中的等待事件是指在数据库运行时，由于某些资源的限制，导致进程需要等待的事件。以下是常见的33个Oracle等待事件： 1. latch free - 等待获取latch资源的进程。 2. CPU time - 等待CPU处理时间。 3. log file sync - 等待日志文件同步完成。 4. buffer busy waits - 等待访问繁忙的数据缓冲区。 5. db file sequential read - 等待从磁盘读取数据文件的读取操作完成。 6. db file scattered read - 等待从磁盘读取散乱的数据块的读取操作完成。 7. log file parallel write - 等待并行写入日志文件的操作完成。 8. direct path read - 等待直接路径读取完成。 9. SQL*Net message from client - 等待来自客户端的SQL*Net消息。 10. log buffer space - 等待空闲的日志缓冲区空间。 11. control file parallel write - 等待并行写入控制文件的操作完成。 12. db file parallel write - 等待并行写入数据文件的操作完成。 13. enqueue - 等待获取enqueue资源的操作完成。 14. db file async I/O submit - 等待异步I/O提交的操作完成。 15. db file async I/O complete - 等待异步I/O完成的操作。 16. direct path write - 等待直接路径写入操作完成。 17. SQL*Net more data to client - 等待传输更多SQL*Net数据给客户端。 18. redo log space requests - 等待空闲的重做日志空间。 19. buffer deadlock - 等待缓冲区死锁解除。 20. db file checkpoint completion - 等待数据文件检查点完成。 21. db file parallel read - 等待并行读取数据文件的操作。 22. latch: cache buffers chains - 等待获取缓冲区链锁的进程。 23. read by other session - 等待其他会话读取数据。 24. control file sequential read - 等待从控制文件读取数据。 25. ASM background process - 等待ASM后台进程操作完成。 26. latch: In-Memory undo latch - 等待获取In-Memory undo latch锁的进程。 27. cell single block physical read - 等待从Cell服务器读取单个块的物理读取操作完成。 28. library cache: mutex X - 等待获取库缓存互斥锁的进程。 29. PX Deq: Table Q Normal - 等待并行执行查询操作。 30. direct path read temp - 等待从临时文件读取数据的直接路径读取操作完成。 31. PX Deq Execution Msg - 等待并行执行消息处理。 32. PX Deq Credit: send blkd - 等待并行执行接收处理。 33. PX Deq: reap credit - 等待并行执行回收资源的操作完成。 以上是常见的33个Oracle等待事件，了解这些事件对于排查和优化数据库性能非常重要。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值