对于数据库的整体性能，AWR报告是一个非常有用的诊断工具。通常，当检测到性能问题时，我们会收集涵盖问题发生时间段的AWR报告-但***仅收集涵盖1小时时间段的AWR报告-如果时间太长，则AWR报告是不能很好的反映问题。您还应该收集没有性能问题的时间段的AWR报告，作为比较有问题的时间段的AWR报告的参考点。两个AWR报告的时间段应该相同，比如都是半小时，或者都是一小时。解读在处理性能问题时，我们最关心的是数据库在等待什么。当进程由于某种原因不能执行操作时，它需要等待。耗时最多的等待事件是我们最需要关注的，因为减少它我们可以获得最大的收益。AWR报告的“Top5TimedEvents”部分提供了此类信息，使我们能够仅关注主要问题。Top5TimedEvents如前所述，“Top5TimedEvents”是AWR报告中最重要的部分。它指出数据库的会话花费最多时间等待事件，如下所示：Top5Events部分包含一些与Events（事件）相关的信息。它记录了这段时间遇到的等待总数，等待的总时间，以及每次等待的平均时间；这部分按照每个Event占整体调用时间的百分比排序。根据Top5Events部分的信息，接下来我们需要查看AWR报告的其他部分来验证发现的问题或者做定量分析。等待事件需要根据报告周期的持续时间和当时数据库中的并发用户数来评估。例如：10分钟内1000万个等待事件比10小时内1000万个等待事件更有问题；10个用户造成的1000万个等待事件比10,000个用户造成的相同等待问题更多。就像上面的例子，将近60%的时间都在等待IO相关的事件。dbfilescatteredread事件一般表示正在进行全表扫描或索引快速全扫描引起的多块读。“dbfilesequentialread”事件一般是一个不能做多块读的操作导致的单块读（比如读索引）。另外20%的时间用于使用或等待CPU时间。过多的CPU使用率通常是由性能不佳的SQL（或那些有可能以较少资源完成相同操作的SQL）引起的；对于这样的SQL，过多的IO操作也是一种症状。关于CPU使用率，我们稍后再讨论。基于以上，我们排查这个等待事件是否有问题。如果有问题，修复它；如果正常，检查下一个等待事件。IO相关等待过多一般有两个主要原因：数据库做了太多的读操作。每次IO读操作都很慢。Top5Events部分显示的信息可以帮助我们检查：数据库是否进行了Largenumberofreads：上图显示在这段时间内两种类型的读取都大于1000万，这些是否超标取决于是否报告时间为1小时或1分钟。我们可以检查AWR报告的运行时间。如果这些读操作确实太多了，那么我们需要查看AWR报告的SQLStatistics部分的信息，因为读操作是由SQL语句发起的。每次IO读操作是否很慢：从上图可以看出，这段时间内两类读操作的平均等待时间小于8ms。8ms是快还是慢取决于底层硬件设备；一般来说，任何小于20ms的都可以认为是可以接受的。我们还可以在AWR报告的“TablespaceIOStats”部分获得更详细的信息。如上图所示，我们关心的是AvRd(ms)指标。如果它高于20毫秒并且有很多同时读取，我们可能要开始从操作系统的角度调查潜在的IO问题。虽然高“dbfilescatteredread”和“dbfilesequentialread”等待可能是与I/O相关的问题，但很多时候这些等待也可能是正常的；事实上，对于一个已经在运行的数据库系统，这些等待往往排在前5位，因为这意味着您的数据库没有那些真正的“问题”。诀窍是能够评估导致这些等待的语句是否使用了最佳访问路径。如果“dbfilescatteredread”比较高，那么相关的sql语句可能是全表扫描，没有使用索引（可能没有创建索引，可能没有合适的索引）；相应地，如果“dbfilesequentialread”过多，则可能说明这些SQL语句使用了选择性低的索引，导致访问过多不必要的索引块或使用了错误的索引。这些等待可能表明SQL语句的执行计划并不完美。接下来，我们需要使用AWR来检查这些topSQL是否可以进一步调优。我们可以查看AWR报告中的SQLStatistics部分。上面的例子显示20%的时间花在等待或使用CPU上。我们还需要检查SQL统计部分以进行进一步分析。应该注意的是，接下来的分析步骤取决于我们在TOP5部分中的发现。在上面的例子中，前3个等待事件表明问题可能与SQL语句的执行计划不佳有关，因此我们接下来将分析“SQL统计”部分。同样，因为我们没有看到与latch相关的wait，所以latch在我们的例子中并没有造成严重的性能问题；那么我们根本不需要去分析latch相关的信息。一般来说，如果数据库性能很慢，“CPU”、“dbfilesequentialread”和“dbfilescatteredread”在TOP5等待事件中比较明显（不管它们之间的先后顺序），我们总是需要检查TopSQL（按逻辑和物理读取）部分；调用SQLTuningAdvisor或手动调整这些SQL以确保它们高效运行。SQLStatisticsAWR包含一些不同的SQL统计信息：根据Top5部分的TopWaitEvent，我们需要查看不同的SQL统计信息。在我们的例子中，TopWaitEvent是“dbfilescatteredread”、“dbfilesequentialread”和CPU；我们最需要关心的是按CPUTime、Gets和Reads排序的SQL。我们先从“SQLorderedbygets”说起，因为造成highbuffergets的SQL语句一般都是需要调优的对象。对于这些TopSQL，你可以手动调优或者调用SQLTuningAdvisor。Analysis:->TotalBufferGets:4,745,943,815假设这是一个一小时的AWR报告，4,745,943,815是一个非常大的值；所以需要进一步分析这条SQL是否使用了最佳执行计划IndividualBufferGetssingleintheaboveexample有很多条SQLbufferget，最少的有8.5亿条。这三个SQL指向缓冲区过多的两个不同原因：注意：对于一些非常繁忙的系统，以上数字可能是正常的。这时候，我们需要将这些数字与正常时间段的数字进行比较。如果没有太大区别，那么这些SQL就不是问题的罪魁祸首（虽然我们仍然可以通过调优这些SQL获益）#单次执行buffergetsSQL_ID为'5t1y1nvmwp2'和'4at7cbx8hnz'的SQL语句被执行了168总次数，但每次执行都会导致超过500万次缓冲区获取。这两个SQL应该是调优的主要候选对象。#ExcessiveexecutiontimesSQL_ID'grr4mg7ms81'每次执行只导致16次buffergets，减少每次执行此SQL的bufferget可能不会显着减少总的buffergets。这个语句的问题是它执行的太频繁了，6500万次。更改此SQL的执行计数可能更有意义。这个SQL好像是循环调用的。如果它一次可以处理更多的数据，它可能会减少执行的次数。
