關於AWR報告的解析

其實，網上關於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