WORKLOAD REPOSITORY 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）。說明系統壓力非常小。

可是對於批次系統，資料庫的工作負載總是集中在一段時間內。如果快照週期不在這一段時間內，或者快照週期跨度太長而包含了大量的資料庫空閒時間，所得出的分析結果是沒有意義的。這也說明選擇分析時間段很關鍵，要選擇能夠代表效能問題的時間段。

Report Summary

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 per transaction：每事務的回滾率

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 %:	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 Hit Ratio 也稱Cache Hit Ratio，Library Hit ratio也稱Library Cache 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 Parse Elapsd：解析實際執行時間/(解析實際執行時間+解析中等待資源時間)，越高越好。

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 file parallel write是相對比較多的等待，佔用了7%的CPU時間。

通常，在沒有問題的資料庫中，CPU time總是列在第一個。

更多的等待事件，參見本報告的Wait Events一節。

RAC Statistics

	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

詳細的AWR解析報告