何时会发生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 ...
随机推荐
- LeetCode OJ:Simplify Path(简化路径)
Given an absolute path for a file (Unix-style), simplify it. For example,path = "/home/", ...
- pgbench使用记录
1.初始化: pgbench -i pgbench 如果端口号有变化,需要先手动创建数据库,再执行. pgbench -i -s 10 -p 5433 pgbench 重点:主要用到两个参数,-i:初 ...
- 【PL/SQL编程】注释说明
1. 单行注释 由两个连接字符“--”开始,后面紧跟着注释内容. 2. 多行注释 由/*开头, 由*/结尾.
- libwebsockets 运行问题
/****************************************************************************** * libwebsockets 运行问题 ...
- 【sqlite】错误代码整理
这两天为了一个问题折腾了好久,记载一下. SQLite语句一定要严格按例子来写,例如: "CREATE TABLE PunchData (Id Text primary key, Heigh ...
- 开源的UML建模工具
StarUML 一个开源的UML建模工具 地址:http://staruml.sourceforge.net/en/ 效果图: 出处:http://www.cnblogs.com/zzy0471/ar ...
- bzoj 3202 [Sdoi2013]项链——容斥+置换+推式子
题目:https://www.lydsy.com/JudgeOnline/problem.php?id=3202 可见Zinn博客:https://www.cnblogs.com/Zinn/p/100 ...
- 实现对sqlite数据库增删改查
package com.example.db.dao;import java.util.ArrayList;import java.util.List;import android.content.C ...
- zabbix监控的配置
ZABBIX监控的操作步骤有两个! 首先登录到zabbix 的主界面在configuration---host---create host在如上的host 创建界面中 主要是输入被监测的server的 ...
- PHP 判断手机号归属地 和 运营商的免费接口
在项目开发的时候,需要去查询又一批手机号或者固话的具体信息(归属地 运营商) 就需要写一个脚本,来批量请求接口来得到我们想要的数据 学习源头:https://blog.csdn.net/shaerdo ...