合 如何使用AWR报告来诊断数据库性能问题 (Doc ID 1523048.1)
常见问题:如何使用AWR报告来诊断数据库性能问题 (Doc ID 1523048.1)
常见问题:如何使用AWR报告来诊断数据库性能问题 (Doc ID 1523048.1)
How to Use AWR Reports to Diagnose Database Performance Issues (Doc ID 1359094.1)
目标
本文旨在提供如何解释跟数据库性能问题息息相关的AWR信息。
需要注意的是生成 AWR Report 或访问 AWR 相关的视图，以及使用任何 AWR 相关的诊断信息，都需要额外的 Diagnostic Pack License。这包括生成 AWR/ADDM/ASH report，也包括当技术支持要求的生成上述报表时。
注意: Oracle Diagnostics Pack (以及 Oracle Tuning Pack) 只在企业版中提供。
详见:
Oracle® Database Licensing Information
12c Release 1 (12.1)
Part number E17614-08
Chapter 1 1 Oracle Database Editions
Feature Availability by Edition
http://docs.oracle.com/database/121/DBLIC/options.htm#DBLIC139
最佳实践
如何主动避免问题发生及做好诊断信息的收集
有些问题是无法预见的，但大部分其它的问题如果及早发现一些征兆其实是可以避免的。同时，如果问题确实发生了，那么收集问题发生时的信息就非常重要。有关于如何主动避免问题及诊断信息的收集，请参见：
Document 1482811.1 Best Practices: Proactively Avoiding Database and Query Performance Issues
Document 1477599.1 Best Practices Around Data Collection For Performance Issues
解决方案
对于数据库整体的性能问题，AWR的报告是一个非常有用的诊断工具。
一般来说，当检测到性能问题时，我们会收集覆盖了发生问题的时间段的AWR报告-但是最好只收集覆盖1个小时时间段的AWR报告-如果时间过长，那么AWR报告就不能很好的反映出问题所在。
还应该收集一份没有性能问题的时间段的AWR报告，作为一个参照物来对比有问题的时间段的AWR报告。这两个AWR报告的时间段应该是一致的，比如都是半个小时的，或者都是一个小时的。
关于如何收集AWR报告，请参照如下文档：
Document 1363422.1 Automatic Workload Repository (AWR) Reports - Start Point
注：最好一开始我们从ADDM报告入手，因为对应时间段的ADDM报告往往已经指出了问题所在。
参见:
Interpretation
在处理性能问题时，我们最关注的是数据库正在等待什么。
当进程因为某些原因不能进行操作时，它需要等待。花费时间最多的等待事件是我们最需要关注的，因为降低它，我们能够获得最大的好处。
AWR报告中的"Top 5 Timed Events"部分就提供了这样的信息，可以让我们只关注主要的问题。
Top 5 Timed Events
正如前面提到的，"Top 5 Timed Events"是AWR报告中最重要的部分。它指出了数据库的sessions花费时间最多的等待事件，如下：
1 2 3 4 5 6 7 8 9 | Top 5 Timed Events Avg %Total ------------------ wait Call Event Waits Time (s) (ms) Time Wait Class ------------------------------ ------------ ----------- ------ ------ ---------- db file scattered read 10,152,564 81,327 8 29.6 User I/O db file sequential read 10,327,231 75,878 7 27.6 User I/O CPU time 56,207 20.5 read by other session 4,397,330 33,455 8 12.2 User I/O PX Deq Credit: send blkd 31,398 26,576 846 9.7 Other |
Top 5 Events部分包含了一些跟Events（事件）相关的信息。它记录了这期间遇到的等待的总次数，等待所花费的总时间，每次等待的平均时间；这一部分是按照每个Event占总体call time的百分比来进行排序的。
根 据Top 5 Events部分的信息的不同，接下来我们需要检查AWR报告的其他部分，来验证发现的问题或者做定量分析。等待事件需要根据报告期的持续时间和当时数据 库中的并发用户数进行评估。如：10分钟内1000万次的等待事件比10个小时内的1000万等待更有问题；10个用户引起的1000万次的等待事件比 10,000个用户引起的相同的等待要更有问题。
就像上面的例子，将近60%的时间是在等待IO相关的事件。
- 事件"db file scattered read"一般表明正在做由全表扫描或者index fast full scan引起的多块读。
- 事件"db file sequential read"一般是由不能做多块读的操作引起的单块读（如读索引）
其他20%的时间是花在使用或等待CPU time上。过高的CPU使用经常是性能不佳的SQL引起的（或者这些SQL有可能用更少的资源完成同样的操作）；对于这样的SQL，过多的IO操作也是一个症状。关于CPU使用方面，我们会在之后讨论。
