其實，網上關于AWR的解析已經足夠多了。但總覺得通過收集資料，再加工寫出來的資料能便于自己了解其中的各項内容，是以我對AWR進行一篇詳盡的解析。希望能分幾次完成
從AWR報告的第一部分包含了資料庫的名稱、資料庫的ID号、執行個體名、執行個體數、啟動的時間、資料庫版本和是否為RAC。此外也包含了系統的部分資訊。
該部分最關鍵的内容是第三個子產品，裡面記錄了snapshot的開始時間和結束時間，以及資料庫運作時間和使用者級别調用(session)所消耗的時間。
DB CPU：Amount of CPU time (in microseconds) spent on database user-level calls. This does not include the CPU time spent on instance background processes such as PMON.
這裡就涉及一個問題，通過資料庫使用者調用的時間可以算出資料庫繁忙的程度。首先來看看Elapsed Time為1664.70 mins 折算成秒為
Elasped Time=(1664*60+.7*60)/3600 hours
看下snapshot begin to end 時間為27 hours 44 mins 42 sec 剛好就是Elasped Time的時間。
系統有32個CPUs，因為并行作業的緣故，總計DB在CPU上消耗的時間應為32*1664.7 而DB Time的時間為在所有CPUs上消耗的時間106.76 mins。
從這裡我們就可以算出資料庫使用者級别消耗的時間比：106.76/32*1664.7*100%≈0.2%
也就是說DB在CPU上的使用率為0.2%,idle rate達到99.8%。說明資料庫負載相當的低。
DB Time既然為使用者級别的調用，具體包含什麼呢？我這裡直接引用網上的公式。
DB Time= DB CPU + Non-Idle Wait + Wait on CPU queue
通過檢視CPU的負載大概可以印證這個資料。
第二部分
報告概要的Cache Sizes很簡單，主要包含buffer的尺寸、shared pool大小、标準塊大小、日志buffer的大小。
正如我們所知的，Oracle DB采用LRU算法，将資料塊内容緩存至Buffer中，進行資料的加速讀取通路操作，而對于已經修改過的Dirty Buffer，又通過Cache和DBWR程序寫回到資料檔案中。是以對于一個OLTP（On-Line Transaction Processing）型資料庫Buffer Cache是相當重要的。
資料庫CPU負載狀況分析
DB Time(s)=DB Time/Elasped,這裡得出的是近似值。可以了解為在資料庫運作的這個時段中，DB在調用方面消耗的時間。
DB CPU(s) 表示DB Time時間内，有約0.1S是消耗在CPU上的。
而CPU繁忙程度則需要觀察Instance CPU中的Busy CPU項
可以看出該資料庫該時間段内CPU 繁忙度為45.4%也是相當空閑的。
Transactions：說明資料庫每秒處理事務的個數為71.2,那麼這段時間段内總處理的事務數公式：
總事務數=Transactions*Elasped=71.2*1664.7*60=
事務的效能比
Buffer Nowait：非等待Buffer事件比
Buffer Hit：Buffer命中率
Library Hit %：庫命中率,主要針對資料庫的字典資訊的查詢
Execute to Parse：用于解析的執行比
Parse CPU to Parse Elapsd：CPU解析在整個解析中的時間比
Redo Nowait：非等待Redo事件比
In-memory Sort：記憶體中的排序的事件比
Soft Parse：在總的解析次數中軟解析比率
Latch Hit：闩的命中率
% Non-Parse CPU：非解析CPU使用比
共享池狀态
SQL with executions：超過1次被調用的SQL語句比例
Memory for SQL w/exec：記憶體中SQL寫操作超過1次比例
占用時間前五的前台事件(Top 5 Timed Foreground Events)
DB CPU：占用的時間6411秒, 在整個DB Time時間中占用比為100.09% 說明CPU消耗很高。
log file sync：寫入日志檔案時間為424秒 占比424/6411*100%近似值
direct path read：
SQL*Net message to client：用戶端連接配接時間
cursor: pin S 遊标時間
這裡Avg wait(ms)的換算是有Time(s)/Waits獲得的。上面反映的資料 如log file sync幾乎為0，說在該時段内log file sync單次等待的時間近乎為0毫秒（實際值0.06ms) 。這裡表明沒有發生因日志的寫導緻的IO遲緩的問題。
按SQL執行耗時排序
而DB CPU一般都發生在執行SQL語句和調用Procedure的時候，這裡我們來觀察SQL order by CPU
上面的顯示了SQL執行的時間占CPU Time前10的SQL語句，在上面Top 5 foreground events中CPU time總計消耗了6411秒，而SQL執行消耗DB CPU時間總計為5359.64秒(%Total)。占了約83.6%的比例。
%CPU是在語句執行消耗的時間中CPU Time的時間比，即CPU Time(s)/Elasped Time(s)
%IO是語句執行的IO時間和Elasped Time比，即IO Time(s)/Elasped Time(s) in Read，通過IO的比可以看到哪些語句的實體讀占用比較多，同樣可以在SQL order by Read表中擷取
通過Reads表可以觀察到SQL的實體讀的情況，這裡的Elasped Time(s)就是用于計算%IO的基數。
通過這個觀察，可以看到其中IO讀最多的一個語句是SQLPLUS工具中調用了一個語句，很明顯該語句的參數了大量的實體讀操作。那麼就要考慮該語句的優化了。接下來可以觀察SQL的邏輯讀部分。Gets表示的是SQL語句在Buffer中擷取的資料量
裡面統計的Total Buffer Gets總值為527,755,991，%Total=Buffer Gets/Total Buffer Gets
這裡的SQL發生總Buffer Gets為784,209,002
To Be Continue...... : P
轉載于:https://blog.51cto.com/onlinekof2001/1712794