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

20 篇文章 0 订阅
18 篇文章 0 订阅

最近某些系统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。这可能需要系统管理员的协助。

1、资源项目源码均已通过严格测试验证,保证能够正常运行; 2、项目问题、技术讨论,可以给博主私信或留言,博主看到后会第一时间与您进行沟通; 3、本项目比较适合计算机领域相关的毕业设计课题、课程作业等使用,尤其对于人工智能、计算机科学与技术等相关专业,更为适合; 4、下载使用后,可先查看README.md或论文文件(如有),本项目仅用作交流学习参考,请切勿用于商业用途。 5、资源来自互联网采集,如有侵权,私聊博主删除。 6、可私信博主看论文后选择购买源代码。 1、资源项目源码均已通过严格测试验证,保证能够正常运行; 2、项目问题、技术讨论,可以给博主私信或留言,博主看到后会第一时间与您进行沟通; 3、本项目比较适合计算机领域相关的毕业设计课题、课程作业等使用,尤其对于人工智能、计算机科学与技术等相关专业,更为适合; 4、下载使用后,可先查看README.md或论文文件(如有),本项目仅用作交流学习参考,请切勿用于商业用途。 、5资源来自互联网采集,如有侵权,私聊博主删除。 6、可私信博主看论文后选择购买源代码。 1、资源项目源码均已通过严格测试验证,保证能够正常运行; 2、项目问题、技术讨论,可以给博主私信或留言,博主看到后会第一时间与您进行沟通; 3、本项目比较适合计算机领域相关的毕业设计课题、课程作业等使用,尤其对于人工智能、计算机科学与技术等相关专业,更为适合; 4、下载使用后,可先查看README.md或论文文件(如有),本项目仅用作交流学习参考,请切勿用于商业用途。 5、资源来自互联网采集,如有侵权,私聊博主删除。 6、可私信博主看论文后选择购买源代码。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值