AWR 是 Oracle 10g 版本 推出的新特性， 全稱叫Automatic Workload Repository-自動負載信息庫。它是一種Oracle10g提供的性能收集和分析工具，是進行Oracle性能調優的利器。它能提供一個時間段內整個系統資源使用情況的報告，通過這個報告，我們就可以瞭解一個系統的整個運行情況，這就像一個人全面的體檢報告。
AWR 是通過對比兩次快照(snapshot)收集到的統計信息，來生成報表數據，生成的報表包括多個部分。
下面根據某朋友公司讓我幫忙分析的AWR報告來逐條說明。
WORKLOAD REPOSITORY report for
| DB Name | DB Id | Instance | Inst num | Startup Time | Release | RAC |
|---|---|---|---|---|---|---|
| FXXOA | 3654559930 | fxxoa | 1 | 08-Mar-17 06:03 | 11.2.0.1.0 | NO |
這是DB的一些基本信息，DB name，instance name, instance number, DB version以及是否是RAC安裝。從這裏看出這是一個11gr2的single DB。
| Host Name | Platform | CPUs | Cores | Sockets | Memory (GB) |
|---|---|---|---|---|---|
| PXX_F10_client1 | AIX-Based Systems (64-bit) | 120 | 60 |
|
50.00 |
顯然，這是DB安裝的機器名，操作系統是AIX64bit，邏輯CPU有120個，物理CPU有60個，內存有50G。
|
|
Snap Id | Snap Time | Sessions | Cursors/Session |
|---|---|---|---|---|
| Begin Snap: | 38185 | 08-Mar-17 08:00:13 | 60 | 2.0 |
| End Snap: | 38186 | 08-Mar-17 09:00:21 | 113 | 6.6 |
| Elapsed: |
|
60.14 (mins) |
|
|
| DB Time: |
|
197.25 (mins) |
|
|
此表顯示抓取時間爲2017/3/8 8:00:13至9:00:21，共計60.14分鐘。開始sessions（即連接數）是60個，結束時sessions增到113個。
Cursors/Session是指平均每個session open的cursors數量。這個數的作用具體請參照 http://www.cnblogs.com/sumsen/archive/2012/07/19/2599206.html
DB Time不包括Oracle後臺進程消耗的時間。如果DB Time遠遠小於Elapsed時間，說明數據庫比較空閒。
db time= cpu time + wait time（不包含空閒等待）(非後臺進程）
說白了,db time就是記錄的服務器花在數據庫運算(非後臺進程)和等待(非空閒等待)上的時間
DB time = cpu time + all of nonidle wait event time。
這個報告中顯示，snap間隔60.14分鐘，那麼120個cpu就有60.14*120=7216.8分鐘，DB Time爲197.25分鐘，那麼
cpu有197.25/7216.8 * 100% = 2.73%的時間花費在正經工作上。說明DB的負載很低。
對於大多數系統，數據庫的工作負載總是集中在一段時間內。如果快照週期不在這一段時間內，或者快照週期跨度太長而包含了大量的數據庫空閒時間，所得出的分析結果是沒有意義的。這也說明選擇分析時間段很關鍵，要選擇能夠代表性能問題的時間段。
Report Summary
Cache Sizes
|
|
Begin | End |
|
|
|---|---|---|---|---|
| Buffer Cache: | 3,840M | 3,584M | Std Block Size: | 8K |
| Shared Pool Size: | 5,536M | 5,536M | Log Buffer: | 116,608K |
我們知道Buffer Cache也叫數據庫緩衝區高速緩存，是SGA中用來緩存已從數據文件中檢索到的數據塊的副本。說白了就是緩存最常用的段，以便儘可能減少訪問數據時物理磁盤I/O的次數。基本上Buffer Cache越大越好。
Shared Pool主要包括library cache和dictionary cache。library cache用來存儲最近解析（或編譯）過的SQL、PL/SQL語句及它們對應的hash值和執行計劃等。library cache用來存儲最近引用的數據字典。發生在library cache或dictionary cache的cache miss代價要比發生在buffer cache的代價高得多。因此shared pool的設置要確保最近使用的數據都能被cache。
Std Block Size是數據塊大小。
Log Buffer是重做日誌緩衝區大小。
Load Profile
|
|
Per Second | Per Transaction | Per Exec | Per Call |
|---|---|---|---|---|
| DB Time(s): | 3.3 | 4.4 | 0.00 | 0.00 |
| DB CPU(s): | 1.4 | 1.9 | 0.00 | 0.00 |
| Redo size: | 6,057.5 | 8,158.4 |
|
|
| Logical reads: | 125,528.3 | 169,064.1 |
|
|
| Block changes: | 5,191.4 | 6,991.9 |
|
|
| Physical reads: | 356.6 | 480.2 |
|
|
| Physical writes: | 25.5 | 34.3 |
|
|
| User calls: | 2,628.2 | 3,539.7 |
|
|
| Parses: | 1,180.0 | 1,589.2 |
|
|
| Hard parses: | 62.8 | 84.6 |
|
|
| W/A MB processed: | 0.6 | 0.8 |
|
|
| Logons: | 0.2 | 0.2 |
|
|
| Executes: | 1,185.8 | 1,597.1 |
|
|
| Rollbacks: | 0.0 | 0.0 |
|
|
| Transactions: | 0.7 |
|
|
|
Redo size：每秒產生的日誌大小(單位字節)，可標誌數據變更頻率, 數據庫任務的繁重與否。
Logical reads：每秒/每事務邏輯讀的塊數.平均每秒產生的邏輯讀的block數。Logical Reads= Consistent Gets + DB Block Gets
Block changes：每秒/每事務修改的塊數
Physical reads：每秒/每事務物理讀的塊數
Physical writes：每秒/每事務物理寫的塊數
User calls：每秒/每事務用戶call次數
Parses：SQL解析的次數.每秒解析次數，包括fast parse，soft parse和hard parse三種數量的綜合。 軟解析每秒超過300次意味着你的"應用程序"效率不高，調整session_cursor_cache。在這裏，fast
parse指的是直接在PGA中命中的情況（設置了session_cached_cursors=n）；soft parse是指在shared pool中命中的情形；hard parse則是指都不命中的情況。
Hard parses：其中硬解析的次數，硬解析太多，說明SQL重用率不高。每秒產生的硬解析次數, 每秒超過100次，就可能說明你變量綁定使用的不好，也可能是共享池設置不合理。這時候可以啓用參數cursor_sharing=similar|force，該參數默認值爲exact。但該參數設置爲similar時，存在bug，可能導致執行計劃的不優。
Sorts：每秒/每事務的排序次數
Logons：每秒/每事務登錄的次數
Executes：每秒/每事務SQL執行次數
Transactions：每秒事務數.每秒產生的事務數，反映數據庫任務繁重與否。
Blocks changed per Read：表示邏輯讀用於修改數據塊的比例.在每一次邏輯讀中更改的塊的百分比。
Recursive Call：遞歸調用佔所有操作的比率.遞歸調用的百分比，如果有很多PL/SQL，那麼這個值就會比較高。
Rollback per transaction：每事務的回滾率.看回滾率是不是很高，因爲回滾很耗資源 ,如果回滾率過高,可能說明你的數據庫經歷了太多的無效操作 ,過多的回滾可能還會帶來Undo Block的競爭 該參數計算公式如下: Round(User rollbacks / (user commits + user rollbacks) ,4)* 100% 。
Rows per Sort：每次排序的行數
注:
Oracle的硬解析和軟解析
提到軟解析(soft prase)和硬解析(hard prase)，就不能不說一下Oracle對sql的處理過程。當你發出一條sql語句交付Oracle，在執行和獲取結果前，Oracle對此sql將進行幾個步驟的處理過程：
1、語法檢查(syntax check) 檢查此sql的拼寫是否語法。
2、語義檢查(semantic check)
諸如檢查sql語句中的訪問對象是否存在及該用戶是否具備相應的權限。
3、對sql語句進行解析(prase)
利用內部算法對sql進行解析，生成解析樹(parse tree)及執行計劃(execution plan)。
4、執行sql，返回結果(execute and return) 其中，軟、硬解析就發生在第三個過程裏。
Oracle利用內部的hash算法來取得該sql的hash值，然後在library cache裏查找是否存在該hash值；
假設存在，則將此sql與cache中的進行比較； 假設“相同”，就將利用已有的解析樹與執行計劃，而省略了優化器的相關工作。這也就是軟解析的過程。
誠然，如果上面的2個假設中任有一個不成立，那麼優化器都將進行創建解析樹、生成執行計劃的動作。這個過程就叫硬解析。
創建解析樹、生成執行計劃對於sql的執行來說是開銷昂貴的動作，所以，應當極力避免硬解析，儘量使用軟解析。
Instance Efficiency Percentages (Target 100%)
| Buffer Nowait %: | 100.00 | Redo NoWait %: | 99.99 |
| Buffer Hit %: | 99.77 | In-memory Sort %: | 100.00 |
| Library Hit %: | 93.27 | Soft Parse %: | 94.68 |
| Execute to Parse %: | 0.49 | Latch Hit %: | 99.58 |
| Parse CPU to Parse Elapsd %: | 26.82 | % Non-Parse CPU: | 87.07 |
Buffer Nowait表示在內存獲得數據的未等待比例。在緩衝區中獲取Buffer的未等待比率。Buffer Nowait的這個值一般需要大於99%。否則可能存在爭用，可以在後面的等待事件中進一步確認。
buffer hit表示進程從內存中找到數據塊的比率，監視這個值是否發生重大變化比這個值本身更重要。對於一般的OLTP系統，如果此值低於80%，應該給數據庫分配更多的內存。數據塊在數據緩衝區中的命中率，通常應在95%以上。否則，小於95%，需要調整重要的參數，小於90%可能是要加db_cache_size。一個高的命中率，不一定代表這個系統的性能是最優的，比如大量的非選擇性的索引被頻繁訪問，就會造成命中率很高的假相（大量的db file sequential read），但是一個比較低的命中率，一般就會對這個系統的性能產生影響，需要調整。命中率的突變，往往是一個不好的信息。如果命中率突然增大，可以檢查top buffer get SQL，查看導致大量邏輯讀的語句和索引，如果命中率突然減小，可以檢查top physical reads SQL，檢查產生大量物理讀的語句，主要是那些沒有使用索引或者索引被刪除的。
Redo NoWait表示在LOG緩衝區獲得BUFFER的未等待比例。如果太低（可參考90%閥值），考慮增加LOG BUFFER。當redo buffer達到1M時，就需要寫到redo log文件，所以一般當redo buffer設置超過1M，不太可能存在等待buffer空間分配的情況。當前，一般設置爲2M的redo buffer，對於內存總量來說，應該不是一個太大的值。
library hit表示Oracle從Library Cache中檢索到一個解析過的SQL或PL/SQL語句的比率，當應用程序調用SQL或存儲過程時，Oracle檢查Library Cache確定是否存在解析過的版本，如果存在，Oracle立即執行語句；如果不存在，Oracle解析此語句，並在Library Cache中爲它分配共享SQL區。低的library hit ratio會導致過多的解析，增加CPU消耗，降低性能。如果library hit ratio低於90%，可能需要調大shared pool區。STATEMENT在共享區的命中率，通常應該保持在95%以上，否則需要要考慮：加大共享池；使用綁定變量；修改cursor_sharing等參數。
Latch Hit：Latch是一種保護內存結構的鎖，可以認爲是SERVER進程獲取訪問內存數據結構的許可。要確保Latch Hit>99%，否則意味着Shared Pool latch爭用，可能由於未共享的SQL，或者Library Cache太小，可使用綁定變更或調大Shared Pool解決。要確保>99%，否則存在嚴重的性能問題。當該值出現問題的時候，我們可以藉助後面的等待時間和latch分析來查找解決問題。
Parse CPU to Parse Elapsd：解析實際運行時間/(解析實際運行時間+解析中等待資源時間)，越高越好。計算公式爲：Parse CPU to Parse Elapsd %= 100*(parse time cpu / parse time elapsed)。即：解析實際運行時間/(解析實際運行時間+解析中等待資源時間)。如果該比率爲100%，意味着CPU等待時間爲0，沒有任何等待。
Non-Parse CPU ：SQL實際運行時間/(SQL實際運行時間+SQL解析時間)，太低表示解析消耗時間過多。計算公式爲：% Non-Parse CPU
=round(100*1-PARSE_CPU/TOT_CPU),2)。如果這個值比較小，表示解析消耗的CPU時間過多。與PARSE_CPU相比，如果TOT_CPU很高，這個比值將接近100%，這是很好的，說明計算機執行的大部分工作是執行查詢的工作，而不是分析查詢的工作。
Execute to Parse：是語句執行與分析的比例，如果要SQL重用率高，則這個比例會很高。該值越高表示一次解析後被重複執行的次數越多。計算公式爲：Execute to Parse =100 * (1 - Parses/Executions)。所以如果系統Parses > Executions，就可能出現該比率小於0的情況。該值<0通常說明shared pool設置或者語句效率存在問題，造成反覆解析，reparse可能較嚴重,或者是可能同snapshot有關，通常說明數據庫性能存在問題。 本例中這個值比較低，說明SQL重用率很低。
In-memory Sort：在內存中排序的比率，如果過低說明有大量的排序在臨時表空間中進行。考慮調大PGA(10g)。如果低於95%，可以通過適當調大初始化參數PGA_AGGREGATE_TARGET或者SORT_AREA_SIZE來解決，注意這兩個參數設置作用的範圍時不同的，SORT_AREA_SIZE是針對每個session設置的，PGA_AGGREGATE_TARGET則時針對所有的sesion的。
Soft Parse：軟解析的百分比（softs/softs+hards），近似當作sql在共享區的命中率，太低則需要調整應用使用綁定變量。sql在共享區的命中率，小於<95%,需要考慮綁定，如果低於80%，那麼就可以認爲sql基本沒有被重用。
Shared Pool Statistics
|
|
Begin | End |
|---|---|---|
| Memory Usage %: | 10.48 | 87.46 |
| % SQL with executions>1: | 53.16 | 68.92 |
| % Memory for SQL w/exec>1: | 45.97 | 87.21 |
SQL with executions>1：執行次數大於1的sql比率，如果此值太小，說明需要在應用中更多使用綁定變量，避免過多SQL解析。在一個趨向於循環運行的系統中，必須認真考慮這個數字。在這個循環系統中，在一天中相對於另一部分時間的部分時間裏執行了一組不同的SQL語句。在共享池中，在觀察期間將有一組未被執行過的SQL語句，這僅僅是因爲要執行它們的語句在觀察期間沒有運行。只有系統連續運行相同的SQL語句組，這個數字纔會接近100%。
Memory for SQL w/exec>1：執行次數大於1的SQL消耗內存的佔比。這是與不頻繁使用的SQL語句相比，頻繁使用的SQL語句消耗內存多少的一個度量。這個數字將在總體上與% SQL with executions>1非常接近，除非有某些查詢任務消耗的內存沒有規律。在穩定狀態下，總體上會看見隨着時間的推移大約有75%～85%的共享池被使用。如果Statspack報表的時間窗口足夠大到覆蓋所有的週期，執行次數大於一次的SQL語句的百分率應該接近於100%。這是一個受觀察之間持續時間影響的統計數字。可以期望它隨觀察之間的時間長度增大而增大。
小結：通過ORACLE的實例有效性統計數據，我們可以獲得大概的一個整體印象，然而我們並不能由此來確定數據運行的性能。當前性能問題的確定，我們主要還是依靠下面的等待事件來確認。我們可以這樣理解兩部分的內容，hit統計幫助我們發現和預測一些系統將要產生的性能問題，由此我們可以做到未雨綢繆。而wait事件，就是表明當前數據庫已經出現了性能問題需要解決，所以是亡羊補牢的性質。
Top 5 Timed Foreground Events
| Event | Waits | Time(s) | Avg wait (ms) | % DB time | Wait Class |
|---|---|---|---|---|---|
| DB CPU |
|
5,035 |
|
42.55 |
|
| db file sequential read | 682,689 | 444 | 1 | 3.75 | User I/O |
| db file scattered read | 40,279 | 160 | 4 | 1.35 | User I/O |
| library cache: mutex X | 334 | 78 | 234 | 0.66 | Concurrency |
| latch: shared pool | 3,896 | 71 | 18 | 0.60 | Concurrency |
一個性能良好的系統，cpu time應該在top 5的前面，否則說明你的系統大部分時間都用在等待上。
在這裏，log file parallel write是相對比較多的等待，佔用了7%的CPU時間。 通常，在沒有問題的數據庫中，CPU time總是列在第一個。 更多的等待事件，參見本報告 的Wait Events一節。
Host CPU (CPUs: 120 Cores: 60 Sockets: )
| Load Average Begin | Load Average End | %User | %System | %WIO | %Idle |
|---|---|---|---|---|---|
| 2.25 | 6.08 | 1.8 | 1.9 | 0.1 | 96.3 |
Instance CPU
| %Total CPU | %Busy CPU | %DB time waiting for CPU (Resource Manager) |
|---|---|---|
| 1.2 | 31.0 | 0.0 |
Memory Statistics
|
|
Begin | End |
|---|---|---|
| Host Mem (MB): | 51,200.0 | 51,200.0 |
| SGA use (MB): | 9,792.0 | 9,536.0 |
| PGA use (MB): | 188.1 | 329.4 |
| % Host Mem used for SGA+PGA: | 19.49 | 19.27 |
未完待續