[Oracle]-性能优化工具（3）-ADDM

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% 期间, 数据库的维护窗口是处于活动状态的。