获得逻辑读有四个好处：
       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.  逻辑读是受制于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消耗的时间+等待的时间)。