Oracle 11g: AWR报告解析步骤

这几天在研究AWR报告，参数不仅多，而且不知所云。今天特来整理一下。

首先介绍一下AWR报告，它是是用于系统级别性能诊断和分析的工具，是系统级别性能问题的首选工具，提供系统设置和体系结构的整体概况。

AWR涉及的数据可谓非常多，常常让人看得眼花缭乱，不知道哪些是重点。本文主要讲一下AWR的分析方法。
在AWR报告分析时应采取自顶向下的视角：先专注于主要部分以识别主要问题，然后使用其他部分以获取详细信息。

Oracle有自带的生成awr报告的工具，位于$ORACLE_HOME/rdbms/admin下：

Awrrpt.sql:单实例的AWR报告

Awrgrpt.sql: RAC的AWR报告

Awrrpti.sql:RAC中可以指定节点的AWR报告

Awrddrpt.sql: 单实例的AWR对比报告

Awrgdrpt.sql: RAC的AWR对比报告

Awrsqrpt.sql: 单个sql的报告

生成AWR报告的注意事项：

1. 对于RAC来说，awrgrpt.sql生成的是rac整体的信息，它是为了对比两个节点而生成的报告，信息比较笼统。如果要看具体的详细信息，可以生成单节点的AWR报告来分析。一般对于RAC，我们生成RAC的AWR报告+各节点单独的AWR报告

2. awrrpt.sql是单实例的AWR报告，对于RAC来说，可以用这个脚本生成当前节点的报告，如果要生成其他节点的报告，需要分别登录来生成。Awrrpti.sql就解决了这个问题，它可以在生成报告时指定节点。

3. 对于AWR报告来说，它的数据是begin_snap和end_snap之间的平均值。因此如果需要分析系统在业务高峰期的性能，最好是生成高峰期每个小时单独的AWR报告。

一般来说，解读AWR报告的步骤顺序为：

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

2.ADDM的主要发现（好像是12c之后新增）

3.负载概览（Load Profile）

4.init.ora参数 (init.ora Parameters )

5.顶级前台等待事件 (Top 10 Foreground Events by Total Wait Time)

6.顶级SQL(SQL Statistics )

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

下面分别介绍：

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

这一部分需要关注数据库的版本，是否是RAC和/或CDB；报告的snap时间范围；同时了解基于core的CPU资源信息，如何将会话数和CPU core结合来检查数据库的连接策略；最后通过DB Time来来获得活动会话的信息。

例如我这个AWR报告是11204 RAC；

报告时间是2020年7.17号的10-11点，这应该是业务高峰期，选取的时间比较合适。

有48个逻辑CPU，24个CPU Cores。Oracle建议每个Core有1-10个会话，也就是说最好有24-240个会话能保证有比较好的性能，这里有700+，比较多了。

Elapsed：快照监控时间，这里取的是1个小时，即60分钟。比较常见的是60分钟，120分钟。

DB Time：不包括Oracle后台进程消耗的时间。即CPU time+ wait time。

该例中，DB time为576.37分钟，共48个逻辑CPU，平均每个CPU耗时576.37/48=12分钟。

CPU利用率=12/60,约为20%，即CPU空闲。如果超过100%说明出现等待。

对于CPU利用率，也可以直接看下面的Instance CPU：

Cursors/Sessions: 这里的begin和end值差不多，是正常的。如果该值变大，说明这个期间cursor有泄漏。

2.ADDM的主要发现

对于ADDM部分，我的版本是11204，没有这一部分，需要单独生成addm报告，该报告生成的脚本也在$ORACLE_HOME/rdbms/admin下。参考Oracle 11g：ADDM报告解析

3.负载概览（Load Profile）

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

这里首先看DB Time 和 DB CPU：

DB time per second是每秒的CPU time(即下面的DB CPU)+ wait time（不包括后台进程消耗的时间），也就是基础信息里面的DB Time/Elapsed(576.37/60).

DB CPUs per second，该示例是9.1个，而共有24个core，说明24个CPU，每秒钟平均才使用9.1个，说明CPU比较空闲。如果超过了CPU cores，则表示CPU是瓶颈。

也就是说DB time Per Second - DB CPU Per Second，即是每秒的等待时间，如果这个差值比较大，说明系统很忙，CPU等待时间过长，性能需要优化。

Logons：表示每秒/每事务登录的次数。

Har parses(SQL):硬解析。硬解析高说明SQL代码重用率不高。每秒最好低于20。

Rollbacks：每秒事务的回滚数。

Transactions：每秒事务数，反映数据库任务繁重与否。参考rollbacks，看出回滚率是不是很高，因为回滚很耗费资源，如果回滚率高，说明数据库有太多无效的操作，需要优化SQL语句。

4.init.ora参数 (init.ora Parameters )

上图中显示了很多开头为下划线的参数（这只是个示例，而不是我真正的报告），注意下划线参数是oracle隐藏参数，仅在oracle售后建议时临时设置，否则应该使用默认值。因为Oracle每个release版本，所有的测试都是基于默认值。如果擅自修改了默认值，可能会出现意料之外的后果。

对于参数设置，RAC的不同节点的配置要保持一致，否则RAC在不同节点的执行计划会有差异，进而导致其他的问题。

特别要注意以下参数：

?db_block_size

?db_file_multiblock_read_count

?cursor_sharing

?open_cursors

?optimizer_*

?parallel_*

?processes

?sessions

特别注意db_block_size,作为数据库操作的最小单位，oracle的默认值是8192（即8k）。它是在创建数据库的时候指定的，Oracle强烈建议使用默认值，对于部分特殊要求需要大的数据块，可以在表空间级别实现，而不是在数据库级别配置。

5.顶级前台等待事件 (Top 10 Foreground Events by Total Wait Time)

要关注消耗最多DB时间的等待时间（%DB Time），其对应的等待事件（Event）以及平均等待时间（Wait Avg）

6.顶级SQL统计资料(SQL Statistics )

这里重点关注SQL ordered by Elapsed Time和SQL ordered by Executions

通过SQL ordered by Elapsed Time，检查最耗时的SQL语句，以及每次执行的平均时间Elapsed Time per Exec，以及通过CPU/IO的百分比推断SQL耗时的可能原因，点击“SQL ID”查看完整的SQL语句。
譬如在本例中，33m0a3u1xndua这一项 %Total: 35.03，占比超过总DB time的10%，建议优化相关SQL，可大幅度提升数据库性能；
同样的6pfvxmb6b12s5 %Total: 17.3，也同样需要优化。
8vjrcu84stptq per Exec (s): 18.29 平均每次执行时间超过10s，OLTP系统最好控制在10s以内，也需要优化。

对于SQL Ordered by CPU time，占比超过总DB CPU的%10，平均消耗CPU超过5s的都要重点关注。

通过SQL ordered by Executions，检查执行次数最多的语句，频繁执行的SQL的单次执行效率要求非常高，细小的波动都可能对整体性能造成很大影响。

另外要关注一下每次执行处理的行数，对于OLTP应用，正常每条SQL语句只处理少量的行；如果在一个批量处理的负载中看到大量的执行，并且每次执行只处理一行甚至更少，那就预示着使用了逐行数据处理，这是很糟糕的——没法充分利用系统资源。

同样的，也可以点击SQL ID查看完整的SQL语句。

目前维护的系统性能都不错，以后遇到了问题再来补充。