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"), 確定是否可以改善性能?？梢岳?/p>

用此 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

總結

以上是生活随笔為你收集整理的oracle连接工具 DBz,[Oracle] - 性能优化工具（3） - ADDM的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。