ADDM 通过检查和分析AWR获取的数据来判断Oracle数据库中可能的问题，并给出优化建议。

获取ADDM的方法如下：

@?/rdbms/admin/addmrpt.sql下面可以看一个例子：

--第一步：创建测试用的表

drop table t cascade constraints purge;

create table t AS SELECT * FROM dba_objects ;

--第二步:快照

exec dbms_workload_repository.create_snapshot();

--第三步：模拟进行

DECLARE

v_var number;

BEGIN

FOR n IN 1..10000

LOOP

select count(*) into v_var from t;

END LOOP;

END;

/

---第四步：再次快照

exec dbms_workload_repository.create_snapshot();

--第五步：创建一个优化诊断任务并执行

--(1)先获取到两次快照的ID:

select snap_id from (SELECT * FROM dba_hist_snapshot ORDER BY snap_id desc) where rownum <=2;

--(2)创建优化任务，并执行：

DECLARE

task_name VARCHAR2(30) := 'ADDM_02';

task_desc VARCHAR2(30) := 'ADDM Feature Test';

task_id NUMBER;

BEGIN

dbms_advisor.create_task('ADDM', task_id, task_name, task_desc, null);

dbms_advisor.set_task_parameter(task_name, 'START_SNAPSHOT', 2033);

dbms_advisor.set_task_parameter(task_name, 'END_SNAPSHOT', 2034);

dbms_advisor.set_task_parameter(task_name, 'INSTANCE', 1);

dbms_advisor.set_task_parameter(task_name, 'DB_ID', 977587123);

dbms_advisor.execute_task(task_name);

END;

/

--第六步：查看优化建议结果

--通知函数dbms_advisor.get_task_report可以得到优化建议结果。

set pagesize 0

set linesize 121

spool d:\addm_rpt.html

SET LONG 1000000 PAGESIZE 0 LONGCHUNKSIZE 1000

COLUMN get_clob FORMAT a80

SELECT dbms_advisor.get_task_report('ADDM_02', 'TEXT', 'ALL') FROM DUAL;

spool off

生成的ADDM如下：

任务 '任务_4125' 的 ADDM 报告

----------------------

分析时段

----

AWR 快照范围从 1908 到 1952。

时段从 16-2月 -14 08.19.56 上午 开始

时段在 16-2月 -14 10.00.37 下午 结束

分析目标

----

数据库 'TEST11G' (DB ID 为 977587123)。

数据库版本 11.2.0.1.0。

ADDM 对实例 test11g 执行了分析, 该实例的编号为 1 并运行于 LIANGJB-PC。

分析时段期间的活动

---------

总数据库时间为 26244 秒。

活动会话的平均数量为 .53。

查找结果概要

------

说明 活动的会话 建议案

活动的百分比

--------- ------ ---

1 行锁等待数 .52 | 97.762

2 顶级 SQL 语句 .52 | 96.742

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

查找结果和建议案

--------

查找结果 1: 行锁等待数

受影响的是 .52 个活动会话, 占总活动的 97.76\%。

-------------------------------

发现 SQL 语句正处于行锁定等待。

建议案 1: 应用程序分析

估计的收益为 .39 个活动会话, 占总活动的 72.36\%。

--------------------------------

操作

在 INDEX "LJB.GENDER_IDX" (对象 ID 为 110057) 中检测到了严重的行争用。使用

指定的阻塞 SQL

语句在应用程序逻辑中跟踪行争用的起因。

相关对象

ID 为 110057 的数据库对象。

原理

SQL_ID 为 "cafv93454t4jv" 的 SQL 语句在行锁上被阻塞。

相关对象

SQL_ID 为 cafv93454t4jv 的 SQL 语句。

insert into t values ('M',78, 'young','TTT')

原理

具有 ID 130 和序列号 423 (在实例号 1 中) 的会话是构成此建议案中的优化建议

的 98% 的阻塞会话。

建议案 2: 应用程序分析

估计的收益为 .14 个活动会话, 占总活动的 25.4\%。

-------------------------------

操作

在 TABLE "LJB.T" (对象 ID 为 110056) 中检测到了严重的行争用。使用指定的阻

塞 SQL

语句在应用程序逻辑中跟踪行争用的起因。

相关对象

ID 为 110056 的数据库对象。

原理

SQL_ID 为 "aycghy7dbzja1" 的 SQL 语句在行锁上被阻塞。

相关对象

SQL_ID 为 aycghy7dbzja1 的 SQL 语句。

delete from T WHERE GENDER='M'

原理

具有 ID 130 和序列号 423 (在实例号 1 中) 的会话是构成此建议案中的优化建议

的 100% 的阻塞会话。

导致查找结果的故障现象:

------------

等待类 "应用程序" 消耗了大量数据库时间。

受影响的是 .52 个活动会话, 占总活动的 97.76\%。

查找结果 2: 顶级 SQL 语句

受影响的是 .52 个活动会话, 占总活动的 96.74\%。

-------------------------------

发现 SQL 语句消耗了大量数据库时间。这些语句提供了改善性能的绝佳机会。

建议案 1: SQL 优化

估计的收益为 .38 个活动会话, 占总活动的 71.45\%。

--------------------------------

操作

研究 INSERT 语句 (SQL_ID 为 "cafv93454t4jv"), 确定是否可以改善性能。可以利

用此 SQL_ID 的 ASH

报告来补充此处给出的信息。

相关对象

SQL_ID 为 cafv93454t4jv 的 SQL 语句。

insert into t values ('M',78, 'young','TTT')

原理

SQL 在 CPU, I/O 和集群等待上花费的时间只占其数据库时间的 0%。因此, SQL 优

化指导不适用于这种情况。请查看 SQL

的性能数据以找出可能的改进方法。

原理

此 SQL 的数据库时间由以下部分构成: SQL 执行占 100%, 语法分析占 0%, PL/SQL

执行占 0%, Java 执行占 0%。

原理

SQL_ID 为 "cafv93454t4jv" 的 SQL 语句执行了 1 次, 每次执行平均用时 17640

秒。

原理

等待事件 "enq: TX - row lock contention" (在等待类 "Application" 中) 消耗

了数据库时间的

100% (该数据库时间为处理具有 SQL_ID "cafv93454t4jv" 的 SQL 语句时所用的时

间)。

建议案 2: SQL 优化

估计的收益为 .13 个活动会话, 占总活动的 25.29\%。

--------------------------------

操作

研究 DELETE 语句 (SQL_ID 为 "aycghy7dbzja1"), 确定是否可以改善性能。可以利

用此 SQL_ID 的 ASH

报告来补充此处给出的信息。

相关对象

SQL_ID 为 aycghy7dbzja1 的 SQL 语句。

delete from T WHERE GENDER='M'

原理

SQL 在 CPU, I/O 和集群等待上花费的时间只占其数据库时间的 0%。因此, SQL 优

化指导不适用于这种情况。请查看 SQL

的性能数据以找出可能的改进方法。

原理

此 SQL 的数据库时间由以下部分构成: SQL 执行占 100%, 语法分析占 0%, PL/SQL

执行占 0%, Java 执行占 0%。

原理

SQL_ID 为 "aycghy7dbzja1" 的 SQL 语句执行了 1 次, 每次执行平均用时 7917 秒

。

原理

等待事件 "enq: TX - row lock contention" (在等待类 "Application" 中) 消耗

了数据库时间的

100% (该数据库时间为处理具有 SQL_ID "aycghy7dbzja1" 的 SQL 语句时所用的时

间)。

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

附加信息

----

各种信息

----

等待类 "提交" 并未消耗大量数据库时间。

等待类 "并发" 并未消耗大量数据库时间。

等待类 "配置" 并未消耗大量数据库时间。

等待类 "网络" 并未消耗大量数据库时间。

等待类 "用户 I/O" 并未消耗大量数据库时间。

会话连接和断开连接的调用并未消耗大量数据库时间。

对 SQL 语句的硬语法分析并未消耗大量数据库时间。

在分析时段的 99% 期间, 数据库的维护窗口是处于活动状态的。

原文：http://blog.csdn.net/dbanote/article/details/26836871