序

最近一直在做性能测试，对于单体数据库应用，数据库性能十分重要。使用Oracle数据库，会读AWR就现得更加重要了。把遇到的各种问题都在下面罗列整理一下，部分内容来自网络。随意整理了一下，内容也比较零碎，如果有其他问题可以留言讨论。

目录

• 序
• • Top 10 Forground Events by Total Wait Time
  • log file sync
  • gc current block 2-way
  • Latch: Enqueue Hash Chains
  • gc buffer busy acquire和gc buffer busy release
  • sequential read
  • segments by logical reads
  • segments by row lock waits
  • top elapsed time sql
  • db time
  • enq:TX - index contention

Top 10 Forground Events by Total Wait Time

看AWR报告一般是直接看这里，排名靠前的当然就是耗时较多的操作了。

log file sync

在Top 10 Forground Events by Total Wait Time中常见的事件，在wait class中可以看到属于commit类别。也就是说与提交有关。一般情况下，平均此项耗时在4ms以下，超过4ms就属于有性能问题了。可以考虑IO效率，CPU效率等问题。

gc current block 2-way

如果你使用的是OracleRAC 模式，会出现此等待事件。此事件说明你要读的数据不在此节点上，在另一个节点上。平局耗时不到1ms 。

Latch: Enqueue Hash Chains

在基于虚拟机的上测试时遇到了这个问题。后续没有解决。

gc buffer busy acquire和gc buffer busy release

是RAC模式下常见的事件。主要是一台机器上的多个线程排队访问远程实例的buffer导致。可能是由于热点块、低效SQL语句、数据库交叉访问导致。热点块的问题可以使用分区表、分区索引、反转索引解决。
参见这里。

sequential read

这个指标很实用，可以在不同的平台间进行比较,但是scattered read这种指标就不好比较了。
延迟一般需要在10ms以下,或者至少100 reads/sec，在基于SAN存储缓存数据的情况下，sequential read的指标有时候会保持在2ms左右，这个只能说明SAN已经把数据转化为缓存了，倒不能说明硬盘驱动确实很快。平均的延迟是在1ms以内算是正常。
参见

segments by logical reads

可以在这里看到读写比较多的块。在性能测试中，如果对一些索引或者表的读写特别的多，在这里可以体现出来。
参见

segments by row lock waits

在这里可以看到容易引起行锁的块。如果有一个项的row lock waits比较多，就要引起注意了。遇到过频繁写入索引导致有一个索引的row lock waits特别多。

top elapsed time sql

这个时候可以根据elapsed time得到一个sql执行情况的概览。查看这个的主要目的就是得到执行时间较长的sql语句。按照10分钟对的一个频度，executions为0的sql都需要格外注意，同时兼顾所占的比例。

db time

这个部分可以根据time model的部分得到。这个部分能够得到一个大体的比例，看看db time都主要耗在哪些方面了。

enq:TX - index contention