【Oracle】詳解ADDM工具


一、ADDM簡介  
        Oracle9i及之前,DBA們已經擁有了很多很好用的性能分析工具,比如,tkprofsql_tracestatspackset event 10046&10053等等。這些工具能夠幫助DBA很快的定位性能問題。但這些工具都只給出一些統計數據,然后再由DBA們根據自己的經驗進行優化。

   那能不能由機器自動在統計數據的基礎上給出優化建議呢?Oracle10g中就推出了新的優化診斷工具:數據庫自動診斷監視工具(Automatic Database Diagnostic Monitor ADDM)和SQL優化建議工具(SQL Tuning Advisor STA)。這兩個工具的結合使用,能使DBA節省大量優化時間,也大大減少了系統宕機的危險。簡單點說,ADDM就是收集相關的統計數據到自動工作量知識庫(Automatic Workload Repository AWR)中,而STA則根據這些數據,給出優化建議。例如,一個系統資源緊張,出現了明顯的性能問題,由以往的辦法,做個一個statspack快照,等30分鍾,再做一次。查看報告,發現db file scattered read事件在top 5 events里面。根據經驗,這個事件一般可能是因為缺少索引、統計分析信息不夠新、熱表都放在一個數據文件上導致IO爭用等原因引起的。根據這些經驗,我們需要逐個來定位排除,比如查看語句的查詢計划、查看user_tableslast_analysed子段,檢查熱塊等等步驟來最后定位出原因,並給出優化建議。但是,有了STA以后,它就可以根據ADDM采集到的數據直接給出優化建議,甚至給出優化后的語句。

 

ADDM能發現定位的問題包括:

·操作系統內存頁入頁出問題

·由於Oracle負載和非Oracle負載導致的CPU瓶頸問題

·導致不同資源負載的Top SQL語句和對象——CPU消耗、IO帶寬占用、潛在IO問題、RAC內部通訊繁忙

·按照PLSQL和JAVA執行時間排的Top SQL語句.

·過多地連接(login/logoff).

·過多硬解析問題——由於shared pool過小、書寫問題、綁定大小不適應、解析失敗原因引起的

·過多軟解析問題

·索引查詢過多導致資源爭用.

·由於用戶鎖導致的過多的等待時間(通過包dbms_lock加的鎖)

·由於DML鎖導致的過多等待時間(例如鎖住表了)

·由於管道輸出導致的過多等待時間(如通過包dbms_pipe.put進行管道輸出)

·由於並發更新同一個記錄導致的過多等待時間(行級鎖等待)

·由於ITL不夠導致的過多等待時間(大量的事務操作同一個數據塊)

·系統中過多的commit和rollback(logfile sync事件).

·由於磁盤帶寬太小和其他潛在問題(如由於logfile太小導致過多的checkpoint,MTTR設置問題,過多的undo操作等等)導致的IO性能問題

·對於DBWR進程寫數據塊,磁盤IO吞吐量不足

·由於歸檔進程無法跟上redo日至產生的速度,導致系統變慢

·redo數據文件太小導致的問題

·由於擴展磁盤分配導致的爭用

·由於移動一個對象的高水位導致的爭用問題

·內存太小問題——SGA Target, PGA, Buffer Cache,Shared Pool

·在一個實例或者一個機群環境中存在頻繁讀寫爭用的熱塊

·在一個實例或者一個機群環境中存在頻繁讀寫爭用的熱對象

·RAC環境中內部通訊問題

·LMS進程無法跟上導致鎖請求阻塞

·在RAC環境中由於阻塞和爭用導致的實例傾斜

·RMAN導致的IO和CPU問題

·Streams和AQ問題

·資源管理等待事件

注意:AWR收集的數據時放到內存中(share pool),通過一個新的后台進程MMON定期寫到磁盤中。所以10g的share pool要求比以前版本更大,一般推薦比以前大15-20%。另外,還要求系統參數STATISTICS_LEVEL設置為TYPICAL(推薦)或ALL;

ALTER SESSION SET STATISTICS_LEVEL= TYPICAL;

 

二、案例

1.---SCOTT用戶下創建測試表t1:

16:57:34 SCOTT@GOOD>  create table t1 (id number);

 

Table created.

2.---SYS用戶下收集AWR Snapshot:

16:56:33 SYS@GOOD> begin

17:02:15   2     dbms_workload_repository.create_snapshot('TYPICAL');

17:02:15   3  end;

17:02:15   4  /

 

PL/SQL procedure successfully completed.

3.---SCOTT用戶下向表t1中插入大量數據:

17:03:37 SCOTT@GOOD> begin

17:03:38   2    for i in 1..1000000 loop

17:03:38   3    execute immediate 'insert into scott.t1 values('||i||')';

17:03:38   4    end loop;

17:03:38   5  end;

17:03:38   6  /

 

PL/SQL procedure successfully completed.

4.---TOM用戶下向表t1中插入大量數據:

17:03:37 SCOTT@GOOD> begin

17:03:38   2    for i in 1..1000000 loop

17:03:38   3    execute immediate 'insert into scott.t1 values('||i||')';

17:03:38   4    end loop;

17:03:38   5  end;

17:03:38   6  /

 

PL/SQL procedure successfully completed.

5.---在SYS用戶下再次收集AWR Snapshot:

17:02:18 SYS@GOOD> begin

17:28:18   2     dbms_workload_repository.create_snapshot('TYPICAL');

17:28:18   3  end;

17:28:18   4  /

 

PL/SQL procedure successfully completed.

6.---查詢生成的快照:

17:31:59 SYS@GOOD> select snap_id,BEGIN_INTERVAL_TIME,END_INTERVAL_TIME from dba_hist_snapshot order by snap_id asc;

 

   SNAP_ID BEGIN_INTERVAL_TIME             END_INTERVAL_TIME

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

         1 10-NOV-16 02.59.56.000 PM      19-DEC-16 09.50.08.076 AM

         2 19-DEC-16 10.59.49.000 PM      19-DEC-16 11.10.08.042 PM

          ...

        54 25-DEC-16 04.00.54.990 PM      25-DEC-16 04.56.32.441 PM

        55 25-DEC-16 04.56.32.441 PM      25-DEC-16 05.02.16.537 PM

        56 25-DEC-16 05.02.16.537 PM      25-DEC-16 05.28.19.428 PM

 

56 rows selected.

 

7.---創建優化任務並執行:

17:36:40 SYS@GOOD> DECLARE                                                              

17:36:41   2  task_name VARCHAR2(30) := 'DEMO_ADDM01';                              

17:36:41   3  task_desc VARCHAR2(30) := 'ADDM Feature Test';                        

17:36:41   4  task_id NUMBER;                                                       

17:36:41   5  BEGIN                                                                     

17:36:41   6  dbms_advisor.create_task('ADDM',task_id,task_name,task_desc,null);

17:36:41   7  dbms_advisor.set_task_parameter(task_name,'START_SNAPSHOT',55);    

17:36:41   8  dbms_advisor.set_task_parameter(task_name,'END_SNAPSHOT',56);      

17:36:41   9  dbms_advisor.set_task_parameter(task_name,'INSTANCE',1);            

17:36:41  10  dbms_advisor.set_task_parameter(task_name,'DB_ID',244129167);       

17:36:41  11  dbms_advisor.execute_task(task_name);                                 

17:36:41  12  END;                                                                      

17:36:41  13  /

 

PL/SQL procedure successfully completed.

其中,set_task_parameter是用來設置任務參數的。START_SNAPSHOT是起始快照ID,END_SNAPSHOT是結束快照ID,INSTANCE是實例號,對於單實例,一般是1,在RAC環境下,可以通過查詢視圖v$instance得到,DB_ID是數據庫的唯一識別號,可以通過查詢v$database查到。 

8.---查看優化建議結果:

17:38:44 SYS@GOOD> SELECT dbms_advisor.get_task_report('DEMO_ADDM01','TEXT','ALL') FROM DUAL;

 

DBMS_ADVISOR.GET_TASK_REPORT('DEMO_ADDM01','TEXT','ALL')

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

          ADDM Report for Task 'DEMO_ADDM01'

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

 

Analysis Period

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

AWR snapshot range from 55 to 56.

Time period starts at 25-DEC-16 05.02.17 PM

Time period ends at 25-DEC-16 05.28.19 PM

 

....中間部分省略

The database's maintenance windows were active during 99% of the analysis

period.

9.診斷分析結果

我們從上面的建議結果看到了,ADDM Report的結果與Statspack Report的結果大不相同。Statspack Report的結果給出的都是統計數據、各種事件,然后由DBA根據這些數據給出優化建議,而ADDM Report的結果包含就已經是給出的優化建議了。

 

   

 


注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2020 ITdaan.com