常见问题：如何使用Oracle AWR报告来诊断数据库性能问题

Copyright (c) 2021, Oracle. All rights reserved. Oracle Confidential.常⻅问题:如何使用AWR报告来诊断数据库性能问题 (Doc ID 1523048.1)文档内容目标 最佳实践 如何主动避免问题发生及做好诊断信息的收集 提出问题、获取帮助并分享您的经验解决方案 Interpretation Top 5 Timed Events SQL Statistics 分析： Other SQL Statistic Sections Waits for 'Cursor: mutex/pin' Load Profile Instance Efficiency Latch Activity 值得注意的wait events CPU time events Analysis: 其他潜在的CPU相关的问题： 检查是否有其他等待事件与高CPU 事件同时出现 数据库以外的CPU使用率过高 诊断CPU使用率 'Log file sync' waits Buffer busy waits 诊断其他问题 使用ADDM的报告 其他的AWR参考文章 Statspack参考适用于:Oracle Database - Enterprise Edition - 版本 10.2.0.1 和更高版本Oracle Database Exadata Cloud Machine - 版本 N/A 和更高版本 Oracle Cloud Infrastructure - Database Service - 版本 N/A 和更高版本 Oracle Database Cloud Exadata Service - 版本 N/A 和更高版本 Oracle Database Exadata Express Cloud Service - 版本 N/A 和更高版本 本文档所含信息适用于所有平台目标本文旨在提供如何解释跟数据库性能问题息息相关的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/cd/E16655_01/license.121/e17614/editions.htm#DBLIC116最佳实践如何主动避免问题发生及做好诊断信息的收集有些问题是无法预⻅的，但大部分其它的问题如果及早发现一些征兆其实是可以避免的。同时，如果问题确实发生了，那么收集问题发生时的信息就非常重要。有关于如何主动避免问题及诊断信息的收集，请参⻅：Document 1482811.1 Best Practices: Proactively Avoiding Database and Query Performance Issues Document 1477599.1 Best Practices Around Data Collection For Performance Issues 提出问题、获取帮助并分享您的经验您想要与其他 Oracle 客户、Oracle 员工及业内专家深入探讨吗？ Click here to join the discussion where you can ask questions, get help from others, and share your experiences with this specific article. 点击这里访问 My Oracle Support Community 数据库性能优化⻚，在这里您可以提出问题、获取他人的帮助并分享您的经验。解决方案对于数据库整体的性能问题，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 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使用方面，我们会在之后讨论。 在以上基础上，我们将调查是否这个等待事件是有问题的。若有问题，解决它；若是正常的，检查下个等待事件。过多的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