通过逻辑读来确认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消耗的时间+等待的时间)。
页:
[1]