AWR你好（1）文中提到過，AWR、ASH和ADDM三者之間有些存在某種問題或陰謀，那在對ASH簡單做了介紹以後，那這次我們就來看ADDM.
ADDM（Automatic Database Diagnostic Monitor）資料庫自動診斷監控（o小白自己翻譯的啊……有點不太順），在AWR生成了快照以後，oracle會自動調用ADDM，對最近的兩個快照之間的狀态進行分析，總結可能導緻資料庫性能問題的原因并生成報表。ADDM的主要依據就是database time，那什麼是database time呢，也就是一個資料庫請求到響應的時間。
那o小白自己的了解來說，就是ADDM自動把可能導緻資料庫響應時間最慢的事件給找了出來，從症狀開始，比如哪句sql語句導緻的響應時間變慢，然後分析根本原因，比如是因為db file scattered read，那下面o小白會給大家看個例子，是o小白自己做的ADDM的實驗。
實驗背景是o小白建立了一張表，addmtest，用于測試ADDM.
首先，有心的朋友會發現，昨天的那張腳本的圖裡有一個腳本叫ADDMRPT，那這個腳本就是生成ADDM表報的工具，那前面介紹過了ADDM是根據快照來進行自動分析的，那和前面的AWR腳本一樣，指定起始快照和結束快照以後就可以生成ADDM報表了，唯一不同的是ADDM隻支援txt模式，不支援HTML格式。實驗步驟幾乎完全一緻，也就不貼出來了，不過這裡一點需要注意的，o小白在做實驗的時候碰到了最後結果是這樣的情況。
圖示的結果說NOT ENOUGH DATABASE TIME，而且從上面的Average Database Load和Database Time這兩個都是0，也就是說，這兩個快照之内資料庫幾乎沒有任何負載，那ADDM自然也就沒東西好分析了，o小白實驗環境，自然是沒有負載的，如果是生産庫，那大概是至少30分鐘收集一次吧，當然也要根據業務的情況進行調整。
那o小白就模拟一下負載，編寫了一段腳本，循環往addmtest裡面進行自插入（原來的内容是dba_tables），循環個20次。然後再次運作腳本，生成了報表結果如下。（太長了截一段）
那可以看到，ADDM診斷是SQL Tuning，發現了sql語句，然後找到對應的wait event，後面幾個finding也是一樣的内容， 因為o小白是循環插入的嘛～
那可以看到ADDM還是很好用的，特别對于新手來說，可以讓oracle自動發現問題所在，但是所謂的工具也僅僅是工具而已，不可能那麼智能，有的時候ADDM的分析診斷也并不準确，可能按照他所說的做反而會導緻其他的問題，那隻能提供一個參考，更多還是要看DBA的經驗，而這種經驗自然是要日積月累的，厚積薄發～