AWR通過比較從兩個快照收集的統計信息來生成報告數據，並且生成的報告包括多個部分。
工作量資料檔案庫報告
數據庫名稱
數據庫Id
情況
儀器編號
釋放；排放；發布
皇家汽車俱樂部
主持
ICCI
1314098396
ICCI1
1
10.2.0.3.0
是
HPGICCI1
快照Id
階躍時間
會議
光標/會話
開始捕捉:
2678
14:04:50
24
1.5
結束捕捉:
2680
15:23:37
26
1.5
經過時間:
78.79分鐘
數據庫時間:
11.05(分鐘)
數據庫時間不包括Oracle守護進程消耗的時間。如果數據庫時間遠小於運行時間，則數據庫處於空閑狀態。
Db時間= cpu時間+等待時間(不包括空閑等待)(非後臺進程)
說白了，db time就是服務器記錄的數據庫操作(非後臺進程)和等待(非空閑等待)的時間。
數據庫時間= cpu時間+所有非空閑等待事件時間
79分鐘(期間收集了3個快照數據)，數據庫用時11分鐘，RDA數據顯示系統有8個邏輯CPU(4個物理CPU)。
平均每個CPU用時1.4分鐘，CPU利用率只有2%左右(1.4/79)。說明系統壓力很小。
列舉以下兩個來說明:
報告A:
快照Id快照時間會話光標/會話
- - - -
開始捕捉:4610 2008年7月24日22:00:54 68 19.1
結束捕捉:4612 2008年7月24日23:00:25 17 1.7
耗時:59.51(分鐘)
數據庫時間:466.37分鐘
報告B:
快照Id快照時間會話光標/會話
- - - -
開始拍攝:3098 13-11-07 21:00:37 39 13.6
結束快照:3102 17年11月3日22:00:15 40 16.4
耗時:59.63分鐘
數據庫時間:19.49分鐘
該服務器是壹個AIX系統，具有4個雙核CPU和* * * 8個內核:
/sbin & gt；綁定處理器-q
可用的處理器有:0 1 2 3 4 5 6 7
先說報告A。快照區間，總* * *約60分鐘，cpu有60 * * 8 = 480分鐘，DB時間466.37分鐘。
然後:cpu在處理Oralce非空閑等待和操作(如邏輯讀取)上花費了466.37分鐘。
也就是說，466.37/480*100%的cpu都花在處理Oracle操作上，這還不包括後臺進程。
看報表B，大概需要60分鐘，cpu在Oracle操作上花費19.49/480*100%。
顯然，報告B中服務器的平均負載非常低。
您可以從awr報告的運行時間和數據庫時間中大致了解數據庫的負載。
但是，對於批處理系統，數據庫的工作量總是集中在壹段時間內。如果快照時間段不在該時間段內，
或者快照周期跨度太長，包含數據庫大量空閑時間，分析結果沒有意義。
這也說明選擇分析時間段很重要，可以代表性能問題。
報告摘要
緩存大小
開始
結束
緩沖區緩存:
3344米
3344米
標準塊大小:
8K
共享池大小:
704米
704米
日誌緩沖區:
14352k
顯示SGA每個區域的大小(AMM更改後)，可用於與初始參數值進行比較。
共享池主要包括庫緩存和字典緩存。
庫緩存用於存儲SQL、PL/SQL、Java類等。經過最近的解析(或編譯)。
字典緩存用於存儲最近引用的數據字典。
庫緩存或字典緩存中的緩存未命中成本遠高於緩沖區緩存。
因此，共享池的設置應該保證最近使用的數據可以被緩存。
負載曲線
每秒鐘
每筆交易
重做大小:
918,805.72
775,912.72
邏輯讀取:
3,521.77
2,974.06
阻止更改:
1,817.95
1,535.22
物理讀取:
68.26
57.64
物理寫入:
362.59
306.20
用戶呼叫:
326.69
275.88
解析:
38.66
32.65
硬解析:
0.03
0.03
排序:
0.61
0.51
登錄:
0.01
0.01
執行:
354.34
299.23
交易:
1.18
每次讀取更改的塊數百分比:
51.62
遞歸調用%:
51.72
每個事務的回滾百分比:
85.49
每次排序的行數:
########
顯示數據庫負載概要並將其與基線數據進行比較更有意義。如果每秒或每個事務的負載變化不大，應用程序運行穩定。
單個報表數據只顯示應用的負載，大部分數據沒有所謂的“正確”值。然而，
每秒大於1~2的登錄、每秒大於100的硬解析以及每秒超過300的所有解析都表明可能存在爭用問題。
重做大小:每秒生成的日誌大小(以字節為單位)，可以表示數據更改的頻率以及數據庫任務是否繁重。
邏輯讀取:每秒/每個事務的邏輯讀取次數。每秒生成的邏輯讀取數。邏輯讀取數=壹致獲取數+數據庫塊獲取數
塊更改:每秒/每個事務修改的塊數。
物理讀取:每秒/每個事務物理讀取的塊數。
物理寫入:每秒/每個事務實際寫入的塊數。
用戶調用:每秒/事務的用戶調用數。
語法分析:SQL語法分析的數量。每秒的分析次數，包括快速分析、軟分析和硬分析的綜合。
每秒300次以上的軟解析意味著妳的“應用”效率低下。調整session_cursor_cache。
這裏快速解析指的是PGA中的直接命中(set session _ cached _ cursors = n)；
軟解析是指在共享池中命中的情況；硬解析指的是它們都不命中的情況。
硬解析:其中，硬解析的數量太多，說明SQL的復用率不高。
每秒生成的硬解析次數，超過每秒100次，可能說明妳的綁定沒有用好，也可能是* * *的池設置不合理。
此時可以啟用參數cursor_sharing=similar|force，該參數的默認值為exact。但是，當這個參數設置為similar時，存在壹個bug，可能導致執行計劃不佳。
排序:每秒/事務的排序次數。
Logons:每秒/事務的登錄次數。
執行次數:每秒/事務執行的SQL次數。
Transactions:每秒的事務數。每秒生成的事務數量反映了數據庫任務是否繁重。
每次讀取更改的塊數:表示用於修改數據塊的邏輯讀取的比例。每次邏輯讀取中更改的塊的百分比。
遞歸調用:遞歸調用占所有操作的比率。如果有很多PL/SQL，遞歸調用的百分比會更高。
每個事務的回滾:每個事務的回滾速率。看回滾率是不是很高，因為回滾很消耗資源。如果回滾速率太高，
可能說明妳的數據庫經歷了太多的無效操作，太多的回滾也可能帶來撤銷塊的競爭。
該參數的計算公式如下:Round(用戶回滾/(用戶承諾+用戶回滾)，4) * 100%。
每次排序的行數:每次排序的行數。
註意:
Oracle的硬解析和軟解析
說到軟解析和硬prase，就不能不談Oracle對sql的處理了。
當您向Oracle發送sql語句時，Oracle將在執行和獲取結果之前分幾個步驟處理sql:
1，語法檢查(語法檢查)
檢查此sql的拼寫是否符合語法。
2.語義檢查
比如檢查sql語句中的access對象是否存在，用戶是否有相應的權限。
3.請簡述sql語句。
Sql由內部算法解析，生成解析樹和執行計劃。
4.執行sql並返回結果。
其中，軟硬分析發生在第三個過程。
Oracle使用內部散列算法獲得sql的散列值，然後查找該散列值是否存在於庫高速緩存中。
如果存在，將該sql與緩存中的SQL進行比較；
假設“相同”，將使用現有的解析樹和執行計劃，並省略優化器的相關工作。這也是軟解析的過程。
誠然，如果上述兩個假設中的任何壹個不成立，那麽優化器將創建壹個解析樹並生成壹個執行計劃。這個過程稱為硬解析。
創建解析樹和生成執行計劃對於sql執行來說是開銷很大的操作，所以應該避免硬解析，盡可能使用軟解析。
實例效率百分比(目標100%)
緩沖區Nowait %:
100.00
重做NoWait %:
100.00
緩沖區命中率%:
98.72
內存中排序百分比:
99.86
庫命中率%:
99.97
軟解析%:
99.92
執行以解析%:
89.09
閂鎖命中率%:
99.99
解析CPU以解析Elapsd %:
7.99
%非解析CPU:
99.95
此部分包含Oracle關鍵指標的內存命中率以及其他數據庫實例操作的效率。緩沖區命中率也稱為緩存命中率，
庫命中率也稱為庫緩存命中率。
和Load Profile這壹節壹樣，這壹節沒有所謂的“正確”值，只能根據應用的特性來判斷。
在使用直接讀取來執行大型並行查詢的DSS環境中，20%的緩沖區命中率是可以接受的，但對於OLTP系統來說，這是完全不可接受的。
根據Oracle的經驗，對於OLTP系統，理想的緩沖區命中率應該在90%以上。
Buffer Nowait表示在不等待的情況下在內存中獲得的數據的比例。獲取緩沖區中緩沖區的等待比率。
Buffer Nowait的這個值通常需要大於99%。否則可能會出現爭用，這可以在後面的等待事件中進壹步證實。
緩沖區命中表示進程從內存中找到數據塊的速率，監視該值是否比該值本身有顯著變化更重要。
對於壹般的OLTP系統，如果這個值低於80%，應該給數據庫分配更多的內存。
數據緩沖區中數據塊的命中率通常應該在95%以上。否則，如果小於95%，則需要調整重要參數，如果小於90%，則可能需要添加db_cache_size。
高命中率並不壹定意味著系統的性能是最優的。比如大量的非選擇性索引被頻繁訪問，會造成很高的命中率(大量的db文件順序讀取)。
但是相對較低的命中率壹般會影響這個系統的性能，需要進行調整。命中率的突然變化往往是壹個不好的信息。
如果命中率突然增加，可以檢查top buffer get SQL來查看導致大量邏輯讀取的語句和索引。
如果命中率突然下降，可以檢查top physical reads SQL，檢查產生大量物理讀取的語句，主要是那些沒有使用過索引或者索引已經被刪除的語句。
Redo NoWait表示在日誌緩沖區中獲得緩沖區的等待比率。如果太低(參考90%閾值)，考慮增加日誌緩沖區。
當重做緩沖區達到1M時，需要寫入重做日誌文件，所以壹般當重做緩沖區設置超過1M時，不太可能出現等待緩沖區空間分配的情況。
目前，重做緩沖區(通常設置為2M)對於內存總量來說不應該是壹個太大的值。
庫命中表示Oracle從庫高速緩存中檢索已解析的SQL或PL/SQL語句的速率。當應用程序調用SQL或存儲過程時，
Oracle檢查庫緩存以確定是否有已解析的版本，如果有，Oracle立即執行該語句；如果不存在，Oracle將解析該語句，並在庫緩存中為其分配* * * SQL區域。
低的庫命中率會導致過多的解析，增加CPU消耗，降低性能。
如果庫命中率低於90%，您可能需要增加共享池區域。
* * *享受區的語句命中率通常要保持在95%以上，否則需要考慮:增加* * *享受池；使用綁定變量；修改cursor_sharing等參數。
Latch Hit:Latch是保護內存結構的鎖，可以認為是服務器進程訪問內存數據結構的權限。
確保閂鎖命中& gt99%，否則意味著共享池閂鎖爭用，可能是因為SQL不是* * *，或者庫緩存太小，可以通過改變綁定或者增加共享池來解決。
確保> 99%，否則存在嚴重的性能問題。當這個值出現問題時，我們可以使用等待時間和閂鎖分析來查找和解決問題。
解析CPU解析Elapsd:解析實際運行時間/(解析實際運行時間+解析中等待資源時間)，越高越好。
計算公式為:解析CPU解析經過時間% = 100 *(解析時間CPU/解析時間經過時間)。
即:解析的實際運行時間/(解析的實際運行時間+資源在解析中的等待時間)。如果比值為100%，說明CPU等待時間為0，沒有等待。
非解析CPU :SQL實際運行時間/(SQL實際運行時間+SQL解析時間)，太低說明解析消耗時間太多。
計算公式為:%非解析CPU = round(100 * 1-parse _ CPU/tot _ CPU)，2)。如果這個值很小，就意味著解析消耗了太多的CPU時間。
與PARSE_CPU相比，如果TOT_CPU高，比率將接近100%，這是非常好的，說明計算機執行的大部分工作是執行查詢的工作，而不是分析查詢的工作。
執行到解析:是語句執行到分析的比例，如果SQL的復用率高，這個比例會很高。該值越高，解析後重復執行的次數就越多。
計算公式為:執行到解析= 100 *(1-解析次數/執行次數)。
在這個例子中，幾乎每次執行都需要解析5次。因此，如果系統解析>:Executions，該比率可能小於0。
價值
內存排序:內存中排序的比率。如果太低，意味著臨時表空間中有大量排序。
考慮增加PGA(10g)。如果低於95%，可以通過適當增加初始化參數PGA_AGGREGATE_TARGET或SORT_AREA_SIZE來解決。
註意，這兩個參數的範圍是不同的。SORT_AREA_SIZE是為每個會話設置的，而PGA_AGGREGATE_TARGET是為所有會話設置的。
Softpparse:軟解析(softs/softs+hards)的百分比，大概算是* * *享受區sql的命中率。如果太低，就需要調整應用程序使用的綁定變量。
sql在* * *享受區的命中率不到
共享池統計信息
開始
結束
內存使用百分比:
47.19
47.50
% SQL with executions & gt1:
88.48
79.81
帶有exec >的SQL內存百分比；1:
79.99
73.52
內存使用率%:對於已經運行了壹段時間的數據庫，共享池的內存使用率應該穩定在75%-90%。
如果太小，說明共享池很浪費，如果高於90，說明* * *共享池存在爭用，內存不夠。
這個數字應該會長期穩定在75% ~ 90%。如果這個百分比過低，說明* * *共享池設置過大，會帶來額外的管理負擔，在某些情況下會導致性能下降。
如果這個百分比太高，那麽* * *共享池之外的組件就會老化，如果再次執行SQL語句，就會使SQL語句難以解析。
在規模適當的系統中，* * *共享池的利用率將在75%到略低於90%的範圍內。
帶執行的SQL with1:執行時間大於1的sql比率。如果這個值太小，就意味著需要在應用程序中使用更多的綁定變量，以避免過多的SQL解析。