常见问题:如何使用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花费时间最多的等待事件，如下：

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使用方面，我们会在之后讨论。

在以上基础上，我们将调查是否这个等待事件是有问题的。若有问题，解决它；若是正常的，检查下个等待事件。

过多的IO相关的等待一般会有两个主要的原因：

• 数据库做了太多的读操作
• 每次的IO读操作都很慢

Top 5 Events部分的显示的信息会帮助我们检查：

• 是否数据库做了大量的读操作：
  上面的图显示了在这段时间里两类读操作都分别大于1000万，这些操作是否过多取决于报告的时间是1小时或1分钟。我们可以检查AWR报告的elapsed time
  如果这些读操作确实是太多了，接下来我们需要检查AWR报告中 部分的信息，因为读操作都是由SQL语句发起的。

• 是否是每次的IO读操作都很慢：

  上面的图显示了在这段时间里两类读操作平均的等待时间是小于8ms的

  至于8ms是快还是慢取决于底层的硬件设备；一般来讲小于20ms的都可以认为是可以接受的。

  我们还可以在AWR报告"Tablespace IO Stats"部分得到更详细的信息

  Tablespace IO Stats DB/Inst: VMWREP/VMWREP Snaps: 1-15 -> ordered by IOs (Reads + Writes) desc Tablespace ------------------------------ Av Av Av Av Buffer Av Buf Reads Reads/s Rd(ms) Blks/Rd Writes Writes/s Waits Wt(ms) -------------- ------- ------ ------- ------------ -------- ---------- ------ TS_TX_DATA 14,246,367 283 7.6 4.6 145,263,880 2,883 3,844,161 8.3 USER 204,834 4 10.7 1.0 17,849,021 354 15,249 9.8 UNDOTS1 19,725 0 3.0 1.0 10,064,086 200 1,964 4.9 AE_TS 4,287,567 85 5.4 6.7 932 0 465,793 3.7 TEMP 2,022,883 40 0.0 5.8 878,049 17 0 0.0 UNDOTS3 1,310,493 26 4.6 1.0 941,675 19 43 0.0 TS_TX_IDX 1,884,478 37 7.3 1.0 23,695 0 73,703 8.3 >SYSAUX 346,094 7 5.6 3.9 112,744 2 0 0.0 SYSTEM 101,771 2 7.9 3.5 25,098 0 653 2.7

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

  Tablespace IO Stats                       DB/Inst: VMWREP/VMWREP  Snaps: 1-15 -> ordered by IOs (Reads + Writes) desc Tablespace ------------------------------               Av      Av     Av                       Av     Buffer Av Buf       Reads Reads/s Rd(ms) Blks/Rd       Writes Writes/s      Waits Wt(ms) -------------- ------- ------ ------- ------------ -------- ---------- ------ TS_TX_DATA 14,246,367     283    7.6     4.6  145,263,880    2,883  3,844,161    8.3 USER     204,834       4   10.7     1.0   17,849,021      354     15,249    9.8 UNDOTS1      19,725       0    3.0     1.0   10,064,086      200      1,964    4.9 AE_TS   4,287,567      85    5.4     6.7          932        0    465,793    3.7 TEMP   2,022,883      40    0.0     5.8      878,049       17          0    0.0 UNDOTS3   1,310,493      26    4.6     1.0      941,675       19         43    0.0 TS_TX_IDX   1,884,478      37    7.3     1.0       23,695        0     73,703    8.3 >SYSAUX     346,094       7    5.6     3.9      112,744        2          0    0.0 SYSTEM    101,771       2    7.9     3.5       25,098        0        653    2.7

如上图，我们关心Av Rd(ms)的指标。如果它高于20ms并且同时有很多读操作的，我们可能要开始从OS的角度调查是否有潜在的IO问题。

注：对于一些比较空闲的tablespace/files,我们可能会得到一个比较大的Av Rd(ms)值；对于这样的情况，我们应该忽略这样的tablespace/files;因为这个很大的值可能是由于硬盘自旋(spin)引起的，没有太大的参考意义。比如对
于一个有1000万次读操作而且很慢的系统，引起问题的基本不可能是一个只有10次read的tablespace/file

以下的文档可以帮助我们进一步调查IO方面的问题：

Document 223117.1 Troubleshooting I/O-related waits

虽 然高"db file scattered read"和"db file sequential read"等待可以是I / O相关的问题，但是很多时候这些等待也可能是正常的；实际上，对一个已经性能很好的数据库系统，这些等待事件往往在top 5等待事件里，因为这意味着您的数据库没有那些真正的“问题”。

诀窍是能够评估引起这些等待的语句是否使用了最优的访问路径。如果"db file scattered read"比较高，那么相关的SQL语句可能使用了全表扫描而没有使用索引（也许是没有创建索引，也许是没有合适的索引）；相应的，如果"db file sequential read"过多，则表明也许是这些SQL语句使用了selectivity不高的索引从而导致访问了过多不必要的索引块或者使用了错误的索引。这些等待可 能说明SQL语句的执行计划不是最优的。

接下来就需要通过AWR来检查这些top SQL是否可以进一步的调优，我们可以查看AWR报告中SQL Statistics的部分.上面的例子显示了20%的时间花在了等待或者使用CPU上，我们也需要检查 SQL statistics 部分来进一步的分析。

需要注意，接下来的分析步骤取决于我们在TOP 5部分的发现。在上面的例子里，3个top wait event表明问题可能与SQL语句执行计划不好有关，所以接下来我们要去分析"SQL Statistics"部分。

同样的，因为我们并没有看到latch相关的等待，latch在我们这个例子里并没有引发严重的性能问题；那么我们接下来就完全不需要分析latch相关的信息。

一 般来讲，如果数据库性能很慢，TOP 5等待事件里"CPU"， "db file sequential read" 和"db file scattered read" 比较明显（不管它们之间的顺序如何），我们总是需要检查Top SQL (by logical and physical reads)部分；调用SQL Tuning Advisor或者手工调优这些SQL来确保它们是有效率的运行。

SQL Statistics

AWR包含了一些不同的SQL统计值：

根据Top 5 部分的Top Wait Event不同，我们需要检查不同的SQL statistic。

后续精彩内容已被站长无情隐藏，请输入验证码解锁本文！

验证码：

获取验证码： 请先关注本站微信公众号，然后回复“验证码”，获取验证码。在微信里搜索“AiDBA”或者“dbaup6”或者微信扫描右侧二维码都可以关注本站微信公众号。