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

SQL> select 'Leshami' Author,'http://blog.csdn.net/leshami' Blog,
  2  '645746311' QQ from dual;

AUTHOR  BLOG                         QQ
------- ---------------------------- ---------
Leshami http://blog.csdn.net/leshami 645746311

五、生成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.

--其它部分是一些额外的信息,用于说明哪些类别没有消耗大量的数据库时间。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏维C果糖

史上最简单的 MySQL 教程(二)「关系型数据库」

关系型数据库,是一种建立在关系模型(数学模型)上的数据库。

4309
来自专栏Hadoop数据仓库

HAWQ技术解析(十二) —— 查询优化

        即便对SELECT等数据库查询语句已经很熟悉了,但HAWQ里的查询有其自己的特点,还是需要研究一下。 一、HAWQ的查询处理流程        ...

6066
来自专栏PPV课数据科学社区

SQL and R

R平台及编程语言支持浩大的数据科学技术,他拥有几十年的的历史和超过7000个包,这挂在CRAN的包纷杂的让你无法决定从哪里入手。R-Basics和Visua...

31910
来自专栏数据和云

Oracle 12.2新特性掌上手册 - 第七卷 Big Data and Data Warehousing

编辑手记:也许Oracle 12.2在内核上的智能改进只能让你眼前一亮,那今天基于Big Data和数据仓库的性能优化增强则会让你伸手触Oracle的强大灵魂。...

3027
来自专栏码神联盟

碎片化 | 第四阶段-48-hibernate概述和配置-视频

本套视频从Java基础到架构模式以及AI算法,整体视频以“碎片化”学习的模式,提供给大家 ,并配备实际项目为案例,让大家在坐车、吃饭、午休、蹲坑的时候,都可以学...

3306
来自专栏数据和云

深入剖析:关于cache buffers chains的经典案例处理详解

? 卢文星 目前就职云和恩墨,南区交付工程师,有超过8年超大型数据库管理经验,擅长Oracle数据库性能优化与升级迁移。 作者介绍 故障现象 某省税务核心业务...

2786
来自专栏性能与架构

Kafka 流数据 SQL 引擎 -- KSQL

KSQL 是什么? KSQL 是一个 Kafka 的 SQL 引擎,可以让我们在流数据上持续执行 SQL 查询 例如,有一个用户点击流的topic,和一个可持续...

4276
来自专栏数据和云

Oracle数据库中最让人匪夷所思的十大问题盘点

数据的世界无奇不有,常常会遇到一些超出常识之外的故障的发生。这就要求广大的DBA要深入了解数据库的内部机制,面对一些奇葩的故障或者问题能够拨开迷雾找到真相。今...

3005
来自专栏草根专栏

Entity Framework Core 2.1,添加种子数据

EFCore 2.1出来有一段时间了,里面的新功能还没怎么用,今天研究下如何使用EF Core 2.1添加种子数据。

1481
来自专栏更流畅、简洁的软件开发方式

利用虚拟硬盘(把内存当作硬盘)来提高数据库的效率(目前只针对SQL Server 2000)可以提高很多

      虚拟硬盘:就是把内存当作硬盘来用,比如有2G的内存,那么可以拿出来1G的内存当作硬盘来用。       自从知道了“虚拟硬盘”这个东东,我就一直在想...

4815

扫码关注云+社区

领取腾讯云代金券