通过逻辑读来确认SQL问题

获得逻辑读有四个好处:
       1.  逻辑读是受制于CPU能力的操作,因而,很好的反映了CPU的使用情况;
       2.  逻辑读可能导致物理读,因此,通过减少逻辑读的数量,很可能会降低I/O操作次数;
       3.  逻辑读是受制于串行操作,既然经常要考虑多用户负载的优化,最小逻辑读将有利于避免扩展性问题;
       4.  逻辑读的数量可能通过SQL跟踪文件和动态性能视图在SQL语句以及执行计划级别获得。
       既然逻辑读非常接近总的资源开销,就可以集中精力在每个返回行具有较多逻辑读的访问路径上,一般可以考虑如下的“经验法则”:
       1.  每个返回行少于5个逻辑读的访问路径可能是不错的。
       2.  每个返回行少于10-15个逻辑读的访问路径可以接受的。
       3.  每个返回行少于15-20个逻辑读的访问路径可能是低效的,可能存在改进的余地。
       通过每天分析AWR报告,我发现逻辑读高的SQL语句引起的问题,一是高消耗CPU;二是容易形成热块,形成latch: cache buffers chains等待事件,导致SQL执行变慢(SQL执行时间=CPU消耗的时间+等待的时间)。
标签: 暂无标签
oraunix

写了 199 篇文章,拥有财富 1026,被 339 人关注

转播转播 分享分享 分享淘帖
回复

使用道具

成为第一个吐槽的人

您需要登录后才可以回帖 登录 | 加入社区

本版积分规则

意见
反馈