作者：david_zhang@sh 【轉載時請以超鏈接形式標明文章】
鏈接：http://www.cnblogs.com/david-zhang-index/archive/2012/08/21/2649252.html
1.先看一張圖片，描述awr和ash的一些基礎信息
1 SQL> conn /as sysdba 2 Connected. 3 SQL> @?/rdbms/admin/awrrpt.sql 4 5 Current Instance 6 ~~~~~~~~~~~~~~~~ 7 8 DB Id DB Name Inst Num Instance 9 ----------- ------------ -------- ------------ 10 3918594034 ORCL 1 orcl 11 12 13 Specify the Report Type 14 ~~~~~~~~~~~~~~~~~~~~~~~ 15 Would you like an HTML report, or a plain text report? 16 Enter 'html' for an HTML report, or 'text' for plain text 17 Defaults to 'html' 18 Enter value for report_type: html 19 20 Type Specified: html 21 22 23 Instances in this Workload Repository schema 24 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 25 26 DB Id Inst Num DB Name Instance Host 27 ------------ -------- ------------ ------------ ------------ 28 * 3918594034 1 ORCL orcl DCMSBDM 29 30 Using 3918594034 for database Id 31 Using 1 for instance number 32 33 34 Specify the number of days of snapshots to choose from 35 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 36 Entering the number of days (n) will result in the most recent 37 (n) days of snapshots being listed. Pressing <return> without 38 specifying a number lists all completed snapshots. 39 40 41 Enter value for num_days: 2 42 43 Listing the last 2 days of Completed Snapshots 44 45 Snap 46 Instance DB Name Snap Id Snap Started Level 47 ------------ ------------ --------- ------------------ ----- 48 kobra KOBRA 1227 20 Aug 2012 00:00 1 49 1228 20 Aug 2012 01:00 1 50 1229 20 Aug 2012 02:00 1 51 1230 20 Aug 2012 03:00 1 52 1231 20 Aug 2012 04:00 1 53 ... 54 1263 21 Aug 2012 12:00 1 55 1264 21 Aug 2012 13:00 1 56 1265 21 Aug 2012 14:00 1 57 1266 21 Aug 2012 15:00 1 58 59 60 Specify the Begin and End Snapshot Ids 61 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 62 Enter value for begin_snap: 1227 63 Begin Snapshot Id specified: 1227 64 65 Enter value for end_snap: 1265 66 End Snapshot Id specified: 1265 67 68 69 Specify the Report Name 70 ~~~~~~~~~~~~~~~~~~~~~~~ 71 The default report file name is awrrpt_1_1227_1265.html. To use this name, 72 press <return> to continue, otherwise enter an alternative. 73 74 Enter value for report_name: 75 76 Using the report name awrrpt_1_1227_1265.html 77 78 <html><head><title>AWR Report for DB: KOBRA, Inst: kobra, Snaps: 1227-1265</title> 79 80 ... 81 82 End of Report 83 </body></html> 84 Report written to awrrpt_1_1227_1265.html 85 86 SQL> exit
2.AWR報告分析
2.1CPU負載分析
如果關注數據庫的性能，那么當拿到一份AWR報告的時候，最想知道的第一件事情可能就是系統資源的利用情況了，而首當其沖的，就是CPU。而細分起來，CPU可能指的是：
1. OS級的User%，Sys%， Idle%
2. DB所占OS CPU資源的Busy%
3. DB CPU又可以分為前台所消耗的CPU和后台所消耗的CPU
如果數據庫的版本是11g，那么很幸運的，這些信息在AWR報告中一目了然：
分析上面的圖片，我們可以得出下面的結論：
OS級的User%，Sys%，Idle%：
OS級的%User為3.4，%Sys為0.4，%Idle為96.1，所以%Busy應該是100-96.1=3.9
DB所占OS CPU資源的Busy%：
DB占了OS CPU資源的3.7，%Busy CPU則可以通過上面的數據得到： %Busy CPU = %Total CPU/(%Busy) * 100 =3.7/3.9 * 100 = 94.87，應該和報告的95.3相吻合，這里有出入，我也不知道原因。
Host CPU的結果來源於DBA_HIST_OSSTAT，AWR 報告里已經幫忙整出了這段時間內的絕對數據(這里的時間單位是centi second,也就是1/100秒)
%User = USER_TIME/ (BUSY_TIME+IDLE_TIME)*100 = 1,850,185/ (2,147,757+52,550,299)*100 = 3.38
%Sys = SYS_TIME/ (BUSY_TIME+IDLE_TIME)*100=234,229/ (2,147,757+52,550,299)*100=0.4
%Idle = IDLE_TIME/ (BUSY_TIME+IDLE_TIME)*100=52,550,299/ (2,147,757+52,550,299)*100=96.1
值得注意的，這里已經隱含着這個AWR報告所捕捉的兩個Snapshot之間的時間長短了。有下面的公式：
BUSY_TIME + IDLE_TIME = ELAPSED_TIME * CPU_COUNT
注意：正確的理解這個公式可以對系統CPU資源的使用及其度量的方式有更深一步的理解。
因此ELAPSED_TIME = (2,147,757+52,550,299)/6/100 = 91163.42 seconds
Total DB CPU = DB CPU + Background CPU time = 20,108.16 + 357.62 = 20465.78 centi seconds
Total DB CPU除以總的 BUSY_TIME + IDLE_TIME可得出% Total CPU
% Total CPU = 20465.78/54698056 =3.7%，這剛好與上面Report的值相吻合。
其實，在Load Profile部分，我們也可以看出DB對系統CPU的資源利用情況。
用DB CPU per Second除以CPU Count就可以得到DB在前台所消耗的CPU%了。這里 0.2/6 = 3.3 %比3.7%稍小，說明DB在后台也消耗了大約0.4%的CPU，這是不是一個最簡單的方法了呢？
3 DB Time – 進程消耗時間分析
DB CPU是一個用於衡量CPU的使用率的重要指標。假設系統有N個CPU，那么如果CPU全部處於繁忙狀態的話，一秒鍾內的DB CPU就是N秒。
如何去表征一個系統的繁忙程度呢？除了利用CPU進行計算外，數據庫還會利用其它計算資源，如網絡、硬盤、內存等等，這些對資源的利用同樣可以利用時間進行度量。假設系統有M個Session在運行，同一時刻，有的Session可能在利用CPU，有的Session可能在訪問硬盤，那么，在一秒鍾內，所有Session的時間加起來就可以表征系統在這一秒內的繁忙程度，一般的，這個和的最大值應該為M。這其實就是Oracle提供的另一個重要指標：DB Time，它用以衡量前端進程所消耗的總時間。 對除CPU以外的計算資源的訪問，Oracle用等待事件進行描述。同樣地，和CPU可分為前台消耗CPU和后台消耗CPU一樣，等待事件也可以分為前台等待事件和后台等待事件。 DB Time一般的應該等於DB CPU + 前台等待事件所消耗時間的總和。等待時間通過V$SYSTEM_EVENT視圖進行統計，DB Time和DB CPU則是通過同一個視圖，即V$SYS_TIME_MODEL進行統計。 Load Profile一節就有了對DB Time的描述：
這個系統的CPU個數是6，因此我們可以知道前台進程用了系統CPU的0.2/6=3.3%。DB Time/s為0.2，可以看出這個系統是CPU不繁忙的。里面CPU占了0.2，則其它前台等待事件占了0.2 – 0.2 = 0 Wait Time/s。DB CPU占DB Time的比重呢？ 0.2/0.2= 100%
Top 5 Timed Events，或許很多人都對它有所耳聞，按照CPU/等待事件占DB Time的比例大小，這里列出了Top 5。如果一個工作負載是CPU繁忙型的話，那么在這里應該可以看到 DB CPU的影子。
