High Waits on 'Db File Sequential Read' Due to Table Lookup Following Index Access

最近某些系统AWR的top 5中“Db File Sequential Read”占据的时间百分比非常大,通常这种等待事件是一种正常的。但当前系统性能是有些问题的,并发量大,有些缓慢,因此需要判断这种等待事件是否能够减少。MOS有几篇关于这种等待事件的介绍,这是其中一篇。

High Waits on 'Db File Sequential Read' Due to Table Lookup Following Index Access (文档 ID 875472.1)

即使执行计划已经是最优的了,但一次查询仍能够等待“db file sequential read'”这种事件很长的时间。通常是因为索引扫描的结果集非常大。例如:

SELECT D
FROM BIG_TABLE
WHERE A = 1253
AND B in ('CA', 'CO')
AND C > 210 ;
Rows    Row Source Operation
------- ---------------------------------------------------
 215431 TABLE ACCESS BY INDEX ROWID BIG_TABLE (cr=880191 pr=430780 pw=0 time=2293667056 us) <<<
3582275  INDEX RANGE SCAN BIG_TABLE_IDX (cr=664748 pr=218595 pw=0 time=352506821 us)

Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  SQL*Net message to client                   14363        0.00          0.02
  db file sequential read                    461688        1.15       2254.55 <<<
  SQL*Net message from client                 14363        0.01          9.77
  SQL*Net break/reset to client                   1        0.00          0.00
...

在大多数这样的例子中,执行查询语句在“TABLE ACCESS BY INDEX ROWID”上的等待要比INDEX SCAN上需要更多的。这是因为随机访问表行的代价要比索引扫描更大。

为此,可以有以下几种方法调试:

1. 检查是否有更好的索引或执行计划。可能需要重新设计索引。

2. 尝试全表扫描。全表扫描通常比索引扫描要快,尽管CBO成本比索引扫描的成本高。

SELECT /*+ FULL(BIG_TABLE) */  D 
FROM BIG_TABLE 
WHERE A = 1253 
AND B in ('CA', 'CO') 
AND C > 210 ;

3. 如果仅仅有很少的列出现在SELECT和WHERE子句中,可以考虑为查询创建一个复合索引避免回表。

例如:

CREATE INDEX <INDEX_NAME> ON BIG_TABLE (A, B, C, D);

注意:仅针对SELECT语句有效。如果是UPDATE语句,这种做法可能没用。

4. 将表移动到更大block块大小的表空间。更大的block块会有更多的行,所以对减少block块IO会有帮助。重新组织表也会有帮助,因为这样做可以让索引有一个更小的clustering聚类因子。

5. 可以考虑增加buffer cache的大小,以至于可以缓存更多的块大小。如果表是频繁访问的,使用keep buffer池也是一个不错的选择。

6. 考虑使用IOT(索引组织表)。IOT可能减少IO,原因就是他会将数据存储于一个B树索引结构。例如,如果A列是表BIG_TABLE的主键,可以按照如下方法创建IOT:

create table BIG_TABLE (A number primary key, B char(2), C number, D varchar2(10)) organization index;

7. 如果服务器有足够的空闲资源(CPU,内存),考虑使用并行执行。这种方式不会减少IO,但是有助于降低执行时间。

8. 较差的磁盘IO也可能是一个原因。可以提高表所在磁盘设备的IO。这可能需要系统管理员的协助。

时间: 2024-07-30 18:36:39

High Waits on 'Db File Sequential Read' Due to Table Lookup Following Index Access的相关文章

db file sequential read及优化

db file sequential read:直接路径读:   官方说明如下: This event signifies that the user process is reading a buffer into the SGA buffer cache and is waiting for a physical I/O call to return. A sequential read is a single-block read. Single block I/Os are usuall

Resolving Issues Where Application Queries are Waiting Too Frequently for &#039;db file sequential read&#039;

昨天有篇"db file sequential read"的介绍,还有一篇类似的:Resolving Issues Where Application Queries are Waiting Too Frequently for 'db file sequential read' Operations (文档 ID 1475825.1) 诊断"db file sequential read"的步骤: 简述: 低效的SQL会引起不同节点间非常多的块读. 问题确认: 花

详解 db file sequential read 等待事件

db file sequential read (本文由thomaswoo_dba翻译,转载请注明出处) db file sequential read 事件有三个参数:file#,first block#, block count, 在oracle 10g里,此等待事件在归于 User I/O wait class 下面的. 处理db file sequential read 事件要牢牢把握下面三个主要思想: 1)oracle 进程需要访问的block不能从SGA 中获取,因此oracle 进

db file sequential read 详解

db file sequential read (本文由thomaswoo_dba翻译,转载请注明出处) db file sequential read 事件有三个参数:file#,first block#, block count, 在oracle 10g里,此等待事件在归于 User I/O wait class 下面的. 处理db file sequential read 事件要牢牢把握下面三个主要思想:1)oracle 进程需要访问的block不能从SGA 中获取,因此oracle 进程

常识之外:全表扫描为何产生大量 db file sequential read 单块读?

原创 2016-07-05 熊军 Oracle   编辑手记:在理解Oracle技术细节时,我们不仅应该读懂概念,还要能够通过测试验证细节,理解那些『功夫在诗外』的部分,例如全表扫描和单块读. 开发人员在进行新系统上线前的数据校验测试时,发现一条手工执行的 SQL 执行了超过1小时还没有返回结果.SQL 很简单: 下面是这条 SQL 的真实的执行计划: 很显然,在这个表上建 billing_nbr 和 start_date 的复合索引,这条 SQL 就能很快执行完(实际上最后也建了索引).但是这

db file sequential read等待事件

最近某个应用的AWR中总显示"db file sequential read"等待事件位于top 5之首,下面检索下MOS关于这个等待事件的说明. 等待事件: "db file sequential read" Reference Note (文档 ID 34559.1)         这种等待事件是一种IO读请求相关的等待.与"db file scattered read"不同,因为"sequential read"是将数

解决db file sequential read与db file scattered read

1.根据收集的等待事件,分析是那些对象以及对应的sql. 2.确定是那些对象,执行如下: SELECT segment_name, partition_name, p1, p2 FROM dba_extents, wait1 WHERE wait1.p2 BETWEEN block_id AND (block_id + blocks - 1) AND file_id = wait1.p1ORDER BY segment_name 3.确定执行的sql语句,执行如下: SELECT hash_va

消除11.2上的db file parallel read

客户在11.2.0.3环境中进行压力测试,发现出现大量的db file parallel read等待事件.     这个等待是11g以后才出现的,而在11g以前,一般这个等待事件发生在数据文件的恢复过程中.而11g新增了prefetch的特性,也可能导致这个等待事件的产生. 当运行压力测试时,后台的等待事件如下: SQL> select event, count(*) from v$session where username = user group by event order by 2;

db file async I/O submit 等待事件优化

db file async I/O submit 等待事件优化   一.数据发生db file async I/O submit 我们从数据库awr报告中经常会看到很高db file async I/O submit的等待事件: SQL> select event,wait_class,wait_time from v$session_wait where wait_class<>'Idle' EVENT WAIT_CLASS WAIT_TIME --------------------