在理想情况下，要度量资源的消耗应该考虑数据库引擎使用的所有资源类型，包括：CPU、内存、磁盘以及网络。当然，这是能做到的。不过遗憾的是，得到并评估所有的数据要花费大量时间和努力，且通常只能对一个调优会话中有限的SQL语句这么做。还应该考虑当处理一行的时候，CPU处理的时间依赖于处理器的速度，很明显这在不同系统中是不一样的。此外，内存的使用量和返回的行数大致成正比，而磁盘和网络资源并不总是会用到。实际上，常看到长时间运行的SQL语句使用了不大的内存，但却没有产生磁盘和网络访问。
幸运的是，存在一个针对单一数据库的易于收集的度量，能够告诉我们许多关于数据库引擎工作量的信息：逻辑读数量，即，在执行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消耗的时间+等待的时间)。