性能优化是一个永恒的话题，性能优化也是最具有价值，最值得花费精力深入研究的一个课题，因为资源是有限的，时间是有限的。在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脚本
--下面是单实例下生产
SQL> @?/rdbms/admin/addmrpt.sql
Current Instance
~~~~~~~~~~~~~~~~
DB Id DB Name Inst Num Instance
----------- ------------ -------- ------------
142723844 WXH 1 wxh
Instances in this Workload Repository schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DB Id Inst Num DB Name Instance Host
------------ -------- ------------ ------------ ------------
* 142723844 1 WXH wxh PANACEABJ-00
3
Using 142723844 for database Id
Using 1 for instance number
Specify the number of days of snapshots to choose from
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Entering the number of days (n) will result in the most recent
(n) days of snapshots being listed. Pressing <return> without
specifying a number lists all completed snapshots.
Listing the last 3 days of Completed Snapshots
Snap
Instance DB Name Snap Id Snap Started Level
------------ ------------ --------- ------------------ -----
wxh WXH 95 30 8月 2018 14:22 1
96 30 8月 2018 15:00 1
97 30 8月 2018 16:00 1
98 30 8月 2018 17:00 1
99 31 8月 2018 09:24 1
100 31 8月 2018 10:00 1
101 31 8月 2018 11:00 1
102 31 8月 2018 12:00 1
103 31 8月 2018 13:00 1
104 31 8月 2018 14:00 1
105 31 8月 2018 15:00 1
106 31 8月 2018 16:00 1
107 31 8月 2018 17:00 1
108 31 8月 2018 19:54 1
109 31 8月 2018 21:00 1
110 31 8月 2018 22:00 1
111 01 9月 2018 08:39 1
112 01 9月 2018 10:00 1
113 01 9月 2018 11:00 1
114 01 9月 2018 12:00 1
115 01 9月 2018 13:00 1
116 01 9月 2018 14:00 1
117 01 9月 2018 15:00 1
118 01 9月 2018 16:00 1
119 01 9月 2018 17:00 1
120 01 9月 2018 18:00 1
121 01 9月 2018 19:00 1
122 01 9月 2018 20:00 1
123 01 9月 2018 21:00 1
Specify the Begin and End Snapshot Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
输入 begin_snap 的值: 100
Begin Snapshot Id specified: 100
输入 end_snap 的值: 102
End Snapshot Id specified: 102
Specify the Report Name
~~~~~~~~~~~~~~~~~~~~~~~
The default report file name is addmrpt_1_100_102.txt. To use this name,
press <return> to continue, otherwise enter an alternative.
输入 report_name 的值: TEST7
Using the report name TEST7
Running the ADDM analysis on the specified pair of snapshots ...
Generating the ADDM report for this analysis ...
任务 '任务_217' 的 ADDM 报告
---------------------
分析时段
----
AWR 快照范围从 100 到 102。
时段从 31-8月 -18 10.00.51 上午 开始
时段在 31-8月 -18 12.00.12 下午 结束
分析目标
----
数据库 'WXH' (DB ID 为 142723844)。
数据库版本 11.2.0.1.0。
ADDM 对实例 wxh 执行了分析, 该实例的编号为 1 并运行于 PANACEABJ-003。
分析时段期间的活动
---------
总数据库时间为 15 秒。
活动会话的平均数量为 0。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
没有任何查找结果可以报告。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
附加信息
----
各种信息
----
没有运行 ADDM 的大量数据库活动。
在分析时段的 100% 期间, 数据库的维护窗口是处于活动状态的。
End of Report
Report written to TEST7
SQL>
六、分析ADDM报告
- 报告头部
任务 '任务_13790' 的 ADDM 报告
-----------------------
分析时段
----
AWR 快照范围从 12881 到 12888。
时段从 21-3月 -18 08.00.01 上午 开始
时段在 21-3月 -18 03.00.34 下午 结束
分析目标
----
数据库 'TLPPRD' (DB ID 为 2343497572)。
数据库版本 11.2.0.4.0。
ADDM 对实例 tlpprd 执行了分析, 该实例的编号为 1 并运行于 DP-TLPPRD。
分析时段期间的活动
---------
总数据库时间为 2533 秒。
活动会话的平均数量为 .1。
查找结果概要
------
说明 活动的会话 建议案
活动的百分比
------------- ------ ---
1 顶级 SQL 语句 .09 | 88.895
2 特殊的 "网络" 等待事件 .04 | 43.053
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
查找结果和建议案
--------
查找结果 1: 顶级 SQL 语句
受影响的是 .09 个活动会话, 占总活动的 88.89\%。
-------------------------------
发现 SQL 语句消耗了大量数据库时间。这些语句提供了改善性能的绝佳机会。
建议案 1: SQL 优化
估计的收益为 .06 个活动会话, 占总活动的 57.58\%。
--------------------------------
操作
研究 SELECT 语句 (SQL_ID 为 "asucsbscb1tma"), 确定是否可以改善性能。可以利
用此 SQL_ID 的 ASH
报告来补充此处给出的信息。
相关对象
SQL_ID 为 asucsbscb1tma 的 SQL 语句。
SELECT T.VBELN, T.POSNR, S.NAME1, W.NAME2, U.WERKS, V.LGORT, V.STORE,
U.ARKTX, V.VSART, T.SEND_FLAG, V.CARNO, V.HROOM, V.HTIME, V.HWEIGHT,
V.LOATIM, V.LOADER, T.FLAG, T.KDAUF, S.POSNR_S, V.GROOM, V.GTIME,
V.GWEIGHT, T.MAN, T.OUTTIME, T.FITNO, V.CREATIM, T.FITNUM, T.BATCH,
T.BUNDLE, T.JUDGERESULT, T.STEELGRADE, T.SPEC, T.LENGTH, T.WEIGHT,
T.MATERIAL, W.LFART, '', U.EBELN, U.EBELP, '', V.CREATER, V.CREATIM,
'', '', T.REFLAG, 0, 0, 0, U.LFIMG, T.LINES FROM HP_V_SD_2200_OUTSTO
T LEFT JOIN HP_V_SD_FIT_BODY S ON T.FITNO = S.FITNO AND T.FITNUM =
S.FITNUM LEFT JOIN HP_V_SD_FIT_HEAD V ON T.FITNO = V.FITNO LEFT JOIN
HP_V_SD_DELIVERY_BODY U ON T.VBELN = U.VBELN AND T.POSNR = U.POSNR
LEFT JOIN HP_V_SD_DELIVERY_HEAD W ON T.VBELN = W.VBELN WHERE S.NAME1
LIKE '%高强%' AND TRUNC(T.OUTTIME) >= SYSDATE - 2
操作
从 SQL_ID 为 "asucsbscb1tma" 的 SELECT 语句提取结果时使用更大的提取数组。
相关对象
SQL_ID 为 asucsbscb1tma 的 SQL 语句。
SELECT T.VBELN, T.POSNR, S.NAME1, W.NAME2, U.WERKS, V.LGORT, V.STORE,
U.ARKTX, V.VSART, T.SEND_FLAG, V.CARNO, V.HROOM, V.HTIME, V.HWEIGHT,
V.LOATIM, V.LOADER, T.FLAG, T.KDAUF, S.POSNR_S, V.GROOM, V.GTIME,
V.GWEIGHT, T.MAN, T.OUTTIME, T.FITNO, V.CREATIM, T.FITNUM, T.BATCH,
T.BUNDLE, T.JUDGERESULT, T.STEELGRADE, T.SPEC, T.LENGTH, T.WEIGHT,
T.MATERIAL, W.LFART, '', U.EBELN, U.EBELP, '', V.CREATER, V.CREATIM,
'', '', T.REFLAG, 0, 0, 0, U.LFIMG, T.LINES FROM HP_V_SD_2200_OUTSTO
T LEFT JOIN HP_V_SD_FIT_BODY S ON T.FITNO = S.FITNO AND T.FITNUM =
S.FITNUM LEFT JOIN HP_V_SD_FIT_HEAD V ON T.FITNO = V.FITNO LEFT JOIN
HP_V_SD_DELIVERY_BODY U ON T.VBELN = U.VBELN AND T.POSNR = U.POSNR
LEFT JOIN HP_V_SD_DELIVERY_HEAD W ON T.VBELN = W.VBELN WHERE S.NAME1
LIKE '%高强%' AND TRUNC(T.OUTTIME) >= SYSDATE - 2
原理
SQL 在 CPU, I/O 和集群等待上花费的时间只占其数据库时间的 0%。因此, SQL 优
化指导不适用于这种情况。请查看 SQL
的性能数据以找出可能的改进方法。
原理
此 SQL 的数据库时间由以下部分构成: SQL 执行占 100%, 语法分析占 0%, PL/SQL
执行占 0%, Java 执行占 0%。
原理
SQL_ID 为 "asucsbscb1tma" 的 SQL 语句执行了 84 次, 每次执行平均用时 12 秒
。
原理
等待事件 "SQL*Net message from dblink" (在等待类 "Network" 中) 消耗了数据
库时间的 100%
(该数据库时间为处理具有 SQL_ID "asucsbscb1tma" 的 SQL 语句时所用的时间)。
原理
执行 PL/SQL 语句 (SQL_ID 为 "88y0fsk91zr25") 的顶级调用占数据库时间的 100%
, 该数据库时间是花费在
SELECT 语句 (SQL_ID 为 "asucsbscb1tma") 上的时间。
相关对象
SQL_ID 为 88y0fsk91zr25 的 SQL 语句。
DECLARE job BINARY_INTEGER := :job; next_date DATE := :mydate;
broken BOOLEAN := FALSE; BEGIN p_ygtobxg;
P_TOYGSEND; :mydate := next_date; IF broken THEN :b := 1; ELSE :b :=
0; END IF; END;
建议案 2: SQL 优化
估计的收益为 .02 个活动会话, 占总活动的 17.68\%。
--------------------------------
操作
对 SELECT 语句 (SQL_ID 为 "4sc11bq4xv4pn") 运行 SQL 优化指导。
相关对象
SQL_ID 为 4sc11bq4xv4pn 的 SQL 语句。
SELECT COUNT(*) FROM HP_MM_YGSEND T WHERE T.OUTTIME = :B4 AND
T.LOT_ID = :B3 AND T.LINES = :B2 AND T.ITEM_ID = :B1
原理
SQL 在 CPU, I/O 和集群等待上花费的时间占其数据库时间的 100%。这部分数据库
时间可通过 SQL 优化指导进行改善。
原理
此 SQL 的数据库时间由以下部分构成: SQL 执行占 100%, 语法分析占 0%, PL/SQL
执行占 0%, Java 执行占 0%。
原理
SQL_ID 为 "4sc11bq4xv4pn" 的 SQL 语句执行了 20432 次, 每次执行平均用时 0.0
19 秒。
原理
执行 PL/SQL 语句 (SQL_ID 为 "88y0fsk91zr25") 的顶级调用占数据库时间的 100%
, 该数据库时间是花费在
SELECT 语句 (SQL_ID 为 "4sc11bq4xv4pn") 上的时间。
相关对象
SQL_ID 为 88y0fsk91zr25 的 SQL 语句。
DECLARE job BINARY_INTEGER := :job; next_date DATE := :mydate;
broken BOOLEAN := FALSE; BEGIN p_ygtobxg;
P_TOYGSEND; :mydate := next_date; IF broken THEN :b := 1; ELSE :b :=
0; END IF; END;
建议案 3: SQL 优化
估计的收益为 .01 个活动会话, 占总活动的 5.56\%。
-------------------------------
操作
对 SELECT 语句 (SQL_ID 为 "fw0g1xmhudxdq") 运行 SQL 优化指导。
相关对象
SQL_ID 为 fw0g1xmhudxdq 的 SQL 语句。
select TB.SID as SID, TB.ODO_ID as ODO_ID, TB.ODO_ITEM_ID
as ODO_ITEM_ID, TB.ODO_ITEM_TYPE as ODO_ITEM_TYPE, TB.SO_ID
as SO_ID, TB.SO_ITEM_ID as SO_ITEM_ID,
TB.DISTRIBUTION_CHANNEL as DISTRIBUTION_CHANNEL, TB.DEPT_NAME as
DEPT_NAME, TB.MAT_ID as MAT_ID, TB.LOT_ID as LOT_ID,
TB.FACILITY_ID as FACILITY_ID, TB.FACILITY_DESC as FACILITY_DESC,
TB.WAREHOUSE_ID as WAREHOUSE_ID, TB.WAREHOUSE_DESC as
WAREHOUSE_DESC, TB.SALES_UNIT as SALES_UNIT, TB.SO_ITEM_NAME
as SO_ITEM_NAME, TB.GROSS_WEIGHT as GROSS_WEIGHT,
TB.NET_WEIGHT as NET_WEIGHT, TB.DELIVERY_QTY as DELIVERY_QTY,
TB.MEASURE_UNIT as MEASURE_UNIT, TB.SAP_WAREHOUSE_ID as
SAP_WAREHOUSE_ID, TB.SAP_WAREHOUSE_DESC as SAP_WAREHOUSE_DESC,
TB.SAP_FACILITY_ID as SAP_FACILITY_ID, TB.SAP_FACILITY_DESC as
SAP_FACILITY_DESC, TB.XTEXT1 as XTEXT1, TB.XTEXT2 as XTEXT2,
TB.XTEXT3 as XTEXT3, TB.XTEXT4 as XTEXT4, TB.VERSION as
VERSION, TB.CREATED_BY as CREATED_BY, TB.CREATED_DT as
CREATED_DT, TB.UPDATED_BY as UPDATED_BY, TB.UPDATED_DT as
UPDATED_DT, TB.PLAN_QTY as PLAN_QTY, TB.TRANSIT_QTY as
TRANSIT_QTY, TB.SPLIT_QTY as SPLIT_QTY, TB.SPLIT_SEQ as
SPLIT_SEQ, TB.SPLIT_COUNT as SPLIT_COUNT,
TB.ORIGIN_SYSTEM_NAME as ORIGIN_SYSTEM_NAME, TB.STATUS as
STATUS, TB.EBELN as EBELN, TB.EBELP as EBELP, PB.SOLD_TO
as SOLD_TO, PB.SOLD_TO_DESC as SOLD_TO_DESC, PB.SHIP_TO as
SHIP_TO, PB.SHIP_TO_DESC as SHIP_TO_DESC from
HP_SD_OB_DVY_ORDER_ITEM TB,HP_SD_OB_DVY_ORDER PB where TB.ODO_ID
= PB.ODO_ID and (TB.SPLIT_SEQ=PB.SPLIT_SEQ or TB.SPLIT_SEQ is null)
and TB.ORIGIN_SYSTEM_NAME = PB.ORIGIN_SYSTEM_NAME
and TB.ODO_ID = :1 and
TB.ODO_ITEM_ID = :2
ORDER BY SID DESC
原理
SQL 在 CPU, I/O 和集群等待上花费的时间占其数据库时间的 100%。这部分数据库
时间可通过 SQL 优化指导进行改善。
原理
此 SQL 的数据库时间由以下部分构成: SQL 执行占 100%, 语法分析占 0%, PL/SQL
执行占 0%, Java 执行占 0%。
原理
SQL_ID 为 "fw0g1xmhudxdq" 的 SQL 语句执行了 258 次, 每次执行平均用时 0.4
秒。
建议案 4: SQL 优化
估计的收益为 0 个活动会话, 占总活动的 4.55\%。
-----------------------------
操作
对 SELECT 语句 (SQL_ID 为 "c0xcd2ptjp3sh") 运行 SQL 优化指导。
相关对象
SQL_ID 为 c0xcd2ptjp3sh 的 SQL 语句。
select * from HP_SD_MES_ASSEMBLY_ORDER where flag = '0' and
fitno is not null order by CREATIM asc
原理
SQL 在 CPU, I/O 和集群等待上花费的时间占其数据库时间的 100%。这部分数据库
时间可通过 SQL 优化指导进行改善。
原理
此 SQL 的数据库时间由以下部分构成: SQL 执行占 100%, 语法分析占 0%, PL/SQL
执行占 0%, Java 执行占 0%。
原理
SQL_ID 为 "c0xcd2ptjp3sh" 的 SQL 语句执行了 1262 次, 每次执行平均用时 0.07
9 秒。
建议案 5: SQL 优化
估计的收益为 0 个活动会话, 占总活动的 3.54\%。
-----------------------------
操作
对 SELECT 语句 (SQL_ID 为 "fwxqh94db0xs1") 运行 SQL 优化指导。
相关对象
SQL_ID 为 fwxqh94db0xs1 的 SQL 语句。
select TB.SID as SID, TB.ODO_ID as ODO_ID, TB.ODO_TYPE as
ODO_TYPE, TB.SOLD_TO as SOLD_TO, TB.SOLD_TO_DESC as
SOLD_TO_DESC, TB.SHIP_TO as SHIP_TO, TB.SHIP_TO_DESC as
SHIP_TO_DESC, TB.SALES_ORG as SALES_ORG, TB.TRSPT_TYPE as
TRSPT_TYPE, TB.TRSPT_CONDITION as TRSPT_CONDITION,
TB.TRSPT_POINT as TRSPT_POINT, TB.STATION_ID as STATION_ID,
TB.SPECIAL_LINE as SPECIAL_LINE, TB.RECEIPT_BY as RECEIPT_BY,
TB.RECEIPT_BY_NAME as RECEIPT_BY_NAME, TB.COMMENTS as COMMENTS,
TB.STATUS as STATUS, TB.TDO_ID as TDO_ID, TB.DO_ID as DO_ID,
TB.VERSION as VERSION, TB.CREATED_BY as CREATED_BY,
TB.CREATED_DT as CREATED_DT, TB.UPDATED_BY as UPDATED_BY,
TB.UPDATED_DT as UPDATED_DT, TB.DELIVERY_DT as DELIVERY_DT,
TB.SAP_TRSPT_TYPE as SAP_TRSPT_TYPE, TB.SC_TRSPT_TYPE as
SC_TRSPT_TYPE, TB.ORIGIN_SYSTEM_NAME as ORIGIN_SYSTEM_NAME,
TB.SPLIT_SEQ as SPLIT_SEQ from HP_SD_OB_DVY_ORDER TB where
1=1 and ODO_ID = :1
ORDER BY SID DESC
原理
SQL 在 CPU, I/O 和集群等待上花费的时间占其数据库时间的 100%。这部分数据库
时间可通过 SQL 优化指导进行改善。
原理
此 SQL 的数据库时间由以下部分构成: SQL 执行占 100%, 语法分析占 0%, PL/SQL
执行占 0%, Java 执行占 0%。
原理
SQL_ID 为 "fwxqh94db0xs1" 的 SQL 语句执行了 294 次, 每次执行平均用时 0.32
秒。
查找结果 2: 特殊的 "网络" 等待事件
受影响的是 .04 个活动会话, 占总活动的 43.05\%。
-------------------------------
等待事件 "SQL*Net message from dblink" (在等待类 "Network" 中) 消耗了大量数据库
时间。
建议案 1: 应用程序分析
估计的收益为 .04 个活动会话, 占总活动的 43.05\%。
--------------------------------
操作
研究 "SQL*Net message from dblink" 等待数较大的原因。有关此等待事件的说明,
请参阅 Oracle 的
"Database Reference"。
操作
查看 "顶级 SQL 语句" 以找出在 "SQL*Net message from dblink" 等待事件上消耗
大量时间的 SQL
语句。例如, SELECT 语句 (SQL_ID 为 "asucsbscb1tma") 占这些等待的 100%。
建议案 2: 应用程序分析
估计的收益为 .04 个活动会话, 占总活动的 43.05\%。
--------------------------------
操作
研究 "SQL*Net message from dblink" 等待数在 "SYS$USERS" 服务中非常高的原因
。
建议案 3: 应用程序分析
估计的收益为 .04 个活动会话, 占总活动的 43.05\%。
--------------------------------
操作
研究 "SQL*Net message from dblink" 等待数 (P1 ["driver id"] 的值为 "0", P2
["#bytes"] 的值为 "1") 非常高的原因。
导致查找结果的故障现象:
------------
等待类 "网络" 消耗了大量数据库时间。
受影响的是 .04 个活动会话, 占总活动的 43.17\%。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
附加信息
----
各种信息
----
等待类 "应用程序" 并未消耗大量数据库时间。
等待类 "提交" 并未消耗大量数据库时间。
等待类 "并发" 并未消耗大量数据库时间。
等待类 "配置" 并未消耗大量数据库时间。
CPU 不是此实例的瓶颈。
等待类 "用户 I/O" 并未消耗大量数据库时间。
会话连接和断开连接的调用并未消耗大量数据库时间。
对 SQL 语句的硬语法分析并未消耗大量数据库时间。
******************************************************附件其他解读************************************************
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.
--其它部分是一些额外的信息，用于说明哪些类别没有消耗大量的数据库时间。
扫一扫
964
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
