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

最新推荐文章于 2021-05-25 11:32:37 发布
最新推荐文章于 2021-05-25 11:32:37 发布
阅读量161 收藏
点赞数
上次，进行过一次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 1353
直接路径读取等待事件这个事件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 342
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章　性能...
数据库性能问题排查.txt
08-10
高资源消耗sql定位：消耗CPU较多的sql:消耗磁盘较多的sql:查找产生direct path read的SQL，查询当前等待事件，主要是direct path read
oracle 11g禁用和强制direct path read
weixin_34256074的博客
08-20 389
一般在混合型环境中，大表在进行全表扫描或者走并行的时候一般会出现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来进行全表扫描，因为这可能更快，也对性能影响不大。 小表受到隐含参数：
2024年测风激光雷达行业分析报告.pptx
06-16
行业报告
mapreduce综合应用案例 - 招聘数据清洗.docx
06-16
招聘数据清洗是一个典型的大数据处理任务，可以通过MapReduce来实现高效且可扩展的数据清洗过程。下面是一个简单的招聘数据清洗的MapReduce应用案例： 输入数据准备：将招聘数据集划分为若干个块，每个块包含多条记录。 Map阶段： 每个Map任务负责处理一个数据块。 Map函数解析输入记录，提取关键字段，如职位名称、公司名称、薪资等。 对于每条记录，如果关键字段缺失或格式不正确，可以忽略或标记为错误数据。 输出中间键值对，其中键为职位名称，值为包含相关信息的自定义对象或字符串。 Reduce阶段： 所有Map任务的输出会根据职位名称进行分组。 Reduce函数对每个职位名称的数据进行处理，可以进行去重、合并、计数等操作。 根据需求，可以进一步筛选、过滤数据，如只保留特定行业或薪资范围的职位。 输出最终结果，可以保存为文件或存储到数据库中。 通过以上MapReduce应用，可以高效地清洗大规模的招聘数据，并提供结构化、准确的数据用于后续的分析和决策。此外，由于MapReduce具有良好的容错性和可扩展性，可以处理海量数据并在分布式环境中实现高性能的数据清洗任务。
Springboot+vue学生管理系统源码
06-16
Springboot+vue学生管理系统源码 idea导入后端项目，设置好依赖，运行SystemApplication.java 使用vscode或者hbuilderx等工具打开前端项目，运行即可 另外前端vue页打包成静态资源放到后端里面了，即便不运行前端vue项目也是可以的 如果需要修改，则使用npm run bulid重新打包，生成的前端代码，放到后端代码的resources的static目录下
学习数据结构和算法.zip
最新发布
06-16
大学生数据结构学习笔记和资料大全！
oracle 常见的33个等待事件
09-09
8. direct path read - 等待直接路径读取完成。 9. SQL*Net message from client - 等待来自客户端的SQL*Net消息。 10. log buffer space - 等待空闲的日志缓冲区空间。 11. control file parallel write - 等待并行...

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

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

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值