ADDM 通過檢查和分析AWR采集的數(shù)據(jù)來推斷Oracle在數(shù)據(jù)庫中可能出現(xiàn)的問題。并給出優(yōu)化建議。
獲得ADDM例如，下面的方法：
@?/rdbms/admin/addmrpt.sql
以下能夠看一個樣例：
--第一步：創(chuàng)建測試用的表
drop table t cascade constraints purge;
create table t AS SELECT * FROM dba_objects ;
--第二步:快照
exec dbms_workload_repository.create_snapshot();
--第三步：模擬進(jìn)行
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();
--第五步：創(chuàng)建一個優(yōu)化診斷任務(wù)并運(yùn)行
--(1)先獲取到兩次快照的ID:
select snap_id from (SELECT * FROM dba_hist_snapshot ORDER BY snap_id desc) where rownum <=2;
--(2)創(chuàng)建優(yōu)化任務(wù)，并運(yùn)行：
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;
/
--第六步：查看優(yōu)化建議結(jié)果
--通知函數(shù)dbms_advisor.get_task_report能夠得到優(yōu)化建議結(jié)果。
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
任務(wù) '任務(wù)_4125' 的 ADDM 報(bào)告
----------------------
分析時段
----
AWR 快照范圍從 1908 到 1952。
時段從 16-2月 -14 08.19.56 上午 開始
時段在 16-2月 -14 10.00.37 下午 結(jié)束
分析目標(biāo)
----
數(shù)據(jù)庫 'TEST11G' (DB ID 為 977587123)。
數(shù)據(jù)庫版本號 11.2.0.1.0。
ADDM 對實(shí)例 test11g 運(yùn)行了分析, 該實(shí)例的編號為 1 并運(yùn)行于 LIANGJB-PC。
分析時段期間的活動
---------
總數(shù)據(jù)庫時間為 26244 秒。
活動會話的平均數(shù)量為 .53。
查找結(jié)果概要
------
說明 活動的會話 建議案
活動的百分比
--------- ------ ---
1 行鎖等待數(shù) .52 | 97.762
2 頂級 SQL 語句 .52 | 96.742
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
查找結(jié)果和建議案
--------
查找結(jié)果 1: 行鎖等待數(shù)
受影響的是 .52 個活動會話, 占總活動的 97.76\%。
-------------------------------
發(fā)現(xiàn) SQL 語句正處于行鎖定等待。
建議案 1: 應(yīng)用程序分析
預(yù)計(jì)的收益為 .39 個活動會話, 占總活動的 72.36\%。
--------------------------------
操作
在 INDEX "LJB.GENDER_IDX" (對象 ID 為 110057) 中檢測到了嚴(yán)重的行爭用。使用
指定的堵塞 SQL
語句在應(yīng)用程序邏輯中跟蹤行爭用的起因。
相關(guān)對象
ID 為 110057 的數(shù)據(jù)庫對象。
原理
SQL_ID 為 "cafv93454t4jv" 的 SQL 語句在行鎖上被堵塞。
相關(guān)對象
SQL_ID 為 cafv93454t4jv 的 SQL 語句。
insert into t values ('M',78, 'young','TTT')
原理
具有 ID 130 和序列號 423 (在實(shí)例號 1 中) 的會話是構(gòu)成此建議案中的優(yōu)化建議
的 98% 的堵塞會話。
建議案 2: 應(yīng)用程序分析
預(yù)計(jì)的收益為 .14 個活動會話, 占總活動的 25.4\%。
-------------------------------
操作
在 TABLE "LJB.T" (對象 ID 為 110056) 中檢測到了嚴(yán)重的行爭用。使用指定的阻
塞 SQL
語句在應(yīng)用程序邏輯中跟蹤行爭用的起因。
相關(guān)對象
ID 為 110056 的數(shù)據(jù)庫對象。
原理
SQL_ID 為 "aycghy7dbzja1" 的 SQL 語句在行鎖上被堵塞。
相關(guān)對象
SQL_ID 為 aycghy7dbzja1 的 SQL 語句。
delete from T WHERE GENDER='M'
原理
具有 ID 130 和序列號 423 (在實(shí)例號 1 中) 的會話是構(gòu)成此建議案中的優(yōu)化建議
的 100% 的堵塞會話。
導(dǎo)致查找結(jié)果的故障現(xiàn)象:
------------
等待類 "應(yīng)用程序" 消耗了大量數(shù)據(jù)庫時間。
受影響的是 .52 個活動會話, 占總活動的 97.76\%。
查找結(jié)果 2: 頂級 SQL 語句
受影響的是 .52 個活動會話, 占總活動的 96.74\%。
-------------------------------
發(fā)現(xiàn) SQL 語句消耗了大量數(shù)據(jù)庫時間。這些語句提供了改善性能的絕佳機(jī)會。
建議案 1: SQL 優(yōu)化
預(yù)計(jì)的收益為 .38 個活動會話, 占總活動的 71.45\%。
--------------------------------
操作
研究 INSERT 語句 (SQL_ID 為 "cafv93454t4jv"), 確定能否夠改善性能。能夠利
用此 SQL_ID 的 ASH
報(bào)告來補(bǔ)充此處給出的信息。
相關(guān)對象
SQL_ID 為 cafv93454t4jv 的 SQL 語句。
insert into t values ('M',78, 'young','TTT')
原理
SQL 在 CPU, I/O 和集群等待上花費(fèi)的時間僅僅占其數(shù)據(jù)庫時間的 0%。因此, SQL 優(yōu)
化指導(dǎo)不適用于這樣的情況。請查看 SQL
的性能數(shù)據(jù)以找出可能的改進(jìn)方法。
原理
此 SQL 的數(shù)據(jù)庫時間由下面部分構(gòu)成: SQL 運(yùn)行占 100%, 語法分析占 0%, PL/SQL
運(yùn)行占 0%, Java 運(yùn)行占 0%。
原理
SQL_ID 為 "cafv93454t4jv" 的 SQL 語句運(yùn)行了 1 次, 每次運(yùn)行平均用時 17640
秒。
原理
等待事件 "enq: TX - row lock contention" (在等待類 "Application" 中) 消耗
了數(shù)據(jù)庫時間的
100% (該數(shù)據(jù)庫時間為處理具有 SQL_ID "cafv93454t4jv" 的 SQL 語句時所用的時
間)。
建議案 2: SQL 優(yōu)化
預(yù)計(jì)的收益為 .13 個活動會話, 占總活動的 25.29\%。
--------------------------------
操作
研究 DELETE 語句 (SQL_ID 為 "aycghy7dbzja1"), 確定能否夠改善性能。能夠利
用此 SQL_ID 的 ASH
報(bào)告來補(bǔ)充此處給出的信息。
相關(guān)對象
SQL_ID 為 aycghy7dbzja1 的 SQL 語句。
delete from T WHERE GENDER='M'
原理
SQL 在 CPU, I/O 和集群等待上花費(fèi)的時間僅僅占其數(shù)據(jù)庫時間的 0%。因此, SQL 優(yōu)
化指導(dǎo)不適用于這樣的情況。請查看 SQL
的性能數(shù)據(jù)以找出可能的改進(jìn)方法。
原理
此 SQL 的數(shù)據(jù)庫時間由下面部分構(gòu)成: SQL 運(yùn)行占 100%, 語法分析占 0%, PL/SQL
運(yùn)行占 0%, Java 運(yùn)行占 0%。
原理
SQL_ID 為 "aycghy7dbzja1" 的 SQL 語句運(yùn)行了 1 次, 每次運(yùn)行平均用時 7917 秒
。
原理
等待事件 "enq: TX - row lock contention" (在等待類 "Application" 中) 消耗
了數(shù)據(jù)庫時間的
100% (該數(shù)據(jù)庫時間為處理具有 SQL_ID "aycghy7dbzja1" 的 SQL 語句時所用的時
間)。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
附加信息
----
各種信息
----
等待類 "提交" 并未消耗大量數(shù)據(jù)庫時間。
等待類 "并發(fā)" 并未消耗大量數(shù)據(jù)庫時間。
等待類 "配置" 并未消耗大量數(shù)據(jù)庫時間。
等待類 "網(wǎng)絡(luò)" 并未消耗大量數(shù)據(jù)庫時間。
等待類 "用戶 I/O" 并未消耗大量數(shù)據(jù)庫時間。
會話連接和斷開連接的調(diào)用并未消耗大量數(shù)據(jù)庫時間。
對 SQL 語句的硬語法分析并未消耗大量數(shù)據(jù)庫時間。
在分析時段的 99% 期間, 數(shù)據(jù)庫的維護(hù)窗體是活躍。
版權(quán)聲明：本文博客原創(chuàng)文章。博客，未經(jīng)同意，不得轉(zhuǎn)載。
更多文章、技術(shù)交流、商務(wù)合作、聯(lián)系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯(lián)系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點(diǎn)擊下面給點(diǎn)支持吧，站長非常感激您！手機(jī)微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點(diǎn)擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
