How to read Oracle AWR Report

RWP团队谈性能优化之大开眼界篇（四）AWR报告实例分析

本讲首先介绍了用于数据库诊断的各种工具汇总，强调AWR报告是用于系统级别性能诊断和分析的工具。AWR报告是系统级别性能问题的首选工具，提供系统设置和体系结构的整体概况。分析时采取自顶向下的视角：先专注于主要部分以识别主要问题，然后使用其他部分以获取详细信息, 然后简要介绍了AWR包括的各种报告，比如：单实例和多实例的报告，单实例和多实例的对比报告，CDB/PDB级别有不同的报告，以及单个SQL的AWR报告等。在不同的场景下应该选择合适的报告来分析

接下来给出了RWP 推荐的分析AWR报告的顺序：

1.报告开头的系统基础信息

2.ADDM的主要发现

3.负载概览（Load Profile）

4.init.ora参数

5.顶级前台等待事件

6.顶级SQL

7.根据上述步骤里发现的可疑问题，再通过其他部分获取特定的详细信息以进行分析

针对这个顺序中的每个步骤，分别讲解了需要查看和分析的重点

1. 对于报告开头的系统基础信息，需要关注数据库的版本，是否是RAC和/或CDB；同时了解基于core的CPU资源信息，如何将会话数和CPU core结合来检查数据库的连接策略；最后通过DB Time来来获得活动会话的信息

2.对于ADDM的主要发现部分，通过数据库给出的主要发现可以大致定位系统存在问题的可能方面，从而为后续的分析指明方向

3.在负载概览（Load Profile）部分，通过DB时间和CPU时间可以对数据库是消耗较多CPU还是在各种等待上有个直观了解。而解析（特别是硬解析）和用户登陆信息可以对应用的实现有个初步了解，并提前掌握系统可能存在的问题

4.在init.ora参数部分，需要重点关注下划线参数和事件的设置，这些参数应该仅在Oracle售后建议时临时设置；所有参数应该尽量使用默认值，在不同节点上的配置也应该保持一致。设置过多的参数可能会对系统带来不可预知的表现。Oracle的所有测试都是基于默认值的

需要重点关注的init.ora参数包括：

•db_block_size

•db_file_multiblock_read_count

•cursor_sharing

•open_cursors

•optimizer_*

•parallel_*

•processes

•sessions

5.在顶级前台等待事件部分，需要重点关注消耗最多DB时间的等待事件，包括等待的总时长和平均等待时长。对于IO类型的平均等待时长，可以作为IO延迟以简单估算IO是否出现问题。在新的版本里面，这个部分显示顶级的前十个等待事件，而在之前的版本中只显示前五个

6.在顶级SQL中，会根据多个维度排序展示处于前几位的SQL。应该根据前面的部分观察到的现象有针对性的查看某些维度的顶级SQL

在“SQL ordered by Elapsed

Time”部分，可以检查最耗时的SQL语句，检查SQL语句平均每次长，以及通过CPU/IO的百分比推断SQL耗时的可能原因

“SQL ordered by Executions”也是值得关注的部分，应该关注执行次数多的SQL。频繁执行的SQL的单次执行效率要求非常高，细小的波动都可能对整体性能造成很大影响。另外要关注一下每次执行处理的行数，对于OLTP应用，正常每条SQL语句只处理少量的行；如果在一个批量处理的负载中看到大量的执行，并且每次执行只处理一行甚至更少，那就预示着使用了逐行数据处理，这是很糟糕的——没法充分利用系统资源

在SQL语句部分，如果看到很多类似SYS_B_xxx的绑定变量，意味着说明cursor_sharing 设置成了similar 或者force，可能应用没有合理使用绑定变量来解决硬解析问题

接下来以一个来自在线交易系统的实际AWR为例，按照上述方法进行深入分析，逐步研究并探讨AWR所能带来的性能诊断信息

在AWR 开头部分，可以看到系统已经过载了，会话数超过 core数的100倍，而且会话数还在增长，可能存在连接泄漏和动态连接池的问题。另外每个会话的平均游标数在增加，可能存在游标泄漏的问题

而在负载概览部分，可以看到系统大约有260 平均活动会话，其中40 个会话使用CPU，但是系统只有32个core，说明达到系统CPU的限制。在这个部分还能看到系统每秒钟10次数据库登陆，对于一个稳定的系统来说这个值太高了，也说明了可能存在会话泄漏和动态连接池的问题。另外还能发现有70%的用户会话是回滚，可能代码逻辑存在问题

在初始化参数部分，可以看到系统修改了大量的参数，包括很多下划线参数。值得指出的是其中的Db_block_size=16384，默认情况下这个参数是8k。Oracle的数据库测试都是基于8k完成的，在非特殊情况下都应该使用默认的db_block_size设置。对于部分特殊要求需要大的数据块，可以在表空间级别实现，而不是在数据库级别配置

在初始化参数部分可以看到修改的参数还包括优化器相关的参数（Optimizer_开头的参数），除非是Oracle售后的特别建议，否则强烈建议将优化器相关的参数保留默认值，这样可以避免带来不可预知的执行计划的问题

在顶级等待事件部分，可以看到Concurrency类型的等待消耗了超过 35% 的数据库时间，造成这种类型的等待的原因一般是CPU过载；另外还可以看到行锁等待占用 18% 的数据库时间，需要评估业务逻辑的实现

在顶级SQL部分，响应时间排第一位的是一条SELECT FOR UPDATE语句，它占用 12% 的数据库时间，总共两百万次执行，平均每次执行时间 0.1 秒。同时参考Segments by Row Lock Waits部分可以发现，40% 的行级锁发生在该SQL对应的对象上

在顶级SQL部分接下来的两条语句

调用DBMS_APPLICATION_INFO用于应用模块标识，消耗 14%

的数据库时间，分别执行两千六百万次。对应用模块进行标识是一件好事，但是，从Oracle 10g开始就不需要再调用这个接口了，可以通过OCI 或Java 的参数来代替

接下来对从学员处收到的六个AWR报告依次进行了分析

第一个AWR是要求分析CPU的使用情况，说是AWR里看到的CPU使用信息和在操作系统看到的不一致。但是通过AWR的开始部分看到该AWR来自于三年半以前。在拿到一个AWR的时候，首先需要关注该AWR是否对应自己需要分析的时间段。

第二个AWR要求分析的是两个库之间数据同步的问题。既然从A库到B库，那应该分别提供同一个时间A和B库的AWR，而实际提供的只是CDB的报告。CDB的报告包括CDB本身以及其中的所有PDB的负载信息。如果A和B是这个CDB中的两个PDB，那应该分别生成PDB级别的AWR。AWR的时间跨度是1小时，而问题描述是分钟以内的操作，应该在测试的前后手工创建snapshot，生成更短时间短的AWR来做分析

两个CDB的AWR的ADDM和顶级活动部分都有明确提示有数据库登陆的问题。“Failed Logon

Delay”意味着登陆密码错误，应该解决一直使用错误密码尝试登陆数据库的应用

第三个AWR是要求分析故障期间的业务卡顿的问题。通过AWR看到数据库的版本是10.2.0.5.0，10g版本的AWR的信息比后续版本的少很多，而且10g已经不再被Oracle支持了，应该升级到更新的版本。另外，既然是出现故障，那应该同时提供没有故障的AWR以做对比分析，也可以生成AWR的对比报告。通过分析AWR，可以看到解析占用了大量的时间，需要研究应用实现的逻辑，合理使用绑定变量等

第四个AWR分析没有给出具体的分析需求。但是打开文件看到实际上提供的并非Oracle的标准AWR报告。在寻求帮助的时候应该提供标准的AWR，这样才能保证数据的一致性和准确性

第五个AWR分析也没有给出具体的分析需求。提供的只有一个RAC的AWR报告，RAC的Global AWR只提供部分信息，还需要单个的实例的AWR一起做分析。在AWR的ADDM中发现有较严重的数据库连接问题，应该review应用连接到数据库的逻辑，设置合适的连接池策略。另外在顶级等待事件里看到有不常见的latch等待事件，建议检查数据库是否启用了特别的选件，并且通过Oracle的800服务提SR跟进.

第六个AWR是来自于EBS系统，该AWR跨度8小时，时间跨度可能太长。AWR的时间段要包括需要分析的问题发生的时间，并且时间跨度尽量短，AWR看到的是8个小时的平均值。如果确实要分析这个8个小时时间段，那应该再提供每一个小时间隔的AWR

该AWR的init.ora部分看到设置了不少参数，其中_pga_max_size 和 _smm_max_size 的设置看起来是为了解决PGA问题。对于EBS应用，Init.ora参数应该遵循EBS的最佳实践建议来设置。建议参照最佳实践来review所有的参数配置

在顶级等待事件里看到数据库的IO延迟较长，需要评估磁盘阵列的配置是否存在问题。另外在顶级SQL部分看到大量e:CUX:开头的客户自定义模块占用最多的数据库时间，可以进行SQL级别的诊断确定是否能够优化

总结

对于AWR报告：

l 系统级别性能问题的首选工具

l 提供系统设置和体系结构的整体概况

l 分析时采取自顶向下的视角

n 专注于主要部分以识别主要问题

n 使用其他部分以获取详细信息

解读AWR报告的步骤：

1.报告开头的系统基础信息

2.ADDM的主要发现

3.负载概览（Load Profile）

4.init.ora参数

5.顶级前台等待事件

6.顶级SQL

7.根据上述步骤里发现的可疑问题，再通过其他部分获取特定的详细信息以进行分析

AWR报告分析的注意事项：

l 注意时间段，AWR的时间段要包括需要分析的问题发生的时间，并且时间跨度尽量短

l 对于RAC的数据库，需要同时分析Global的和所有单个实例的AWR

l 对于CDB/PDB架构，如果只分析某个PDB的问题，那就应该分析单个PDB的AWR

l 在寻求帮助的时候应该提供标准的AWR，这样才能保证数据的一致性和准确性

l 系统运行稳定的时候，可以收集AWR做为基准，以便出问题的时候将问题AWR与基准进行比较

本次课程回顾就到这里，另外本次课程回看视频已上传至bilibili，视频地址：

https://space.bilibili.com/28628293?spm_id_from=333.788.b_765f7570696e666f.2