查看: 3085|回复: 8

db file sequential read等待还有没有优化的潜力?

[复制链接]
论坛徽章:
71
ITPUB元老
日期:2009-11-30 15:55:11授权会员
日期:2009-11-30 11:36:17ITPUB季度 技术新星
日期:2010-08-31 10:47:25优秀写手
日期:2014-12-24 06:00:14ITPUB8周年纪念徽章
日期:2009-09-27 10:21:20祖国60周年纪念徽章
日期:2009-10-09 08:28:00奔驰
日期:2013-10-20 13:32:09数据库板块每日发贴之星
日期:2008-10-03 01:02:14数据库板块每日发贴之星
日期:2009-11-23 01:01:03数据库板块每日发贴之星
日期:2010-07-27 01:01:02
发表于 2009-8-16 22:20 | 显示全部楼层 |阅读模式
如果sql都优化了,索引也都建好测试过了,有时还是有db file sequential read等待,那么这正常吗?还有没有优化的潜力?
存储只有一个盘阵。
SQL> select event,wait_time,seconds_in_wait,wait_class,state from v$session_wait where wait_class!='Idle' order by wait_time desc;

EVENT                                                             WAIT_TIME SECONDS_IN_WAIT WAIT_CLASS                                                       STATE
---------------------------------------------------------------- ---------- --------------- ---------------------------------------------------------------- -------------------
db file sequential read                                                   0               0 User I/O                                                         WAITING
db file sequential read                                                   0               0 User I/O                                                         WAITING
log file parallel write                                                   0               0 System I/O                                                       WAITING
RMAN backup & recovery I/O                                                0               0 System I/O                                                       WAITING
db file sequential read                                                   0               0 User I/O                                                         WAITING
论坛徽章:
2
2010新春纪念徽章
日期:2010-03-01 11:07:21ITPUB9周年纪念徽章
日期:2010-10-08 09:32:27
发表于 2009-8-17 06:15 | 显示全部楼层
看了这个事件, 想起有位大师,也不知道什么来头, 当时一客户说数据库有问题, 做了个STATSPACK, 等待事件是SEQUENCIAL READ 和LATCH FREE.

他看了一眼TOP的SQL, 就下了结论:   某条SQL 执行了过多的SEQUENCIAL READ 而CONSISTANT READ 等只有很少的结果集, 他认为是PLAN 走了不该走的INDEX. 应该FULL TABLE SCAN.  

这个判断我一直没弄懂.   不知对楼主有没启示.

如果纯粹是该一事件, 那么设置DB_nk_BLOCK_SIZE可以加快读.

使用道具 举报

回复
论坛徽章:
3
九尾狐狸
日期:2006-04-12 17:47:49ITPUB新首页上线纪念徽章
日期:2007-10-20 08:38:44ITPUB十周年纪念徽章
日期:2011-11-01 16:21:15
发表于 2009-8-17 07:44 | 显示全部楼层
有这个等待是正常的,不是很多就可以。

使用道具 举报

回复
论坛徽章:
188
红宝石
日期:2014-05-09 08:24:37萤石
日期:2014-01-03 10:25:39奥运会纪念徽章:羽毛球
日期:2008-07-01 10:46:06奥运会纪念徽章:马术
日期:2008-07-07 17:43:24奥运会纪念徽章:射箭
日期:2008-07-25 18:07:39奥运会纪念徽章:皮划艇激流回旋
日期:2008-07-30 10:02:57奥运会纪念徽章:花样游泳
日期:2008-09-26 13:02:43奥运会纪念徽章:排球
日期:2008-12-03 11:23:272010新春纪念徽章
日期:2010-01-04 08:33:082010年世界杯参赛球队:澳大利亚
日期:2010-02-26 11:08:44
发表于 2009-8-17 08:21 | 显示全部楼层
注意看看buffer get/exec 很高的sql。

使用道具 举报

回复
招聘 : Java研发
认证徽章
论坛徽章:
71
马上加薪
日期:2014-02-19 11:55:14蜘蛛蛋
日期:2012-12-26 18:16:01茶鸡蛋
日期:2012-11-16 08:12:48ITPUB 11周年纪念徽章
日期:2012-10-09 18:05:07奥运会纪念徽章:网球
日期:2012-08-23 14:58:08奥运会纪念徽章:沙滩排球
日期:2012-07-19 17:28:14版主2段
日期:2012-07-07 02:21:02咸鸭蛋
日期:2012-03-23 18:17:482012新春纪念徽章
日期:2012-02-13 15:13:512012新春纪念徽章
日期:2012-02-13 15:13:51
发表于 2009-8-17 08:57 | 显示全部楼层
wait并非意味着效率有问题

使用道具 举报

回复
论坛徽章:
11
生肖徽章2007版:虎
日期:2009-08-14 13:50:18ITPUB十周年纪念徽章
日期:2011-11-01 16:24:512010广州亚运会纪念徽章:自行车
日期:2011-03-19 13:35:152011新春纪念徽章
日期:2011-02-18 11:42:492010世博会纪念徽章
日期:2010-10-17 20:10:522010系统架构师大会纪念
日期:2010-09-03 16:39:572010新春纪念徽章
日期:2010-03-01 11:04:592010新春纪念徽章
日期:2010-01-04 08:33:08参与WIN7挑战赛纪念
日期:2009-11-06 16:05:25生肖徽章2007版:狗
日期:2009-09-10 11:32:03
发表于 2009-8-17 09:25 | 显示全部楼层
wait 是相对的,不是绝对的!数据库有wait才是正常!

使用道具 举报

回复
招聘 : 数据库管理员
论坛徽章:
66
ITPUB元老
日期:2005-07-16 18:49:11授权会员
日期:2005-10-30 17:05:33ITPUB新首页上线纪念徽章
日期:2007-10-20 08:38:44现任管理团队成员
日期:2011-05-07 01:45:08版主3段
日期:2012-05-15 15:24:11
发表于 2009-8-17 09:50 | 显示全部楼层
db file sequential read优化的途径就是减少索引扫描,比如优化业务逻辑,减少SQL的运行等。。。

使用道具 举报

回复
论坛徽章:
5
生肖徽章2007版:鸡
日期:2008-01-02 17:35:53奥运会纪念徽章:羽毛球
日期:2008-06-23 12:00:05奥运会纪念徽章:柔道
日期:2008-07-04 09:42:36奥运会纪念徽章:皮划艇激流回旋
日期:2008-08-12 14:50:402010新春纪念徽章
日期:2010-03-01 11:19:07
发表于 2009-8-17 10:51 | 显示全部楼层
db file sequential read
的优化, 在不修改任何代码的前提下, 可以参考如下思路:
以减少每次sql访问所要读取的索引块为目标.


为了达到这个目标, 可以考虑如下手段:
1. 对表上的索引进行优化, 比如多字段组合索引, 减少组合字段的个数, 去掉不必要的字段, 尽量做成单列索引.
2. 定期对索引进行rebuild操作, 减少索引中的碎片.

定位逻辑读较大的top sql,
看是否执行计划走了 index full scan, 这个操作是很慢的, 会使用单块读的方式读完整个索引. 调整sql, 使执行计划不要走这个操作.

使用道具 举报

回复
论坛徽章:
71
ITPUB元老
日期:2009-11-30 15:55:11授权会员
日期:2009-11-30 11:36:17ITPUB季度 技术新星
日期:2010-08-31 10:47:25优秀写手
日期:2014-12-24 06:00:14ITPUB8周年纪念徽章
日期:2009-09-27 10:21:20祖国60周年纪念徽章
日期:2009-10-09 08:28:00奔驰
日期:2013-10-20 13:32:09数据库板块每日发贴之星
日期:2008-10-03 01:02:14数据库板块每日发贴之星
日期:2009-11-23 01:01:03数据库板块每日发贴之星
日期:2010-07-27 01:01:02
 楼主| 发表于 2009-8-17 12:30 | 显示全部楼层
好的。

使用道具 举报

回复

您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

TOP技术积分榜 社区积分榜 徽章 团队 统计 知识索引树 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档
  ChinaUnix | ChinaUnix博客 | ChinaUnix论坛
CopyRight 1999-2011 itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有 联系我们 
京ICP备09055130号-4  北京市公安局海淀分局网监中心备案编号:11010802021510 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表