爱华网在数据为日常维护过程中，出现性能问题我们通常会取数据库的AWR报告进行分析，今天在metalink上看到AWR学习专题，记录一下自己学习过程！
一、如何主动避免问题发生及做好诊断信息的收集
有些问题是无法预见的，但大部分其它的问题如果及早发现一些征兆其实是可以避免的。同时，如果问题确实发生了，那么收集问题发生时的信息就非常重要。有关于如何主动避免问题及诊断信息的收集，请参见：
Document 1482811.1 Best Practices: Proactively Avoiding Database and QueryPerformance IssuesDocument 1477599.1 Best Practices Around Data Collection For PerformanceIssues有兴趣的朋友可以通过metalink看看，不过今天我们的目的是如何分析AWR报告，我们继续往下看，AWR报告系统默认是一个小时收集一次，默认保留7天，11g中默认保留八天，为了维护和分析方便，我们取AWR报告时最好取一小时的，同时收集正常时的AWR报告做成基线，方便以后出问题了进行对比，这样可以加快分析速度，Toad里面有一个AWR对比的功能，有兴趣的朋友可以查一下相关的资料，关于如何取AWR报告，详见：Document 1363422.1 Automatic Workload Repository (AWR) Reports - StartPoint取AWR进行分析前最好先看看对应时段的ADDM报告，ADDM报告已经针对该时段内的问题给出了指导建议，帮助比较大，有朋友可能会说，这样通过命令取太不方便了，的确如此，但是TOAD可以很方便很容易查看这些报告，但是查看这些报告需要较高版本的TOADFOR ORACLE 11G是一个比较不错的版本二、AWR分析重点关注事项拿到AWR报告后第一件事是判断当时数据库负载是否很高，判断方法详见：http://blog.sina.com.cn/s/blog_61cd89f60102ecsv.html方法很多，不唯一，仅供参考 Top 5Events部分包含了一些跟Events（事件）相关的信息。它记录了这期间遇到的等待的总次数，等待所花费的总时间，每次等待的平均时间；这一部分是按照每个Event占总体calltime的百分比来进行排序的。根 据Top 5Events部分的信息的不同，接下来我们需要检查AWR报告的其他部分，来验证发现的问题或者做定量分析。等待事件需要根据报告期的持续时间和当时数据库中的并发用户数进行评估。如：10分钟内1000万次的等待事件比10个小时内的1000万等待更有问题；10个用户引起的1000万次的等待事件比10,000个用户引起的相同的等待要更有问题。三、TOP 5部分Top5Events部分包含了一些跟Events（事件）相关的信息。它记录了这期间遇到的等待的总次数，等待所花费的总时间，每次等待的平均时间；这一部分是按照每个Event占总体calltime的百分比来进行排序的 根据Top 5Events部分的信息的不同，接下来我们需要检查AWR报告的其他部分，来验证发现的问题或者做定量分析。等待事件需要根据报告期的持续时间和当时数据库中的并发用户数进行评估。如：10分钟内1000万次的等待事件比10个小时内的1000万等待更有问题；10个用户引起的1000万次的等待事件比10,000个用户引起的相同的等待要更有问题。
就像上面的例子，将近60%的时间是在等待IO相关的事件。
其他20%的时间是花在使用或等待CPUtime上。过高的CPU使用经常是性能不佳的SQL引起的（或者这些SQL有可能用更少的资源完成同样的操作）；对于这样的SQL，过多的IO操作也是一个症状。关于CPU使用方面，我们会在之后讨论。在以上基础上，我们将调查是否这个等待事件是有问题的。若有问题，解决它；若是正常的，检查下个等待事件。
过多的IO相关的等待一般会有两个主要的原因：
Top 5 Events部分的显示的信息会帮助我们检查：
我们还可以在AWR报告"Tablespace IO Stats"部分得到更详细的信息
这部分我们关注的是AvRd(ms)的指标。如果它高于20ms并且同时有很多读操作的，我们可能要开始从OS的角度调查是否有潜在的IO问题。
注：对于一些比较空闲的tablespace/files,我们可能会得到一个比较大的AvRd(ms)值；对于这样的情况，我们应该忽略这样的tablespace/files;因为这个很大的值可能是由于硬盘自旋(spin)引起的，没有太大的参考意义。比如对于一个有1000万次读操作而且很慢的系统，引起问题的基本不可能是一个只有10次read的tablespace/file以下的文档可以帮助我们进一步调查IO方面的问题：Note:223117.1Troubleshooting I/O-related waits虽然高"db file scattered read"和"dbfile sequentialread"等待可以是I/O相关的问题，但是很多时候这些等待也可能是正常的；实际上，对一个已经性能很好的数据库系统，这些等待事件往往在top5等待事件里，因为这意味着您的数据库没有那些真正的“问题”。怎么判断是否有问题呢？
我们只能能够评估引起这些等待的语句是否使用了最优的访问路径。如果"db file scatteredread"比较高，那么相关的SQL语句可能使用了全表扫描而没有使用索引（也许是没有创建索引，也许是没有合适的索引）；相应的，如果"dbfile sequentialread"过多，则表明也许是这些SQL语句使用了selectivity不高的索引从而导致访问了过多不必要的索引块或者使用了错误的索引。这些等待可能说明SQL语句的执行计划不是最优的，接下来就需要通过AWR来检查这些topSQL是否可以进一步的调优，我们可以查看AWR报告中 SQLStatistics的部分.
上面的例子显示了20%的时间花在了等待或者使用CPU上，我们也需要检查 SQLstatistics 部分来进一步的分析。需要注意，接下来的分析步骤取决于我们在TOP5部分的发现。在上面的例子里，3个top wait event表明问题可能与SQL语句执行计划不好有关，所以接下来我们要去分析"SQLStatistics"部分。同样的，因为我们并没有看到latch相关的等待，latch在我们这个例子里并没有引发严重的性能问题；那么我们接下来就完全不需要分析latch相关的信息。一般来讲，如果数据库性能很慢，TOP5等待事件里"CPU"， "db file sequential read" 和"db file scattered read"比较明显（不管它们之间的顺序如何），我们总是需要检查Top SQL (by logical and physicalreads)部分；调用SQL TuningAdvisor或者手工调优这些SQL来确保它们是有效率的运行。
三、SQLStatistics部分AWR包含了一些不同的SQL统计值：
根据Top 5 部分的Top Wait Event不同，我们需要检查不同的SQLstatistic，在我们这个例子里，Top Wait Event是"db file scattered read"，"db filesequential read"和"CPU"；我们最需要关心的是SQL orderedby CPU Time, Gets and Reads,我们要从"SQL ordered bygets"入手，因为引起高buffer gets的SQL语句一般是需要调优的对象
对这些Top SQL,可以手工调优，也可以调用SQL TuningAdvisor简称STA，具体使用方法可以参照：
Document 271196.1 Automatic SQL Tuning - SQL Profiles.
Document 262687.1 How to use the Sql Tuning Advisor.
Document 276103.1 PERFORMANCE TUNING USING ADVISORS ANDMANAGEABILITY FEATURES: AWR, ASH,andADDM and Sql TuningAdvisor.
分析：
Other SQL Statistic Sections
就像之前提到的那样，AWR报告中有很多不同的部分用来分析各种不同的问题。如果特定的问题并没有出现，那么分析AWR报告的这些部分并不能有很大的帮助，面提到了一些可能的问题：四、Load Profile部分
根据Top5等待事件的不同，"Load Profile"可以提供一些有用的背景资料或潜在问题的细节信息。
在这一部分，我们重点关注，hard parse的次数要少于soft parse，如果mutex等待事件比较严重，如"librarycache: mutex X"，那么查看所有parse的比率会更有用，此时最有效的方法就是把LoadProfile部分跟正常时候的AWR报告做比较会更有用，比较redo size, users calls, 和parsing
五、Instance Efficiency部分
InstanceEfficiency部分更适用于一般性的调优，而不是解决某个具体问题（除非等待事件直接指向这些指标）。
从我们的这个例子来看，最有用的信息是99.69%Non-ParseCPU，它表明几乎所有的CPU都消耗在了Execution而不是Parse上。98.04％ 的soft parse比率显示hardparse的比例很小，这是可取的。Execute to Parse57.31%很一般，说明cursor没有被很好的重用了。我们总是期望这里的值都是接近100%,但是因为应用的不同，如果这个部分的参数的某些值很小，也是可以认为没有问题的；如在数据仓库环境，hardparse因为使用了物化视图或histogram而变得很高。所以，重要的是，我们需要把这部分信息和正常时候的AWR报告做比较来判断是否有问题。
六、LatchActivity 部分
在我们这个例子里，我们并没有看到很高的latch相关的等待，所以这部分的信息可以忽略，但是如果latch相关的等待很严重，我们需要查看LatchSleep Breakdown 部分sleeps很高的latch
这里toplatch是cache buffers chains. Cache Buffers Chains latches是用来保护buffercaches中的buffers。在我们读取数据时，这个latch是正常需要获得的。Sleep的数字上升代表session在读取buffers时开始等待这个latch。争用通常来自于不良的SQL要读取相同的buffers在我们这个例子里，虽然读取buffer的操作发生了10亿次，但是只sleep了970次，可以认为是比较低的。AvgSlps/Miss（Sleeps/ Misses）也比较低。这表明当前Server有能力处理这样多的数据，所以没有发生CacheBuffers Chains latch的争用,关于其他的latch free等待，请参照以下文档：
其他潜在的CPU相关的问题：
八、'Log file sync'waits当 一个user session commit或rollback时，log writer进程会把redo从logbuffer中写入redologfile文件，AWR报告会帮助我们来确定是否存在这方面的问题，并且确认是否是由物理IO引起。如果”log filesync”事件比较严重，下面的文档详细描述了如何来处理:
Document 1376916.1 Troubleshooting: "Log File Sync" Waits
Note:34592.1WAITEVENT: "log file sync"
九、Buffer busywaits
当一个session从buffercache读取一个buffer时，如果这个buffer处于busy的状态（由于其它session正在向其中读取数据，或者是由于这个buffer被其它的session以不兼容模式持有），那么这个session就会等待这个事件。参照下面文档来找出哪个block处于busy状态和为什么：
Document 155971.1 Resolving Intense and "Random" Buffer BusyWait Performance
Problems:Note:34405.1WAITEVENT: "buffer busy waits"
九、诊断其他问题
关于其他性能问题，请参照文档:
Document 1377446.1 Troubleshooting Performance Issues十、其他的AWR参考文章当阅读AWR报告的其他部分时，可以参照下面的一些文档:
Document 786554.1 How to Read PGA Memory Advisory Section inAWR and Statspack ReportsDocument 754639.1 How to Read Buffer Cache Advisory Section inAWR and Statspack Reports
Document 1301503.1 Troubleshooting: AWR Snapshot Collectionissues
Document 1363422.1 Automatic Workload Repository (AWR) Reports- Start Point 以上只是学习AWR的专题的一个开始，只是一个简单的概述，要想完全搞懂AWR还有很长很长的路要走，需要坚持多看、多总结，以后会有更多的AWR专题，分析不当之处还望各位高手批评指点，谢谢！
