AWR 報告分析(一)
WORKLOADREPOSITORY report for
DB Name |
DB Id |
Instance |
Inst num |
Release |
RAC |
Host |
ICCI |
1314098396 |
ICCI1 |
1 |
10.2.0.3.0 |
YES |
HPGICCI1 |
Snap Id |
Snap Time |
Sessions |
Cursors/Session |
|
Begin Snap: |
2678 |
25-Dec-08 14:04:50 |
24 |
1.5 |
End Snap: |
2680 |
25-Dec-08 15:23:37 |
26 |
1.5 |
Elapsed: |
78.79 (mins) |
|||
DB Time: |
11.05 (mins) |
DB Time不包括Oracle後臺程序消耗的時間。如果DB Time遠遠小於Elapsed時間,說明資料庫比較空閒。
在79分鐘裡(其間收集了3次快照資料),資料庫耗時11分鐘,RDA資料中顯示系統有8個邏輯CPU(4個物理CPU),平均每個CPU耗時1.4分鐘,CPU利用率只有大約2%(1.4/79)。說明系統壓力非常小。
可是對於批量系統,資料庫的工作負載總是集中在一段時間內。如果快照週期不在這一段時間內,或者快照週期跨度太長而包含了大量的資料庫空閒時間,所得出的分析結果是沒有意義的。這也說明選擇分析時間段很關鍵,要選擇能夠代表性能問題的時間段。
ReportSummary
Cache Sizes
Begin |
End |
|||
Buffer Cache: |
3,344M |
3,344M |
Std Block Size: |
8K |
Shared Pool Size: |
704M |
704M |
Log Buffer: |
14,352K |
顯示SGA中每個區域的大小(在AMM改變它們之後),可用來與初始引數值比較。
shared pool主要包括library cache和dictionary cache。library cache用來儲存最近解析(或編譯)後SQL、PL/SQL和Java classes等。library cache用來儲存最近引用的資料字典。發生在library cache或dictionary cache的cache miss代價要比發生在buffer cache的代價高得多。因此shared pool的設定要確保最近使用的資料都能被cache。
Load Profile
Per Second |
Per Transaction |
|
Redo size: |
918,805.72 |
775,912.72 |
Logical reads: |
3,521.77 |
2,974.06 |
Block changes: |
1,817.95 |
1,535.22 |
Physical reads: |
68.26 |
57.64 |
Physical writes: |
362.59 |
306.20 |
User calls: |
326.69 |
275.88 |
Parses: |
38.66 |
32.65 |
Hard parses: |
0.03 |
0.03 |
Sorts: |
0.61 |
0.51 |
Logons: |
0.01 |
0.01 |
Executes: |
354.34 |
299.23 |
Transactions: |
1.18 |
% Blocks changed per Read: |
51.62 |
Recursive Call %: |
51.72 |
Rollback per transaction %: |
85.49 |
Rows per Sort: |
######## |
顯示資料庫負載概況,將之與基線資料比較才具有更多的意義,如果每秒或每事務的負載變化不大,說明應用執行比較穩定。單個的報告資料只說明應用的負載情況,絕大多資料並沒有一個所謂“正確”的值,然而Logons大於每秒1~2個、Hard parses大於每秒100、全部parses超過每秒300表明可能有爭用問題。
Redo size:每秒/每事務產生的redo大小(單位位元組),可標誌資料庫任務的繁重程式。
Logical reads:每秒/每事務邏輯讀的塊數
Block changes:每秒/每事務修改的塊數
Physical reads:每秒/每事務物理讀的塊數
Physical writes:每秒/每事務物理寫的塊數
User calls:每秒/每事務使用者call次數
Parses:SQL解析的次數
Hard parses:其中硬解析的次數,硬解析太多,說明SQL重用率不高。
Sorts:每秒/每事務的排序次數
Logons:每秒/每事務登入的次數
Executes:每秒/每事務SQL執行次數
Transactions:每秒事務數
Blocks changed per Read:表示邏輯讀用於修改資料塊的比例
Recursive Call:遞迴呼叫佔所有操作的比率
Rollback pertransaction:每事務的回滾率
Rows per Sort:每次排序的行數
注:
Oracle的硬解析和軟解析
提到軟解析(soft parse)和硬解析(hard parse),就不能不說一下Oracle對sql的處理過程。當你發出一條sql語句交付Oracle,在執行和獲取結果前,Oracle對此sql將進行幾個步驟的處理過程:
1、語法檢查(syntax check)
檢查此sql的拼寫是否語法。
2、語義檢查(semantic check)
諸如檢查sql語句中的訪問物件是否存在及該使用者是否具備相應的許可權。
3、對sql語句進行解析(parse)
利用內部演算法對sql進行解析,生成解析樹(parsetree)及執行計劃(execution plan)。
4、執行sql,返回結果(executeand return)
其中,軟、硬解析就發生在第三個過程裡。
Oracle利用內部的hash演算法來取得該sql的hash值,然後在librarycache裡查詢是否存在該hash值;
假設存在,則將此sql與cache中的進行比較;
假設“相同”,就將利用已有的解析樹與執行計劃,而省略了優化器的相關工作。這也就是軟解析的過程。
誠然,如果上面的2個假設中任有一個不成立,那麼優化器都將進行建立解析樹、生成執行計劃的動作。這個過程就叫硬解析。
建立解析樹、生成執行計劃對於sql的執行來說是開銷昂貴的動作,所以,應當極力避免硬解析,儘量使用軟解析。
Instance Efficiency Percentages (Target 100%)
Buffer Nowait %: |
100.00 |
Redo NoWait %: |
100.00 |
Buffer Hit %: |
98.72 |
In-memory Sort %: |
99.86 |
Library Hit %: |
99.97 |
Soft Parse %: |
99.92 |
Execute to Parse %: |
89.09 |
Latch Hit %: |
99.99 |
Parse CPU to Parse Elapsd %: |
7.99 |
% Non-Parse CPU: |
99.95 |
本節包含了Oracle關鍵指標的記憶體命中率及其它資料庫例項操作的效率。其中Buffer HitRatio 也稱Cache HitRatio,Library Hitratio也稱LibraryCache Hit ratio。同Load Profile一節相同,這一節也沒有所謂“正確”的值,而只能根據應用的特點判斷是否合適。在一個使用直接讀執行大型並行查詢的DSS環境,20%的Buffer Hit Ratio是可以接受的,而這個值對於一個OLTP系統是完全不能接受的。根據Oracle的經驗,對於OLTPT系統,Buffer Hit Ratio理想應該在90%以上。
Buffer Nowait表示在記憶體獲得資料的未等待比例。
buffer hit表示程序從記憶體中找到資料塊的比率,監視這個值是否發生重大變化比這個值本身更重要。對於一般的OLTP系統,如果此值低於80%,應該給資料庫分配更多的記憶體。
Redo NoWait表示在LOG緩衝區獲得BUFFER的未等待比例。如果太低(可參考90%閥值),考慮增加LOG 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區。
Latch Hit:Latch是一種保護記憶體結構的鎖,可以認為是SERVER程序獲取訪問記憶體資料結構的許可。要確保Latch Hit>99%,否則意味著Shared Pool latch爭用,可能由於未共享的SQL,或者Library Cache太小,可使用繫結變更或調大Shared Pool解決。
Parse CPU to ParseElapsd:解析實際執行時間/(解析實際執行時間+解析中等待資源時間),越高越好。
Non-Parse CPU :SQL實際執行時間/(SQL實際執行時間+SQL解析時間),太低表示解析消耗時間過多。
Execute to Parse:是語句執行與分析的比例,如果要SQL重用率高,則這個比例會很高。該值越高表示一次解析後被重複執行的次數越多。
In-memory Sort:在記憶體中排序的比率,如果過低說明有大量的排序在臨時表空間中進行。考慮調大PGA。
Soft Parse:軟解析的百分比(softs/softs+hards),近似當作sql在共享區的命中率,太低則需要調整應用使用繫結變數。
Shared Pool Statistics
Begin |
End |
|
Memory Usage %: |
47.19 |
47.50 |
% SQL with executions>1: |
88.48 |
79.81 |
% Memory for SQL w/exec>1: |
79.99 |
73.52 |
Memory Usage %:對於一個已經執行一段時間的資料庫來說,共享池記憶體使用率,應該穩定在75%-90%間,如果太小,說明Shared Pool有浪費,而如果高於90,說明共享池中有爭用,記憶體不足。
SQL with executions>1:執行次數大於1的sql比率,如果此值太小,說明需要在應用中更多使用繫結變數,避免過多SQL解析。
Memory for SQL w/exec>1:執行次數大於1的SQL消耗記憶體的佔比。
Top 5 Timed Events
Event |
Waits |
Time(s) |
Avg Wait(ms) |
% Total Call Time |
Wait Class |
CPU time |
515 |
77.6 |
|||
SQL*Net more data from client |
27,319 |
64 |
2 |
9.7 |
Network |
log file parallel write |
5,497 |
47 |
9 |
7.1 |
System I/O |
db file sequential read |
7,900 |
35 |
4 |
5.3 |
User I/O |
db file parallel write |
4,806 |
34 |
7 |
5.1 |
System I/O |
這是報告概要的最後一節,顯示了系統中最嚴重的5個等待,按所佔等待時間的比例倒序列示。當我們調優時,總希望觀察到最顯著的效果,因此應當從這裡入手確定我們下一步做什麼。例如如果‘buffer busy wait’是較嚴重的等待事件,我們應當繼續研究報告中Buffer Wait和File/Tablespace IO區的內容,識別哪些檔案導致了問題。如果最嚴重的等待事件是I/O事件,我們應當研究按物理讀排序的SQL語句區以識別哪些語句在執行大量I/O,並研究Tablespace和I/O區觀察較慢響應時間的檔案。如果有較高的LATCH等待,就需要察看詳細的LATCH統計識別哪些LATCH產生的問題。
在這裡,log fileparallel write是相對比較多的等待,佔用了7%的CPU時間。
通常,在沒有問題的資料庫中,CPUtime總是列在第一個。
更多的等待事件,參見本報告 的Wait Events一節。
RACStatistics
Begin |
End |
|
Number of Instances: |
2 |
2 |
Global Cache Load Profile
Per Second |
Per Transaction |
|
Global Cache blocks received: |
4.16 |
3.51 |
Global Cache blocks served: |
5.97 |
5.04 |
GCS/GES messages received: |
408.47 |
344.95 |
GCS/GES messages sent: |
258.03 |
217.90 |
DBWR Fusion writes: |
0.05 |
0.05 |
Estd Interconnect traffic (KB) |
211.16 |
Global Cache Efficiency Percentages (Target local+remote 100%)
Buffer access - local cache %: |
98.60 |
Buffer access - remote cache %: |
0.12 |
Buffer access - disk %: |
1.28 |
Global Cache and Enqueue Services - Workload Characteristics
Avg global enqueue get time (ms): |
0.1 |
Avg global cache cr block receive time (ms): |
1.1 |
Avg global cache current block receive time (ms): |
0.8 |
Avg global cache cr block build time (ms): |
0.0 |
Avg global cache cr block send time (ms): |
0.0 |
Global cache log flushes for cr blocks served %: |
3.5 |
Avg global cache cr block flush time (ms): |
3.9 |
Avg global cache current block pin time (ms): |
0.0 |
Avg global cache current block send time (ms): |
0.0 |
Global cache log flushes for current blocks served %: |
0.4 |
Avg global cache current block flush time (ms): |
3.0 |
Global Cache and Enqueue Services - Messaging Statistics
Avg message sent queue time (ms): |
0.0 |
Avg message sent queue time on ksxp (ms): |
0.3 |
Avg message received queue time (ms): |
0.5 |
Avg GCS message process time (ms): |
0.0 |
Avg GES message process time (ms): |
0.0 |
% of direct sent messages: |
14.40 |
% of indirect sent messages: |
77.04 |
% of flow controlled messages: |
8.56 |
Main Report
Wait Events Statistics
Time Model Statistics
- Total time in database user-calls (DB Time): 663s
- Statistics including the word "background" measure background process time, and so do not contribute to the DB time statistic
- Ordered by % or DB time desc, Statistic name
Statistic Name |
Time (s) |
% of DB Time |
DB CPU |
514.50 |
77.61 |
sql execute elapsed time |
482.27 |
72.74 |
parse time elapsed |
3.76 |
0.57 |
PL/SQL execution elapsed time |
0.50 |
0.08 |
hard parse elapsed time |
0.34 |
0.05 |
connection management call elapsed time |
0.08 |
0.01 |
hard parse (sharing criteria) elapsed time |
0.00 |
0.00 |
repeated bind elapsed time |
0.00 |
0.00 |
PL/SQL compilation elapsed time |
0.00 |
0.00 |
failed parse elapsed time |
0.00 |
0.00 |
DB time |
662.97 |
|
background elapsed time |
185.19 |
|
background cpu time |
67.48 |
此節顯示了各種型別的資料庫處理任務所佔用的CPU時間。
Wait Class
- s - second
- cs - centisecond - 100th of a second
- ms - millisecond - 1000th of a second
- us - microsecond - 1000000th of a second
- ordered by wait time desc, waits desc
Wait Class |
Waits |
%Time -outs |
Total Wait Time (s) |
Avg wait (ms) |
Waits /txn |
User I/O |
66,837 |
0.00 |
120 |
2 |
11.94 |
System I/O |
28,295 |
0.00 |
93 |
3 |
5.05 |
Network |
1,571,450 |
0.00 |
66 |
0 |
280.72 |
Cluster |
210,548 |
0.00 |
29 |
0 |
37.61 |
Other |
81,783 |
71.82 |
28 |
0 |
14.61 |
Application |
333,155 |
0.00 |
16 |
0 |
59.51 |
Concurrency |
5,182 |
0.04 |
5 |
1 |
0.93 |
Commit |
919 |
0.00 |
4 |
4 |
0.16 |
Configuration |
25,427 |
99.46 |
1 |
0 |
4.54 |
Wait Events
- s - second
- cs - centisecond - 100th of a second
- ms - millisecond - 1000th of a second
- us - microsecond - 1000000th of a second
- ordered by wait time desc, waits desc (idle events last)
Event |
Waits |
%Time -outs |
Total Wait Time (s) |
Avg wait (ms) |
Waits /txn |
SQL*Net more data from client |
27,319 |
0.00 |
64 |
2 |
4.88 |
log file parallel write |
5,497 |
0.00 |
47 |
9 |
0.98 |
db file sequential read |
7,900 |
0.00 |
35 |
4 |
1.41 |
db file parallel write |
4,806 |
0.00 |
34 |
7 |
0.86 |
db file scattered read |
10,310 |
0.00 |
31 |
3 |
1.84 |
direct path write |
42,724 |
0.00 |
30 |
1 |
7.63 |
reliable message |
355 |
2.82 |
18 |
49 |
0.06 |
SQL*Net break/reset to client |
333,084 |
0.00 |
16 |
0 |
59.50 |
db file parallel read |
3,732 |
0.00 |
13 |
4 |
0.67 |
gc current multi block request |
175,710 |
0.00 |
10 |
0 |
31.39 |
control file sequential read |
15,974 |
0.00 |
10 |
1 |
2.85 |
direct path read temp |
1,873 |
0.00 |
9 |
5 |
0.33 |
gc cr multi block request |
20,877 |
0.00 |
8 |
0 |
3.73 |
log file sync |
919 |
0.00 |
4 |
4 |
0.16 |
gc cr block busy |
526 |
0.00 |
3 |
6 |
0.09 |
enq: FB - contention |
10,384 |
0.00 |
3 |
0 |
1.85 |
DFS lock handle |
3,517 |
0.00 |
3 |
1 |
0.63 |
control file parallel write |
1,946 |
0.00 |
3 |
1 |
0.35 |
gc current block 2-way |
4,165 |
0.00 |
2 |
0 |
0.74 |
library cache lock |
432 |
0.00 |
2 |
4 |
0.08 |
name-service call wait |
22 |
0.00 |
2 |
76 |
0.00 |
row cache lock |
3,894 |
0.00 |
2 |
0 |
0.70 |
gcs log flush sync |
1,259 |
42.02 |
2 |
1 |
0.22 |
os thread startup |
18 |
5.56 |
2 |
89 |
0.00 |
gc cr block 2-way |
3,671 |
0.00 |
2 |
0 |
0.66 |
gc current block busy |
113 |
0.00 |
1 |
12 |
0.02 |
SQL*Net message to client |
1,544,115 |
0.00 |
1 |
0 |
275.83 |
gc buffer busy |
15 |
6.67 |
1 |
70 |
0.00 |
gc cr disk read |
3,272 |
0.00 |
1 |
0 |
0.58 |
direct path write temp |
159 |
0.00 |
1 |
5 |
0.03 |
gc current grant busy |
898 |
0.00 |
1 |
1 |
0.16 |
log file switch completion |
29 |
0.00 |
1 |
17 |
0.01 |
CGS wait for IPC msg |
48,739 |
99.87 |
0 |
0 |
8.71 |
gc current grant 2-way |
1,142 |
0.00 |
0 |
0 |
0.20 |
kjbdrmcvtq lmon drm quiesce: ping completion |
9 |
0.00 |
0 |
19 |
0.00 |
enq: US - contention |
567 |
0.00 |
0 |
0 |
0.10 |
direct path read |
138 |
0.00 |
0 |
1 |
0.02 |
enq: WF - contention |
14 |
0.00 |
0 |
9 |
0.00 |
ksxr poll remote instances |
13,291 |
58.45 |
0 |
0 |
2.37 |
library cache pin |
211 |
0.00 |
0 |
1 |
0.04 |
ges global resource directory to be frozen |
9 |
100.00 |
0 |
10 |
0.00 |
wait for scn ack |
583 |
0.00 |
0 |
0 |
0.10 |
log file sequential read |
36 |
0.00 |
0 |
2 |
0.01 |
undo segment extension |
25,342 |
99.79 |
0 |
0 |
4.53 |
rdbms ipc reply |
279 |
0.00 |
0 |
0 |
0.05 |
ktfbtgex |
6 |
100.00 |
0 |
10 |
0.00 |
enq: HW - contention |
44 |
0.00 |
0 |
1 |
0.01 |
gc cr grant 2-way |
158 |
0.00 |
0 |
0 |
0.03 |
enq: TX - index contention |
1 |
0.00 |
0 |
34 |
0.00 |
enq: CF - contention |
64 |
0.00 |
0 |
1 |
0.01 |
PX Deq: Signal ACK |
37 |
21.62 |
0 |
1 |
0.01 |
latch free |
3 |
0.00 |
0 |
10 |
0.00 |
buffer busy waits |
625 |
0.16 |
0 |
0 |
0.11 |
KJC: Wait for msg sends to complete |
154 |
0.00 |
0 |
0 |
0.03 |
log buffer space |
11 |
0.00 |
0 |
2 |
0.00 |
enq: PS - contention |
46 |
0.00 |
0 |
1 |
0.01 |
enq: TM - contention |
70 |
0.00 |
0 |
0 |
0.01 |
IPC send completion sync |
40 |
100.00 |
0 |
0 |
0.01 |
PX Deq: reap credit |
1,544 |
99.81 |
0 |
0 |
0.28 |
log file single write |
36 |
0.00 |
0 |
0 |
|