Oracle ADDM性能诊断利器及报告解读

性能优化是一个永恒的话题，性能优化也是最具有价值，最值得花费精力深入研究的一个课题，因为资源是有限的，时间是有限的。在Oracle数据库中，随着Oracle功能的不断强大和完善，Oralce数据库在性能方面实现自我诊断及优化的功能也越来智能化，这大大的简花了人工优化的脑力和体力的开销，尤其是借助ADDM自动诊断并给出调整建议。本文主要描述ADDM功能及特性。

一、ADDM的主要功能

ADDM全称是Automatic Database Diagnostic Monitor，是Oracle一个实现性能自我诊断的最佳利器。它依赖于AWR，也就是说ADDM要诊断，必要要有诊断的依据。在Oracle中，这个诊断依据就是Oracle AWR，因为Oracle AWR会定期的收集整个数据库在运行期间的性能统计数据。ADDM可提供单实例以及Oracle RAC数据库级别性能诊断，它主要实现以下功能：

  定期分析AWR数据(默认情况下每小时自动诊断诊断报告)

  诊断性能问题的根本原因

  提供纠正任何问题的建议

  标识系统的非问题区域

ADDM分析特定时间段的性能数据，也就是说需要为ADDM指定快照的范围。ADDM总是分析实例模式指定的实例。对于非Oracle RAC或单实例环境，在实例模式中执行的分析与数据库范围分析相同。如果你使用的是Oracle RAC，ADDM还将分析在数据库模式的整个数据库。ADDM按照DB Time，即数据库时间模型统计自上而下进行分析，将最消耗资源的问题(用占据整个DB Time的百分比排序)列出在首部，并给出建议办法以及理由。所有的诊断结果都按此方式列出。

通过优化后减少DB Time，在相同资源的前提下，使得数据库能够支持的更多用户请求，从而增加吞吐量。

ADDM分析的主要范围：

  CPU瓶颈：Oracle数据库还是其他应用程序导致CPU开销过高？

  内存瓶颈：Oracle数据库的内存结构，如SGA、PGA、和缓冲区高速缓存，足够大吗？

  I/O问题：I/O子系统执行超预期？

  高负载SQL语句：是否有任何SQL语句正在消耗过多的系统资源？

  高负荷的PL/SQL的执行和编译，和高负荷的java使用？

  Oracle RAC问题：全局缓存热块和对象是什么；有任何互连延迟的问题？

  应用程序最优使用Oracle数据库：如糟糕的连接管理，过度解析析，或应用程序级锁争的问题吗？

  数据库配置问题：是否有不正确的日志文件大小，归档问题，过多的检查点，或未经优化的参数设置？

  并发问题：是否存在缓冲区忙问题？

  热对象和顶级SQL的各种问题领域

三、ADDM逻辑结构图及诊断方法

1、逻辑结构

默认情况下，Oracle数据库服务器从SGA每60分钟自动收集统计信息，并以快照的形式将其存储在自动工作负载信息库（AWR）。这些快照存储在磁盘和类似于statspack快照。然而，它们含有比statspack快照更精确的信息。此外，ADDM被计划为自动运行，主动侦测每一个数据库实例。每一次拍摄快照，ADDM触发执行相应的最后两个快照周期进行分析。这种方法在数据库产生重大异常前，主动监测实例，并检测瓶颈，每个ADDM分析的结果存储在自动工作负载信息库，也可以通过OEM进行管理。

注：虽然ADDM分析Oracle数据库性能的最后两个快照定义的时期，也可以手动调用ADDM分析任何两个时间间隔快照。

2、ADDM与Database Time

数据库时间(Database Time)定义为在数据库中处理用户请求所花费的时间的总和。图中上半部分描述了单个用户提交请求的简单场景。用户的响应时间是发送请求的瞬间和接收响应的瞬间之间的时间间隔。该用户请求所涉及的数据库时间仅是该用户在数据库中所花费的响应时间的一部分。

图中下半部分描述的数据库时间，是多个用户时间之和，即每个用户正在执行一系列操作，导致对数据库产生一系列请求。图中可以看出，数据库时间与用户请求的数量和持续时间成正比，并且可以高于或低于相应的自然时间（经过的时间）。使用数据库时间作为度量，可以测量数据库的任何实体的性能影响。例如，尺寸较小的缓冲区高速缓存的性能影响将作为在执行其缓冲区缓存较大时可能避免的其他I/O请求所花费的总数据库时间。数据库时间只是衡量数据库服务器完成的工作量。 数据库时间消耗的速率是数据库负载平均值，以数据库时间每秒计算。 ADDM的目标是减少在给定工作负载上花费的数据库时间，这类似于耗费较少的能量来执行相同的任务。

3、ADDM诊断方法

 
识别最大数据库时间开销的组件，并优化该组件，即可获得最大收益。也就是ADDM可以量化性能瓶颈。自动性能调优的第一步是正确识别性能问题的根本原因。只有当正确识别性能问题的根本原因时，才有可能探索有效的调整建议来解决或优化这个问题。

ADDM基于两个时间维度来查看数据库时间开销： 
a、查看在处理用户请求的各个阶段花费的数据库时间。此维度包括诸如“连接到数据库”，“优化SQL语句”和“执行SQL语句”之类等。 
b、查看使用或等待用于处理用户请求的各种数据库资源所花费的数据库时间。在此维度中考虑的数据库资源包括硬件资源（如CPU和I / O设备）以及软件资源（如数据库锁和应用程序锁）。

为了执行自动诊断，ADDM会查看在这两个维度下，在每个类别中花费的数据库时间，然后演练到消耗大量数据库时间的类别。可以使用DBTime-graph来表示此二维向下钻取过程。 
性能问题通常会将数据库时间分布在一个维度的多个类别中，而不是另一个维度。例如，CPU容量不足的数据库会降低处理用户请求的所有阶段，这些都是ADDM分析的第一个维度。然而，从第二个维度来看，影响数据库的最佳性能问题是CPU容量不足。确定数据库时间消耗的二维视图给ADDM在缩小更重要的性能问题方面做出了非常好的判断。

三、ADDM诊断结果

ADDM在诊断问题后，并建议可能的解决方案。ADDM分析结果表示为一组一组的研究成果。每个ADDM研究结果包括下列类型之一：

  问题发现：哪些问题导致了过高的DB Time 占用

  建议对象：列出需要调整的对象

  行为理由：列出这些对象的行为以及调整的理由

建议的类型通常包括：

  硬件更改：添加CPU或更改I/O子系统配置

  数据库配置：更改初始化参数设置

  模式的变化：哈希分区表或索引，或使用自动段空间管理（ASSM）

  应用程序更改：使用序列的缓存选项或使用绑定变量

  使用其他顾问：在高负载SQL上运行SQL调优顾问或在热对象上运行段顾问

建议的列表可以包含各种选择来解决同样的问题；你不必应用所有的建议来解决特定的问题。每个建议有一个好处，这是一个估计的DB时间的一部分，可以节省，如果建议实施。建议包括行动和理由。您必须应用推荐的所有操作以获得估计的效益。

四、配置ADDM

要使用ADDM，两个重要的参数应进行正确的配置。

  statistics_level：该参数建议设置为TYPICAL

  control_management_pack_access：该参数建议设置为DIAGNOSTIC+TUNING，及诊断和优化包都被使用。

SQL> show parameter statistics_level;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
statistics_level                     string      TYPICAL
SQL> show parameter control_management_pack_access;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
control_management_pack_access       string      DIAGNOSTIC+TUNING

五、生成ADDM报告

--RAC环境下生成指定实例的addm报告使用addmrpti.sql脚本
--下面是单实例下生产addm
SQL> @?/rdbms/admin/addmrpt.sql
Current Instance
~~~~~~~~~~~~~~~~

   DB Id    DB Name      Inst Num Instance
----------- ------------ -------- ------------
   42938845 ORA11G              1 ora11g

Instances in this Workload Repository schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   DB Id     Inst Num DB Name      Instance     Host
------------ -------- ------------ ------------ ------------
* 42938845          1 ORA11G       ora11g       ydq05

Specify the Begin and End Snapshot Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enter value for begin_snap: 85
Begin Snapshot Id specified: 85

Enter value for end_snap: 90
End   Snapshot Id specified: 90

-- Author : Leshami
-- Blog   : http://blog.csdn.net/leshami
-- QQ     : 645746311

Specify the Report Name
~~~~~~~~~~~~~~~~~~~~~~~
The default report file name is addmrpt_1_85_90.txt.  To use this name,
press <return> to continue, otherwise enter an alternative.

Enter value for report_name:

Using the report name addmrpt_1_85_90.txt                                               

六、分析ADDM报告

• 报告头部

          ADDM Report for Task 'TASK_552'
          -------------------------------

Analysis Period
---------------
AWR snapshot range from 85 to 90.
Time period starts at 24-APR-17 01.00.12 PM
Time period ends at 24-APR-17 06.00.17 PM

--以上部分为分析的时间范围，用于限定特定的时间范围有助于诊断特定故障
--本addm报告的时间周期为24-APR-17 01.00.12 PM - 24-APR-17 06.00.17 PM

Analysis Target
---------------
Database 'ORA11G' with DB ID 42938845.
Database version 11.2.0.3.0.
ADDM performed an analysis of instance ora11g, numbered 1 and hosted at
ydq05.

--以上信息为数据库的版本，库名，实例等信息

Activity During the Analysis Period
-----------------------------------
Total database time was 73757 seconds.
The average number of active sessions was 4.1.

--以上部分为分析期间的总的数据库耗用时间以及每个会话的平均时间
--当前分析的期间内，自然流逝的时间为5*3600=18000<<DB time(73757)，数据库异常繁忙
--每秒平均的活动会话数位4.1个

Summary of Findings
-------------------
   Description                Active Sessions      Recommendations
                              Percent of Activity
   -------------------------  -------------------  ---------------
1  Top SQL Statements         2.96 | 72.21         5
2  Free Buffer Waits          2.34 | 57.23         3
3  Buffer Busy - Hot Objects  1.21 | 29.64         5
4  Index Block Split          .21 | 5.19           1
5  Commits and Rollbacks      .12 | 2.98           1

--以上部分是诊断结果的摘要部分，列出重要的诊断结果及百分比，建议条数
--如第一行为TopSQL部分，受影响活动会话数2.96，占据整个DB Time 72.21，，5条建议
--第二行为Free Buffer Waits，受影响活动会话数2.34，占整个DB Time 57.23，3条建议

• 诊断结果及建议部分

--这部分内容主要有多个不同的Finding组成，且每个Finding均包含以下内容：
--1、在Finding标题中列出相应的Findings名称，如TopSQL，或者相关等待事件如Free Buffer Waits
--2、描述受影响的活动会话数，以及占用总活动的百分比
--3、给出优化建议，采取的行动，以及理论依据

Finding 1: Top SQL Statements
Impact is 2.96 active sessions, 72.21% of total activity.
---------------------------------------------------------
SQL statements consuming significant database time were found. These
statements offer a good opportunity for performance improvement.

--上面部分描述了Top SQL影响了2.96个活动会话，占用总活动数目72.21%
--并且描述通过SQL优化能够提升性能，可能会包含多条SQL

   Recommendation 1: SQL Tuning
   Estimated benefit is .79 active sessions, 19.17% of total activity.
   -------------------------------------------------------------------
   Action
      Investigate the INSERT statement with SQL_ID "f7rxuxzt64k87" for
      possible performance improvements. You can supplement the information
      given here with an ASH report for this SQL_ID.
      Related Object
         SQL statement with SQL_ID f7rxuxzt64k87.
         INSERT INTO ORDER_ITEMS ( ORDER_ID, LINE_ITEM_ID, PRODUCT_ID,
         UNIT_PRICE, QUANTITY, GIFT_WRAP, CONDITION, ESTIMATED_DELIVERY )
         VALUES ( :B4 , :B3 , :B2 , :B1 , 1, 'None', 'New', (SYSDATE + 3) )
   Rationale
      The SQL spent only 0% of its database time on CPU, I/O and Cluster
      waits. Therefore, the SQL Tuning Advisor is not applicable in this case.
      Look at performance data for the SQL to find potential improvements.
   Rationale
      Database time for this SQL was divided as follows: 100% for SQL
      execution, 0% for parsing, 0% for PL/SQL execution and 0% for Java
      execution.
      -- 此SQL数据库时间被分割为SQL 执行占 100%, 语法分析占 0%,
      -- PL/SQL执行占0%, Java执行占0%，也就是全部为执行时间，其他部分难以优化

   Rationale
      SQL statement with SQL_ID "f7rxuxzt64k87" was executed 55962 times and
      had an average elapsed time of 0.25 seconds.
   Rationale
      Waiting for event "free buffer waits" in wait class "Configuration"
      accounted for 43% of the database time spent in processing the SQL
      statement with SQL_ID "f7rxuxzt64k87".
   Rationale
      Waiting for event "write complete waits" in wait class "Configuration"
      accounted for 25% of the database time spent in processing the SQL
      statement with SQL_ID "f7rxuxzt64k87".
   Rationale
      Waiting for event "buffer busy waits" in wait class "Concurrency"
      accounted for 23% of the database time spent in processing the SQL
      statement with SQL_ID "f7rxuxzt64k87".
   Rationale
      Top level calls to execute the PL/SQL statement with SQL_ID
      "0w2qpuc6u2zsp" are responsible for 100% of the database time spent on
      the INSERT statement with SQL_ID "f7rxuxzt64k87".
      Related Object
         SQL statement with SQL_ID 0w2qpuc6u2zsp.
         BEGIN :1 := orderentry.neworder(:2 ,:3 ,:4 ); END;

    --上面是针对insert SQL语句(SQL_ID为f7rxuxzt64k87)给出的一些调整建议
    --包含完整的SQL语句，执行的次数，以及执行的平均时间
    --同时也给出了该SQL相关的等待事件，如free buffer waits,write complete waits
    --最后还给出了一个顶级的调用为一个包调用了该SQL语句
    --从上面的描述来看，SQL改进的余地很小，可以通过减少等待事件等待时间来改善

Finding 2: Free Buffer Waits
Impact is 2.34 active sessions, 57.23% of total activity.
---------------------------------------------------------
Database writers (DBWR) were unable to keep up with the demand for free
buffers.

--上面的部分描述了第二个诊断结果，为Free Buffer Waits等待事件
--DBWR无法跟上空闲缓冲区的需求，也就是说DBWR太慢，脏数据服务及时写出到数据文件

   Recommendation 1: Database Configuration
   Estimated benefit is 2.34 active sessions, 57.23% of total activity.
   --------------------------------------------------------------------
   Action
      Consider increasing the number of database writers (DBWR) by setting the
      parameter "db_writer_processes". Also consider if asynchronous I/O is
      appropriate for your architecture.
   Rationale
      The value of parameter "db_writer_processes" was "1" during the analysis
      period.
   Rationale
      The value of parameter "disk_asynch_io" was "TRUE" during the analysis
      period.

   --建议采取的行动是调整db_writer_processes参数值，加快写入
   --建议调查参数磁盘异步IO参数，disk_asynch_io

   Recommendation 2: Host Configuration
   Estimated benefit is 2.34 active sessions, 57.23% of total activity.
   --------------------------------------------------------------------
   Action
      Investigate the I/O subsystem's write performance.
   Rationale
      During the analysis period, the average data files' I/O throughput was
      663 K per second for reads and 237 K per second for writes. The average
      response time for single block reads was 0.02 milliseconds.

   --建议调查I/O子系统写入性能，在分析诊断期间，平均的I/O吞吐为663k/读，273k/写
   --单块读的平均时间为0.02毫秒

   Recommendation 3: Application Analysis
   Estimated benefit is 2.34 active sessions, 57.23% of total activity.
   --------------------------------------------------------------------
   Action
      Investigate application logic for possible use of direct path inserts as
      an alternative for multiple INSERT operations.

   Symptoms That Led to the Finding:
   ---------------------------------
      Wait class "Configuration" was consuming significant database time.
      Impact is 2.41 active sessions, 58.74% of total activity.

   --第三个建议是使用直接路径插入方式替换现有的走缓冲区的方式

Finding 3: Buffer Busy - Hot Objects
Impact is 1.21 active sessions, 29.64% of total activity.
---------------------------------------------------------
Read and write contention on database blocks was consuming significant
database time.

--第3个诊断结果为存在热对象，数据库热块读写消耗了大量数据库时间

   Recommendation 1: Schema Changes
   Estimated benefit is .5 active sessions, 12.18% of total activity.
   ------------------------------------------------------------------
   Action
      Consider partitioning the TABLE "SOE.LOGON" with object ID 77203 in a
      manner that will evenly distribute concurrent DML across multiple
      partitions.
      Related Object
         Database object with ID 77203.
   Rationale
      The INSERT statement with SQL_ID "gzhkw1qu6fwxm" was significantly
      affected by "buffer busy" waits.
      Related Object
         SQL statement with SQL_ID gzhkw1qu6fwxm.
         INSERT INTO LOGON (LOGON_ID,CUSTOMER_ID, LOGON_DATE) VALUES
         (LOGON_SEQ.NEXTVAL, :B2 , :B1 )

   --上面的建议是建议将logon表进行分区，以实现离散IO

   Recommendation 2: Schema Changes
   Estimated benefit is .2 active sessions, 4.77% of total activity.
   -----------------------------------------------------------------
   Action
      Consider partitioning the INDEX "SOE.CARDDETAILS_CUST_IX" with object ID
      77261 in a manner that will evenly distribute concurrent DML across
      multiple partitions.
      Related Object
         Database object with ID 77261.
   Rationale
      The INSERT statement with SQL_ID "budtrjayjnvw3" was significantly
      affected by "buffer busy" waits.
      Related Object
         SQL statement with SQL_ID budtrjayjnvw3.
         INSERT INTO CARD_DETAILS ( CARD_ID, CUSTOMER_ID, CARD_TYPE,
         CARD_NUMBER, EXPIRY_DATE, IS_VALID, SECURITY_CODE ) VALUES ( :B2 ,
         :B1 , 'Visa(Debit)', FLOOR(DBMS_RANDOM.VALUE(1111111111,
         9999999999)), TRUNC(SYSDATE + (DBMS_RANDOM.VALUE(365, 1460))), 'Y',
         FLOOR(DBMS_RANDOM.VALUE(1111, 9999)) )

   --这个建议是对索引进行分区，以实现离散IO

--其他部分省略

• 其他信息

          Additional Information
          ----------------------

Miscellaneous Information
-------------------------
Wait class "Application" was not consuming significant database time.
CPU was not a bottleneck for the instance.
Wait class "Network" was not consuming significant database time.
Wait class "User I/O" was not consuming significant database time.
Session connect and disconnect calls were not consuming significant database
time.
Hard parsing of SQL statements was not consuming significant database time.

The database's maintenance windows were active during 100% of the analysis
period.

--其它部分是一些额外的信息，用于说明哪些类别没有消耗大量的数据库时间。
zhuan: http://blog.csdn.net/leshami/article/details/70859672