db file sequential read等待事件

最新推荐文章于 2026-01-07 10:43:04 发布

转载最新推荐文章于 2026-01-07 10:43:04 发布 · 854 阅读

文章标签：

#file #session #timer #buffer #sql #parallel

Oracle 同时被 2 个专栏收录

523 篇文章

订阅专栏

Oracle EBS

416 篇文章

订阅专栏

本文详细解析了Oracle数据库中的dbfilesequentialread等待事件，包括其产生原因、影响因素及如何通过SQL查询来定位问题会话。同时，介绍了如何通过优化SQL语句减少此类事件发生的方法。

db file sequential read

db file sequential read等待事件有3个参数：file＃，first block＃，和block数量。在10g中，这等待事件受到用户I/O等待级别的影响。当处理db file sequential read等待事件的时候，牢记以下关键想法。

l Oracle进程需要一个当前不在SGA中的块，等待数据库块从磁盘读入到SGA中

l 要看的两个重要的数字是单独会话的TIME_WAITED和AVERAGE_WAIT。

l 重要db file sequential read等待时间最可能是一个应用问题。

db file sequential read等待时间是由于执行对索引，回滚（undo）段，和表（当借助rowid来访问），控制文件和数据文件头的单块读操作SQL语句（用户和递归）引起的。

对于这些对象的物理I/O请求是很正常的，因此db file sequential read等待的存在不是一定意味库或应用出错了。如果会话在这事件上花了好长事件，它可能也不是一个糟糕的事情。相反，如果会话花了大量时间在equeue或latch free上，那么一定是有问题。这儿单块读变的复杂了。

==========

目的：从得到各个session中db file sequential read等待事件的总的等待时间，和等待时间所占总的等待时间(各种等待事件的总和时间)的比例中分析哪一个sid更高，更重要。

==========

select a.sid,

a.event,

a.time_waited,

a.time_waited / c.sum_time_waited * 100 pct_wait_time,

round((sysdate - b.logon_time) * 24) hours_connected

from v$session_event a, v$session b,

(select sid, sum(time_waited) sum_time_waited

from v$session_event

where event not in (

'Null event',

'client message',

'KXFX: Execution Message Dequeue - Slave',

'PX Deq: Execution Msg',

'KXFQ: kxfqdeq - normal deqeue',

'PX Deq: Table Q Normal',

'Wait for credit - send blocked',

'PX Deq Credit: send blkd',

'Wait for credit - need buffer to send',

'PX Deq Credit: need buffer',

'Wait for credit - free buffer',

'PX Deq Credit: free buffer',

'parallel query dequeue wait',

'PX Deque wait',

'Parallel Query Idle Wait - Slaves',

'PX Idle Wait',

'slave wait',

'dispatcher timer',

'virtual circuit status',

'pipe get',

'rdbms ipc message',

'rdbms ipc reply',

'pmon timer',

'smon timer',

'PL/SQL lock timer',

'SQL*Net message from client',

'WMON goes to sleep')

having sum(time_waited) > 0 group by sid) c

where a.sid = b.sid

and a.sid = c.sid

and a.time_waited > 0

and a.event = 'db file sequential read'

order by hours_connected desc, pct_wait_time;

SID EVENT TIME_WAITED PCT_WAIT_TIME HOURS_CONNECTED

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

186 db file sequential read 64446 77.0267848 105

284 db file sequential read 1458405 90.992838 105

194 db file sequential read 1458708 91.0204316 105

322 db file sequential read 1462557 91.1577045 105

139 db file sequential read 211325 52.6281055 11

256 db file sequential read 247236 58.0469755 11

192 db file sequential read 243113 88.0193625 2

你能做两件事来最小化db file sequential read事件：

l 通过降低physical和logical read来优化导致大多数wait的SQL语句

l 降低平均等待时间

此外，当前正运行的SQL语句可能或不可能是导致wait

的。这就是没有历史数据的交互式诊断经常是无功而返的原因。你能查询v$sql视图来查找有高平均DISK_READS的语句，但然后你怎样才能判断他们属于会话？因为这些限制，你可能必须确定和下次明确跟踪会话的SQL语句。一旦你已经找到，优化目标就将降低物理和逻辑读的数量。

针对表（table access by index rowid）的sequential reads

你可以看db file sequential read等待事件，通过P1,P2参数得到是表而不是索引。对于SQL语句来说通过从索引获得的rowid访问表是正常的，如下面解释计划显示，当通过rowid来读一个表的时候，oracle使用一个单独块I/O：

LVL OPERATION OBJECT

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

1 SELECT STATEMENT

2 TABLE ACCESS BY INDEX ROWID RESOURCE_ASGN_SNP

3 INDEX RANGE SCAN RESOURCE_ASGN_SNP_4IX

from:http://blog.chinaunix.net/u/20078/showart.php?id=398179