何时会发生db file sequential read等待事件?
很多网友对系统内频繁发生的db file sequential read等待事件存有疑问,那么到底在那些场景中会触发该单块读等待事件呢?
在我之前写的一篇博文<SQL调优:Clustering Factor影响数据删除速度一例>中总结了db file sequential read等待事件可能发生的场景,在这里再share以下:
”db file sequential read”单块读等待是一种最为常见的物理IO等待事件,这里的sequential指的是将数据块读入到相连的内存空间中(contiguous memory space),而不是指所读取的数据块是连续的。该wait event可能在以下情景中发生:
- 最为常见的是执行计划中包含了INDEX FULL SCAN/UNIQUE SCAN,此时出现”db file sequential read”等待是预料之中的,一般不需要我们去特别关注
- 当执行计划包含了INDEX RANGE SCAN-(“TABLE ACCESS BY INDEX ROWID”/”DELETE”/”UPDATE”), 服务进程将按照”访问索引->找到rowid->访问rowid指定的表数据块并执行必要的操作”顺序访问index和table,每次物理 读取都会进入”db file sequential read”等待,且每次读取的都是一个数据块;这种情况下clustering_factor将发挥其作用,需要我们特别去关注,本例中提及的解决方法对 这种情景也有效
- Extent boundary,假设一个Extent区间中有33个数据块,而一次”db file scattered read”多块读所读取的块数为8,那么在读取这个区间时经过4次多块读取后,还剩下一个数据块,但是请记住多块读scattered read是不能跨越一个区间的(span an extent),此时就会单块读取并出现”db file sequential read”。这是一种正常现象,一般不需要额外关注
- 假设某个区间内有8个数据块,它们可以是块a,b,c,d,e,f,g,h,恰好当前系统中除了d块外的其他数据块都已经被缓存在buffer cache中了,而这时候恰好要访问这个区间中的数据,那么此时就会单块读取d这个数据块,并出现”db file sequential read”等待。注意这种情况不仅于表,也可能发生在索引上。这是一种正常现象,一般不需要额外关注
- chained/migrated rows即链式或迁移行,这里我们不介绍链式行的形成原因,chained/migrated rows会造成服务进程在fetch一行记录时需要额外地单块读取,从而出现”db file sequential read”。这种现象需要我们特别去关注,因为大量的链式/迁移行将导致如FULL SCAN等操作极度恶化(以往的经验是一张本来全表扫描只需要30分钟的表,在出现大量链式行后,全表扫描需要数个小时),同时也会对其他操作造成不那么 明显的性能影响。可以通过监控v$sysstat视图中的”table fetch continued row”操作统计来了解系统中链式/迁移行访问的情况,还可以通过DBA_TBALES视图中的CHAIN_CNT来了解表上的链式/迁移行情况,当然这 要求定期收集表上的统计信息;如果没有定期收集的习惯,那么可以配合@?/rdbms/admin/utlchain脚本和analyze table list chained rows 命令来获取必要的链式行信息
- 创建Index entry,显然当对表上执行INSERT操作插入数据时,虽然在执行计划中你看不到过多的细节,但实际上我们需要利用索引来快速验证表上的某些约束是否 合理,还需要在索引的叶子块中插入相关的记录,此时也可能出现”db file sequential read”等待事件,当然这还和具体的插入的方式有关系。这是一种正常现象,一般不需要额外关注
- 针对表上的UPDATE/DELETE,不同于之前提到的”INDEX RANGE SCAN-UPDATE/DELETE”,如果我们使用rowid去更新或删除数据时,服务进程会先访问rowid指向的表块(注意是先访问table block)上的行数据,之后会根据该行上的具体数据去访问索引叶子块(注意Oracle并不知道这些leaf block在哪里,所以这里同样要如range-scan/unique-scan那样去访问index branch block),这些访问都将会是单块读取,并会出现’db file sequential read’,完成必要的读取后才会执行更新或删除的实际EXEC操作,如下例:
以下trace中,obj#=1307547为sample表,而obj#=1307549为sample表上的唯一一个索引 PARSING IN CURSOR #10 len=58 dep=0 uid=64 oct=6 lid=64 tim=1275805024007795 hv=505118268 ad='d387e470'
update sample set t2=t2+1 where rowid='AAE/OzAAEAAANUEAAQ'
END OF STMT
PARSE #10:c=1999,e=3016,p=1,cr=1,cu=0,mis=1,r=0,dep=0,og=1,tim=1275805024007787
WAIT #10: nam='db file sequential read' ela= 314 file#=4 block#=54532 blocks=1 obj#=1307547 tim=1275805024008308
WAIT #10: nam='db file sequential read' ela= 206 file#=6 block#=20 blocks=1 obj#=1307549 tim=1275805024009235
WAIT #10: nam='db file sequential read' ela= 206 file#=6 block#=742 blocks=1 obj#=1307549 tim=1275805024009496
WAIT #10: nam='db file sequential read' ela= 207 file#=6 block#=24 blocks=1 obj#=1307549 tim=1275805024009750
EXEC #10:c=2000,e=2297,p=6,cr=2,cu=8,mis=0,r=1,dep=0,og=1,tim=1275805024010210 --实际的UPDATE发生在这里
当大量执行这类UPDATE/DELETE操作时将需要频繁地交叉访问表和索引,如果恰好表上的某个索引有较高的 clustering_factor的话,那么就会形成本例中的这种性能问题了。实际上当表上有较多索引时,使用rowid来批量 update/delete数据这种方式是不被推荐的,仅当表上没有索引时才可能十分高效。如果你坚持要这样做,那么可以参照上面提到的建议。
8.BUG!BUG!已知在9i RAC及10g中使用ASM的情况下,存在引发在适用情况下不使用”scattered read”多块读而去使用”sequential read”的BUG。如果你的问题和上述情景都不匹配,但又有大量的”db file sequential read”等待事件,那么你有可能遇到bug了。在这里列出部分已知bug:
Bug# | Version Affected |
Bug 7243560 – High “db file sequential read” IO times when using ASM | 10.2.0.4/11.1.0.7 |
Bug 7243560: RAPID INCREASE IN DB FILE SEQUENTIAL READ AFTER MOVING TO ASM | 10.2.0.3 |
Bug 9711810: EXCESSIVE DB FILE SEQUENTIAL READS WITH NON COMPLIANT BUFFER CACHE ON RAC | 9.2.0.8 |
Bug 9276739: INSERT STATEMENT HAS SLOW PERFORMANCE WITH DB FILE SEQUENTIAL READ | 10.2.0.4 |
Bug 8625100: EXCESSIVE DB FILE SEQUENTIAL READ ON UNDO | 10.2.0.4 |
Bug 8669544: HIGH DB FILE SEQUENTIAL READ AND GC CR DISK READ WAIT EVENTS DURING FULL SCAN | 10.2.0.4 |
Bug 7427133: AN INSERT CAUSES LOTS OF ‘DB FILE SEQUENTIAL READ’ WAITS FOR THE INDEX BLOCKS | 9.2.0.8 |
Bug 8493139: INCREASE IN DB FILE SEQUENTIAL READ WAITEVENT AFTER MIGRATING TO 10 RAC/ASM | 10.2.0.4 |
Bug 5882268: PERFORMANCE ISSUE WITH ‘DB FILE SEQUENTIAL READ’ | 10.2.0.2 |
Bug 7415702: LOTS OF ‘DB FILE SEQUENTIAL READ’ ON UNDO | 10.2.0.3 |
Bug 5607724: 10202 DB FILE SEQUENTIAL READ THRICE AFTER UPGRADE FROM 9I |
http://www.oracledatabase12g.com/archives/db-file-sequential-read-wait-event.html
何时会发生db file sequential read等待事件?的更多相关文章
- oracle之 db file sequential read等待事件优化思想
为什么db file sequential read事件在full table scan操作中显现,为什么在多块读中为什么会有单块读存在 ? extent的大小 :当扩展区中的最后一组块仅是1个块,o ...
- db file sequential read等待事件 --转载
db file sequential read db file sequential read等待事件有3个参数:file#,first block#,和block数量.在10g中,这等待事件受到用户 ...
- db file sequential read等待事件的一点研究
db file sequential read等待事件有3个参数:file#,first block#,和block数量. 这个等待事件有3个参数P1,P2,P3, 其中P1代表Oracle要读取的文 ...
- db file scattered read 等待事件
db file scattered read 等待事件: 我们经常会见到db file scattered read 等待事件,在生产环境中,这个等待事件可能更为常见.这个事件表明用户进程正在读数据 ...
- [20180316]理解db file parallel read等待事件.txt
[20180316]理解db file parallel read等待事件.txt --//一直对db file parallel read等待事件不理解,因为在实际系统中很少遇到这样的等待事件. S ...
- control file sequential read 等待事件
可能的原因 control file sequential read Reading from the control file. This happens in many cases. For ex ...
- Oracle 等待事件 db file sequential read
db file sequential read-数据文件顺序读取 等待事件: "db file sequential read" Reference Note (文档 ID 345 ...
- 全表扫描引发的db file sequential read
今天我要做一个SQL调优,监控该SQL, 利用ASH 监控 该SQL是在sid=4848 上面跑的 db file sequential read等待事件有3个参数:file#,first block ...
- 记一次insert因为db file sequential read影响性能导致性能原因的分析
通过详细的10046 trace发现,大量的io等待分布在以下数据文件上:Misses in library cache during parse: 0Elapsed times include wa ...
随机推荐
- Linux操作系统中的文件目录结构详细介绍
"/" :Linux文件系统的入口.也是最高一级的目录. "/bin":基本系统所需要的命令,功能和"/usr/bin"类似,这个目录下的文 ...
- Http请求get和post调用
工作中会遇到远程调用接口,需要编写Http请求的共通类 以下是自己总结的Http请求代码 package com.gomecar.index.common.utils; import org.apac ...
- brew: Nginx https config
下载安装Brew: /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/mas ...
- Java基础学习-extends继承(成员变量,局部变量,成员方法)
package extend; /*面向对象-继承: * 多个类的共同成员变量和成员方法.抽取到另一个类中(父类),我们多个类就可以访问到父类的成员了 * */ class Game{ String ...
- 向重复劳动说不!——GMExplorer 1.0 Beta 发布
下载: GMExplorer 1.0 Beta 计算机网络诞生以来,各项技术日新月异.在浏览器器能做和看到的,早已不止网页了! 特别是近几年HTML5.云服务等技术的兴起,涌向大批优秀的Web应用.人 ...
- 毕业生、程序猿转岗该如何选择Java、大数据和VR?
许久不见的朋友请我吃饭,期间给我介绍他一个弟弟,说明年要毕业了,还不知道找啥工作,说有培训机构让他学VR.大数据什么的,不知道前景咋样,想咨询一下我.相信很多朋友面临毕业,都不知道该从事哪个行业,自己 ...
- (三十八)js之柯里化
先给大家介绍什么是柯里化与反柯里化 百度翻译: 在计算机科学中,柯里化(Currying)是把接受多个参数的函数变换成接受一个单一参数(最初函数的第一个参数)的函数,并且返回接受余下的参数且返回结果的 ...
- Apache中 RewriteCond 规则参数介绍 转
摘要: RewriteCond指令定义了规则生效的条件,即在一个RewriteRule指令之前可以有一个或多个RewriteCond指令.条件之后的重写规则仅在当前URI与Pattern匹配并且满足此 ...
- pmm监控页面502
我们知道pmm主要使用的是 普罗米修斯采集和grafana日志统计显示. 最近为硬盘扩过一次容量,主要是docker使用的,我的pmm是跑在docker上的,但是重启后pmm的debug日志下载502 ...
- SCARA——OpenGL入门学习三
OpenGL入门学习[三] 在第二课中,我们学习了如何绘制几何图形,但大家如果多写几个程序,就会发现其实还是有些郁闷之处.例如:点太小,难以看清楚:直线也太细,不舒服:或者想画虚线,但不知道方法只能用 ...