ORACLE AWR報告詳細分析

AWR 是 Oracle 10g 版本推出的新特性，全稱叫Automatic Workload Repository-自動負載資訊庫
AWR 是透過對比兩次快照(snapshot)收集到的統計資訊，來生成報表資料，生成的報表包括多個部分。

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時間，說明資料庫比較空閒。
db time= cpu time + wait time（不包含空閒等待）（非後臺程式）
說白了就是db time就是記錄的伺服器花在資料庫運算(非後臺程式)和等待(非空閒等待)上的時間
DB time = cpu time + all of nonidle wait event time

在79分鐘裡（其間收集了3次快照資料），資料庫耗時11分鐘，RDA資料中顯示系統有8個邏輯CPU（4個物理CPU），
平均每個CPU耗時1.4分鐘，CPU利用率只有大約2%（1.4/79）。說明系統壓力非常小。

列出下面這兩個來做解釋：
Report A:
Snap Id Snap Time Sessions Curs/Sess
--------- ------------------- -------- ---------
Begin Snap: 4610 24-Jul-08 22:00:54 68 19.1
End Snap: 4612 24-Jul-08 23:00:25 17 1.7
Elapsed: 59.51 (mins)
DB Time: 466.37 (mins)

Report B:
Snap Id Snap Time Sessions Curs/Sess
--------- ------------------- -------- ---------
Begin Snap: 3098 13-Nov-07 21:00:37 39 13.6
End Snap: 3102 13-Nov-07 22:00:15 40 16.4
Elapsed: 59.63 (mins)
DB Time: 19.49 (mins)

伺服器是AIX的系統，4個雙核cpu,共8個核:

/sbin> bindprocessor -q
The available processors are: 0 1 2 3 4 5 6 7

先說Report A,在snapshot間隔中，總共約60分鐘，cpu就共有60*8=480分鐘，DB time為466.37分鐘
則：cpu花費了466.37分鐘在處理Oralce非空閒等待和運算上(比方邏輯讀)
也就是說cpu有 466.37/480*100% 花費在處理Oracle的操作上，這還不包括後臺程式
看Report B，總共約60分鐘，cpu有 19.49/480*100% 花費在處理Oracle的操作上
很顯然，Report B中伺服器的平均負載很低。
從awr report的Elapsed time和DB Time就能大概瞭解db的負載。

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

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等。
dictionary 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：每秒產生的日誌大小(單位位元組)，可標誌資料變更頻率, 資料庫任務的繁重與否。

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 %:	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的經驗，對於系統，Buffer Hit Ratio理想應該在90%以上。

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)。
本例中，差不多每execution 5次需要一次parse。所以如果系統Parses > Executions，就可能出現該比率小於0的情況。
該值<0通常說明shared pool設定或者語句效率存在問題，造成反覆解析，reparse可能較嚴重,或者是可能同snapshot有關，通常說明資料庫效能存在問題。

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 %:	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，說明共享池中有爭用，記憶體不足。
這個數字應該長時間穩定在75%～90%。如果這個百分比太低，表明共享池設定過大，帶來額外的管理上的負擔，從而在某些條件下會導致效能的下降。
如果這個百分率太高，會使共享池外部的元件老化，如果SQL語句被再次執行，這將使得SQL語句被硬解析。
在一個大小合適的系統中，共享池的使用率將處於75%到略低於90%的範圍內.

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 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產生的問題。

一個效能良好的系統，cpu time應該在top 5的前面，否則說明你的系統大部分時間都用在等待上。

在這裡，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

Main Report

Wait Events Statistics

/* oracle等待事件是衡量oracle執行狀況的重要依據及指示，等待事件分為兩類：
空閒等待事件和非空閒等待事件, TIMED_STATISTICS = TRUE 那麼等待事件按等待的時間排序，= FALSE那麼事件按等待的數量排序。
執行statspack期間必須session上設定TIMED_STATISTICS = TRUE，否則統計的資料將失真。
空閒等待事件是oracle正等待某種工作，在診斷和最佳化資料庫時候，不用過多注意這部分事件，
非空閒等待事件專門針對oracle的活動，指資料庫任務或應用程式執行過程中發生的等待，
這些等待事件是我們在調整資料庫應該關注的。

對於常見的等待事件，說明如下：

1) db file scattered read 檔案分散讀取
該事件通常與全表掃描或者fast full index scan有關。因為全表掃描是被放入記憶體中進行的進行的，通常情況下基於效能的考慮，有時候也可能是分配不到足夠長的連續記憶體空間，所以會將資料塊分散(scattered)讀入Buffer Cache中。該等待過大可能是缺少索引或者沒有合適的索引(可以調整optimizer_index_cost_adj) 。這種情況也可能是正常的，因為執行全表掃描可能比索引掃描效率更高。當系統存在這些等待時，需要透過檢查來確定全表掃描是否必需的來調整。因為全表掃描被置於LRU(Least Recently Used，最近最少適用)列表的冷端(cold end)，對於頻繁訪問的較小的資料表，可以選擇把他們Cache 到記憶體中，以避免反覆讀取。當這個等待事件比較顯著時，可以結合v$session_longops 動態效能檢視來進行診斷，該檢視中記錄了長時間(執行時間超過6 秒的)執行的事物，可能很多是全表掃描操作(不管怎樣，這部分資訊都是值得我們注意的)。
關於引數OPTIMIZER_INDEX_COST_ADJ＝n：該引數是一個百分比值，預設值為100，可以理解為FULL SCAN COST/INDEX SCAN COST。當n%* INDEX SCAN COST<FULL SCAN COST時，oracle會選擇使用索引。在具體設定的時候，我們可以根據具體的語句來調整該值。如果我們希望某個statement使用索引，而實際它確走全表掃描，可以對比這兩種情況的執行計劃不同的COST，從而設定一個更合適的值。

2) db file sequential read 檔案順序讀取整程式碼,特別是表連線：該事件說明在單個資料塊上大量等待，該值過高通常是由於表間連線順序很糟糕（沒有正確選擇驅動行源），或者使用了非選擇性索引。透過將這種等待與statspack報表中已知其它問題聯絡起來(如效率不高的sql),透過檢查確保索引掃描是必須的，並確保多表連線的連線順序來調整。

3) buffer busy wait 緩衝區忙 增大DB_CACHE_SIZE,加速檢查點,調整程式碼：

當程式需要存取SGA中的buffer的時候，它會依次執行如下步驟的操作：

當緩衝區以一種非共享方式或者如正在被讀入到緩衝時,就會出現該等待。該值不應該大於1%。當出現等待問題時，可以檢查緩衝等待統計部分(或V$WAITSTAT)，確定該等待發生在什麼位置：

a) 如果等待是否位於段頭(Segment Header)。這種情況表明段中的空閒列表（freelist）的塊比較少。可以考慮增加空閒列表(freelist，對於Oracle8i DMT)或者增加freelist groups(在很多時候這個調整是立竿見影的(alter table tablename strorage(freelists 2))，在8.1.6之前，這個freelists引數不能動態修改;在8.1.6及以後版本，動態修改feelists需要設定COMPATIBLE至少為8.1.6)。也可以增加PCTUSED與PCTFREE之間距離（PCTUSED-to-pctfree gap），其實就是說降低PCTUSED的值，儘快使塊返回freelist列表被重用。如果支援自動段空間管理（ASSM），也可以使用ASSM模式，這是在ORALCE 920以後的版本中新增的特性。

b) 如果這一等待位於undo header，可以透過增加回滾段(rollback segment)來解決緩衝區的問題。

c) 如果等待位於undo block上，我們需要增加提交的頻率，使block可以儘快被重用；使用更大的回滾段；降低一致讀所選擇的表中資料的密度；增大DB_CACHE_SIZE。

d) 如果等待處於data block，表明出現了hot block，可以考慮如下方法解決： ①將頻繁併發訪問的表或資料移到另一資料塊或者進行更大範圍的分佈(可以增大pctfree值，擴大資料分佈，減少競爭)，以避開這個"熱點"資料塊。②也可以減小資料塊的大小，從而減少一個資料塊中的資料行數，降低資料塊的熱度，減小競爭；③檢查對這些熱塊操作的SQL語句，最佳化語句。④增加hot block上的initrans值。但注意不要把initrans值設定的過於高了，通常設定為5就足夠了。因為增加事務意味著要增加ITL事務槽，而每個ITL事務槽將佔用資料塊中24個位元組長度。預設情況下，每個資料塊或者索引塊中是ITL槽是2個，在增加initrans的時候，可以考慮增大資料塊所在的表的PCTFREE值，這樣Oracle會利用PCTFREE部分的空間增加ITL slot數量，最大達到maxtrans指定。

e) 如果等待處於index block，應該考慮重建索引、分割索引或使用反向鍵索引。為了防止與資料塊相關的緩衝忙等待，也可以使用較小的塊，在這種情況下，單個塊中的記錄就較少，所以這個塊就不是那麼"繁忙"。或者可以設定更大的PCTFREE,使資料擴大物理分佈，減少記錄間的熱點競爭。在執行DML (insert/update/ delete)時，Oracle向資料塊中寫入資訊，對於多事務併發訪問的資料表，關於ITL的競爭和等待可能出現，為了減少這個等待，可以增加initrans，使用多個ITL槽。在Oracle9i 中，可以使用ASSM這個新特性Oracle 使用點陣圖來管理空間使用，減小爭用。

當程式需要存取SGA中的buffer的時候，它會依次執行如下步驟的操作：
1.獲得cache buffers chains latch，遍歷那條buffer chain直到找到需要的buffer header
2.根據需要進行的操作型別(讀或寫)，它需要在buffer header上獲得一個共享或獨佔模式的buffer pin或者buffer lock
3.若程式獲得buffer header pin，它會釋放獲得的cache buffers chains latch，然後執行對buffer block的操作
4.若程式無法獲得buffer header pin，它就會在buffer busy waits事件上等待

程式之所以無法獲得buffer header pin，是因為為了保證資料的一致性，同一時刻一個block只能被一個程式pin住進行存取，
因此當一個程式需要存取buffer cache中一個被其他程式使用的block的時候，這個程式就會產生對該block的buffer busy waits事件。

截至 9i，buffer busy waits事件的p1,p2,p3三個引數分別是file#,block#和id，分別表示等待的buffer block所在的檔案編號，
塊編號和具體的等待原因編號，到了Oracle ，前兩個引數沒變，第3個引數變成了塊型別編號，這一點可以透過查詢v$event_name檢視來進行驗證：

Oracle 9i
> select parameter1,parameter2,parameter3 from v$event_name where name='buffer busy waits'
PARAMETER1                  PARAMETER2                 PARAMETER3
------------------------ ------------------------ ------------------------
file#                             block#                          id
Oracle 10g
PARAMETER1                  PARAMETER2                 PARAMETER3
------------------------ ------------------------ ------------------------
file#                             block#                          class#

在診斷buffer busy waits事件的過程中，獲取如下資訊會很有用：
1.獲取產生buffer busy waits事件的等待原因編號，這可以透過查詢該事件的p3引數值獲得
2.獲取產生此事件的SQL語句，可以透過如下的查詢獲得：
select sql_text from v$sql t1,v$session t2,v$session_wait t3
where t1.address=t2.sql_address and t1.hash_value=t2.sql_hash_value
and t2.sid=t3.sid and t3.event='buffer busy waits';
3.獲取等待的塊的型別以及所在的segment，可以透過如下查詢獲得：

select 'Segment Header' class,a.segment_type,a.segment_name,a.partition_name from dba_segments a,v$session_wait b
where a.header_file=b.p1 and a.header_block=b.p2 and b.event='buffer busy waits'
union
select 'Freelist Groups' class,a.segment_type,a.segment_name,a.partition_name from dba_segments a,v$session_wait b
where a.header_file=b.p1 and b.p2 between a.header_block+1 and (a.header_block+a.freelist_groups) and a.freelist_groups>1 and b.event='buffer busy waits'
union
select a.segment_type||' block' class,a.segment_type,a.segment_name,a.partition_name from dba_extents a,v$session_wait b
where a.file_id=b.p1 and b.p2 between a.block_id and a.block_id+a.blocks-1 and b.event='buffer busy waits' and not exists(select 1 from dba_segments where
header_file=b.p1 and header_block= b.p2);

查詢的第一部分：如果等待的塊型別是segment header，那麼可以直接拿buffer busy waits事件的p1和p2引數去dba_segments檢視中匹配header_file和header_block欄位即可找到等待的segment名稱和segment型別，進行相應調整
查詢的第二部分：如果等待的塊型別是freelist groups，也可以在dba_segments檢視中找出對應的segment名稱和segment型別，注意這裡的引數p2表示的freelist groups的位置是在segment的header_block+1到header_block+freelist groups組數之間，並且freelist groups組數大於1
查詢的第三部分：如果等待的塊型別是普通的資料塊，那麼可以用p1、p2引數和dba_extents進行聯合查詢得到block所在的segment名稱和segment型別

對於不同的等待塊型別，我們採取不同的處理辦法：
1.data segment header：
程式經常性的訪問 segment header通常有兩個原因：獲取或修改process freelists資訊、擴充套件高水位標記，針對第一種情況，程式頻繁訪問process freelists資訊導致freelist爭用，我們可以增大相應的segment物件的儲存引數freelist或者freelist groups；若由於資料塊頻繁進出freelist而導致程式經常要修改freelist，則可以將pctfree值和pctused值設定較大的差距，從而避免資料塊頻繁進出freelist；對於第二種情況，由於該segment空間消耗很快，而設定的next extent過小，導致頻繁擴充套件高水位標記，解決的辦法是增大segment物件的儲存引數next extent或者直接在建立表空間的時候設定extent size uniform
2.data block：
某一或某些資料塊被多個程式同時讀寫，成為熱點塊，可以透過如下這些辦法來解決這個問題：
(1)降低程式的併發度，如果程式中使用了parallel查詢，降低parallel degree，以免多個parallel slave同時訪問同樣的資料物件而形成等待降低效能
(2)調整應用程式使之能讀取較少的資料塊就能獲取所需的資料，減少buffer gets和physical reads
(3)減少同一個block中的記錄數，使記錄分佈於更多的資料塊中，這可以透過若干途徑實現：可以調整segment物件的pctfree值，可以將segment重建到block size較小的表空間中，還可以用alter table minimize records_per_block語句減少每塊中的記錄數
(4)若熱點塊物件是類似自增id欄位的索引，則可以將索引轉換為反轉索引，打散資料分佈，分散熱點塊
3.undo segment header：
undo segment header爭用是因為系統中undo segment不夠，需要增加足夠的undo segment，根據undo segment的方法，若是手工管理模式，需要修改rollback_segments初始化引數來增加rollback segment，若是自動管理模式，可以減小transactions_per_rollback_segment初始化引數的值來使oracle自動增多rollback segment的數量
4.undo block：
undo block爭用是由於應用程式中存在對資料的讀和寫同時進行，讀程式需要到undo segment中去獲得一致性資料，解決辦法是錯開應用程式修改資料和大量查詢資料的時間

小結：buffer busy waits事件是oracle中比較複雜的一個，其形成原因很多，需要根據p3引數對照Oracle提供的原因程式碼表進行相應的診斷，10g以後則需要根據等待的block型別結合引起等待時間的具體SQL進行分析，採取相應的調整措施

4) latch free：當閂鎖丟失率高於0.5%時，需要調整這個問題。詳細的我們在後面的Latch Activity for DB部分說明。

latch是一種低階排隊機制，用於保護SGA中共享記憶體結構。latch就像是一種快速地被獲取和釋放的記憶體鎖。用於防止共享記憶體結構被多個使用者同時訪問。如果latch不可用，就會記錄latch釋放失敗(latch free miss )。有兩種與閂有關的型別:

　　■ 立刻。

　　■ 可以等待。

　　假如一個程式試圖在立刻模式下獲得閂，而該閂已經被另外一個程式所持有，如果該閂不能立可用的話，那麼該程式就不會為獲得該閂而等待。它將繼續執行另一個操作。

　　大多數latch問題都與以下操作相關:

　　沒有很好的是用繫結變數(library cache latch)、重作生成問題(redo allocation latch)、緩衝儲存競爭問題(cache buffers LRU chain)，以及buffer cache中的存在"熱點"塊(cache buffers chain)。

　　通常我們說，如果想設計一個失敗的系統，不考慮繫結變數，這一個條件就夠了，對於異構性強的系統，不使用繫結變數的後果是極其嚴重的。

　　另外也有一些latch等待與bug有關，應當關注Metalink相關bug的公佈及補丁的釋出。當latch miss ratios大於0.5%時，就應當研究這一問題。

　　Oracle的latch機制是競爭，其處理類似於網路裡的CSMA/CD，所有使用者程式爭奪latch，對於願意等待型別(willing-to-wait)的latch,如果一個程式在第一次嘗試中沒有獲得latch,那麼它會等待並且再嘗試一次,如果經過_spin_count次爭奪不能獲得latch, 然後該程式轉入睡眠狀態，持續一段指定長度的時間，然後再次醒來，按順序重複以前的步驟.在8i/9i中預設值是_spin_count=2000。

　　如果SQL語句不能調整，在8.1.6版本以上，Oracle提供了一個新的初始化引數: CURSOR_SHARING可以透過設定CURSOR_SHARING = force 在伺服器端強制繫結變數。設定該引數可能會帶來一定的副作用，對於Java的程式，有相關的bug，具體應用應該關注Metalink的bug公告。

***Latch 問題及可能解決辦法
------------------------------
* Library Cache and Shared Pool (未繫結變數---繫結變數,調整shared_pool_size)
每當執行SQL或PL/SQL儲存過程,包,函式和觸發器時,這個Latch即被用到.Parse操作中此Latch也會被頻繁使用.
* Redo Copy (增大_LOG_SIMULTANEOUS_COPIES引數)
重做複製Latch用來從PGA向重做日誌緩衝區複製重做記錄.
* Redo Allocation (最小化REDO生成,避免不必要提交)
此Latch用來分配重做日誌緩衝區中的空間,可以用NOLOGGING來減緩競爭.
* Row Cache Objects (增大共享池)
資料字典競爭.過度parsing.
* Cache Buffers Chains (_DB_BLOCK_HASH_BUCKETS應增大或設為質數)
"過熱"資料塊造成了記憶體緩衝鏈Latch競爭.
* Cache Buffers Lru Chain (調整SQL，設定DB_BLOCK_LRU_LATCHES,或使用多個緩衝區池)
掃描全部記憶體緩衝區塊的LRU(最近最少使用)鏈時要用到記憶體緩衝區LRU鏈Latch.太小記憶體緩衝區、過大的記憶體緩衝區吞吐量、過多的記憶體中進行的排序操作、DBWR速度跟不上工作負載等會引起此Latch競爭。

5) Enqueue 佇列是一種鎖，保護一些共享資源，防止併發的DML操作。佇列採用FIFO策略，注意latch並不是採用的FIFO機制。比較常見的有3種型別的佇列：ST佇列，HW佇列，TX4佇列。
ST Enqueue的等待主要是在字典管理的表空間中進行空間管理和分配時產生的。解決方法：1）將字典管理的表空間改為本地管理模式 2）預先分配分割槽或者將有問題的字典管理的表空間的next extent設定大一些。
HW Enqueue是用於segment的HWM的。當出現這種等待的時候，可以透過手工分配extents來解決。
TX4 Enqueue等待是最常見的等待情況。通常有3種情況會造成這種型別的等待：1）唯一索引中的重複索引。解決方法：commit或者rollback以釋放佇列。 2）對同一個點陣圖索引段（bitmap index fragment）有多個update，因為一個bitmap index fragment可能包含了多個rowid，所以當多個使用者更新時，可能一個使用者會鎖定該段，從而造成等待。解決方法同上。3）有多個使用者同時對一個資料塊作update，當然這些DML操作可能是針對這個資料塊的不同的行，如果此時沒有空閒的ITL槽，就會產生一個block-level鎖。解決方法：增大表的initrans值使建立更多的ITL槽；或者增大表的pctfree值，這樣oracle可以根據需要在pctfree的空間建立更多的ITL槽；使用smaller block size，這樣每個塊中包含行就比較少，可以減小衝突發生的機會。

AWR報告分析--等待事件-佇列.doc

6) Free Buffer 釋放緩衝區：這個等待事件表明系統正在等待記憶體中的可用空間，這說明當前Buffer 中已經沒有Free 的記憶體空間。如果應用設計良好，SQL 書寫規範，充分繫結變數，那這種等待可能說明Buffer Cache 設定的偏小，你可能需要增大DB_CACHE_SIZE。該等待也可能說明DBWR 的寫出速度不夠，或者磁碟存在嚴重的競爭，可以需要考慮增加檢查點、使用更多的DBWR 程式，或者增加物理磁碟的數量,分散負載，平衡IO。

7) Log file single write：該事件僅與寫日誌檔案頭塊相關，通常發生在增加新的組成員和增進序列號時。頭塊寫單個進行，因為頭塊的部分資訊是檔案號，每個檔案不同。更新日誌檔案頭這個操作在後臺完成，一般很少出現等待，無需太多關注。

8) log file parallel write：從log buffer 寫redo 記錄到redo log 檔案，主要指常規寫操作(相對於log file sync)。如果你的Log group 存在多個組成員，當flush log buffer 時，寫操作是並行的，這時候此等待事件可能出現。儘管這個寫操作並行處理，直到所有I/O 操作完成該寫操作才會完成(如果你的磁碟支援非同步IO或者使用IO SLAVE，那麼即使只有一個redo log file member,也有可能出現此等待)。這個引數和log file sync 時間相比較可以用來衡量log file 的寫入成本。通常稱為同步成本率。改善這個等待的方法是將redo logs放到I/O快的盤中，儘量不使用raid5，確保表空間不是處在熱備模式下，確保redo log和data的資料檔案位於不同的磁碟中。

9) log file sync：當一個使用者提交或回滾資料時，LGWR將會話的redo記錄從日誌緩衝區填充到日誌檔案中，使用者的程式必須等待這個填充工作完成。在每次提交時都出現，如果這個等待事件影響到資料庫效能，那麼就需要修改應用程式的提交頻率, 為減少這個等待事件，須一次提交更多記錄，或者將重做日誌REDO LOG 檔案訪在不同的物理磁碟上，提高I/O的效能。

當一個使用者提交或回滾資料時，LGWR 將會話期的重做由日誌緩衝器寫入到重做日誌中。日誌檔案同步過程必須等待這一過程成功完成。為了減少這種等待事件，可以嘗試一次提交更多的記錄(頻繁的提交會帶來更多的系統開銷)。將重做日誌置於較快的磁碟上，或者交替使用不同物理磁碟上的重做日誌，以降低歸檔對LGWR的影響。

　　對於軟RAID，一般來說不要使用RAID 5，RAID5 對於頻繁寫入得系統會帶來較大的效能損失，可以考慮使用檔案系統直接輸入/輸出，或者使用裸裝置(raw device)，這樣可以獲得寫入的效能提高。

10) log buffer space：日誌緩衝區寫的速度快於LGWR寫REDOFILE的速度,可以增大日誌檔案大小，增加日誌緩衝區的大小，或者使用更快的磁碟來寫資料。

當你將日誌緩衝(log buffer)產生重做日誌的速度比LGWR 的寫出速度快，或者是當日志切換(log switch)太慢時，就會發生這種等待。這個等待出現時，通常表明redo log buffer 過小，為解決這個問題，可以考慮增大日誌檔案的大小，或者增加日誌緩衝器的大小。

　　另外一個可能的原因是磁碟I/O 存在瓶頸，可以考慮使用寫入速度更快的磁碟。在允許的條件下設定可以考慮使用裸裝置來存放日誌檔案，提高寫入效率。在一般的系統中，最低的標準是，不要把日誌檔案和資料檔案存放在一起，因為通常日誌檔案只寫不讀，分離存放可以獲得效能提升。

11) logfile switch：通常是因為歸檔速度不夠快。表示所有的提交(commit)的請求都需要等待"日誌檔案切換"的完成。Log file Switch 主要包含兩個子事件:
log file switch (archiving needed) 這個等待事件出現時通常是因為日誌組迴圈寫滿以後，第一個日誌歸檔尚未完成，出現該等待。出現該等待，可能表示io 存在問題。解決辦法:①可以考慮增大日誌檔案和增加日誌組；②移動歸檔檔案到快速磁碟；③調整log_archive_max_processes。
log file switch (checkpoint incomplete) 當日志組都寫完以後，LGWR 試圖寫第一個log file，如果這時資料庫沒有完成寫出記錄在第一個log file 中的dirty 塊時(例如第一個檢查點未完成)，該等待事件出現。該等待事件通常表示你的DBWR 寫出速度太慢或者IO 存在問題。為解決該問題，你可能需要考慮增加額外的DBWR 或者增加你的日誌組或日誌檔案大小，或者也可以考慮增加checkpoint的頻率。

12) DB File Parallel Write：檔案被DBWR並行寫時發生。解決辦法：改善IO效能。

處理此事件時，需要注意

1）db file parallel write事件只屬於DBWR程式。

2）緩慢的DBWR可能影響前臺程式。

3）大量的db file parallel write等待時間很可能是I/O問題引起的。（在確認os支援非同步io的前提下，你可以在系統中檢查disk_asynch_io引數，保證為TRUE。可以透過設定db_writer_processes來提高DBWR程式數量，當然前提是不要超過cpu的數量。）
     DBWR程式執行經過SGA的所有寫入，當開始寫入時，DBWR程式編譯一組髒塊（dirty block），並且將系統寫入呼叫釋出到作業系統。DBWR程式查詢在各個時間內寫入的塊，包括每隔3秒的一次查詢，當前臺程式提交以清除緩衝區中的內容時：在檢查點處查詢，當滿足_DB_LARGE_DIRTY_QUEUE、_DB_BLOCK_MAX_DIRTY_TARGET和FAST_START_MTTR_TARGET閥值時，等等。
    雖然使用者會話從來沒有經歷過db file parallel write等待事件，但這並不意味著它們不會受到這種事件的影響。緩慢的DBWR寫入效能可以造成前臺會話在write complete waits或free buffer waits事件上等待。DBWR寫入效能可能受到如下方面的影響：I/O操作的型別（同步或非同步）、儲存裝置（裸裝置或成熟的檔案系統）、資料庫佈局和I/O子系統配置。需要檢視的關鍵資料庫統計是當db file parallel write、free buffer waits和write complete waits等待事件互相關聯時，系統範圍內的TIME_WAITED和AVERAGE_WAIT。
    如果db file parallel write平均等待時間大於10cs（或者100ms），則通常表明緩慢的I/O吞吐量。可以透過很多方法來改善平均等待時間。主要的方法是使用正確型別的I/O操作。如果資料檔案位於裸裝置（raw device）上，並且平臺支援非同步I/O，就應該使用非同步寫入。但是，如果資料庫位於檔案系統上，則應該使用同步寫入和直接I/O（這是作業系統直接I/O）。除了確保正在使用正確型別的I/O操作，還應該檢查你的資料庫佈局並使用常見的命令監控來自作業系統的I/O吞吐量。例如sar -d或iostat -dxnC。
    當db file parallel write平均等待時間高並且系統繁忙時，使用者會話可能開始在free buffer waits事件上等待。這是因為DBWR程式不能滿足釋放緩衝區的需求。如果free buffer waits事件的TIME_WAITED高，則應該在快取記憶體中增加緩衝區數量之前說明DBWR I/O吞吐量的問題。
    高db file parallel write平均等待時間的另一個反響是在write complete waits等待事件上的高TIME_WAITED。前臺程式不允許修改正在傳輸到磁碟的塊。換句話說，也就是位於DBWR批次寫入中的塊。前臺的會話在write complete waits等待事件上等待。因此，write complete waits事件的出現，一定標誌著緩慢的DBWR程式，可以透過改進DBWR I/O吞吐量修正這種延遲。

13) DB File Single Write：當檔案頭或別的單獨塊被寫入時發生，這一等待直到所有的I/O呼叫完成。解決辦法：改善IO效能。

14) DB FILE Scattered Read：當掃描整個段來根據初始化引數db_file_multiblock_read_count讀取多個塊時發生，因為資料可能分散在不同的部分，這與分條或分段）相關，因此通常需要多個分散的讀來讀取所有的資料。等待時間是完成所有I/O呼叫的時間。解決辦法：改善IO效能。

這種情況通常顯示與全表掃描相關的等待。
當資料庫進行全表掃時，基於效能的考慮，資料會分散(scattered)讀入Buffer Cache。如果這個等待事件比較顯著，可能說明對於某些全表掃描的表，沒有建立索引或者沒有建立合適的索引，我們可能需要檢查這些資料表已確定是否進行了正確的設定。

然而這個等待事件不一定意味著效能低下，在某些條件下Oracle會主動使用全表掃描來替換索引掃描以提高效能，這和訪問的資料量有關，在CBO下Oracle會進行更為智慧的選擇，在RBO下Oracle更傾向於使用索引。

因為全表掃描被置於LRU（Least Recently Used，最近最少適用）列表的冷端（cold end），對於頻繁訪問的較小的資料表，可以選擇把他們Cache到記憶體中，以避免反覆讀取。

當這個等待事件比較顯著時，可以結合v$session_longops動態效能檢視來進行診斷，該檢視中記錄了長時間（執行時間超過6秒的）執行的事物，可能很多是全表掃描操作（不管怎樣，這部分資訊都是值得我們注意的）。

15) DB FILE Sequential Read：當前臺程式對資料檔案進行常規讀時發生，包括索引查詢和別的非整段掃描以及資料檔案塊丟棄等待。等待時間是完成所有I/O呼叫的時間。解決辦法：改善IO效能。

如果這個等待事件比較顯著，可能表示在多表連線中，表的連線順序存在問題，沒有正確地使用驅動表；或者可能索引的使用存在問題，並非索引總是最好的選擇。在大多數情況下，透過索引可以更為快速地獲取記錄，所以對於編碼規範、調整良好的資料庫，這個等待事件很大通常是正常的。有時候這個等待過高和儲存分佈不連續、連續資料塊中部分被快取有關，特別對於DML頻繁的資料表，資料以及儲存空間的不連續可能導致過量的單塊讀，定期的資料整理和空間回收有時候是必須的。

需要注意在很多情況下，使用索引並不是最佳的選擇，比如讀取較大表中大量的資料，全表掃描可能會明顯快於索引掃描，所以在開發中就應該注意，對於這樣的查詢應該進行避免使用索引掃描。

16) Direct Path Read：一般直接路徑讀取是指將資料塊直接讀入PGA中。一般用於排序、並行查詢和read ahead操作。這個等待可能是由於I/O造成的。使用非同步I/O模式或者限制排序在磁碟上，可能會降低這裡的等待時間。

與直接讀取相關聯的等待事件。當ORACLE將資料塊直接讀入會話的PGA（程式全域性區）中，同時繞過SGA（系統全域性區）。PGA中的資料並不和其他的會話共享。即表明，讀入的這部分資料該會話獨自使用，不放於共享的SGA中。

在排序操作(order by/group by/union/distinct/rollup/合併連線)時，由於PGA中的SORT_AREA_SIZE空間不足，造成需要使用臨時表空間來儲存中間結果，當從臨時表空間讀入排序結果時，產生direct path read等待事件。

使用HASH連線的SQL語句，將不適合位於記憶體中的雜湊分割槽重新整理到臨時表空間中。為了查明匹配SQL謂詞的行，臨時表空間中的雜湊分割槽被讀回到記憶體中(目的是為了查明匹配SQL謂詞的行)，ORALCE會話在direct path read等待事件上等待。

使用並行掃描的SQL語句也會影響系統範圍的direct path read等待事件。在並行執行過程中，direct path read等待事件與從屬查詢有關，而與父查詢無關，執行父查詢的會話基本上會在PX Deq:Execute Reply上等待，從屬查詢會產生direct path read等待事件。

直接讀取可能按照同步或非同步的方式執行，取決於平臺和初始化引數disk_asynch_io引數的值。使用非同步I/O時，系統範圍的等待的事件的統計可能不準確，會造成誤導作用。

17) direct path write：直接路徑寫該等待發生在，系統等待確認所有未完成的非同步I/O 都已寫入磁碟。對於這一寫入等待，我們應該找到I/O 操作最為頻繁的資料檔案(如果有過多的排序操作，很有可能就是臨時檔案)，分散負載，加快其寫入操作。如果系統存在過多的磁碟排序，會導致臨時表空間操作頻繁，對於這種情況，可以考慮使用Local管理表空間，分成多個小檔案，寫入不同磁碟或者裸裝置。

在DSS系統中，存在大量的direct path read是很正常的，但是在OLTP系統中，通常顯著的直接路徑讀（direct path read）都意味著系統應用存在問題，從而導致大量的磁碟排序讀取操作。

直接路徑寫（direct paht write）通常發生在Oracle直接從PGA寫資料到資料檔案或臨時檔案，這個寫操作可以繞過SGA。

這類寫入操作通常在以下情況被使用：
·直接路徑載入；
·並行DML操作；
·磁碟排序；
·對未快取的“LOB”段的寫入，隨後會記錄為direct path write(lob)等待。

最為常見的直接路徑寫，多數因為磁碟排序導致。對於這一寫入等待，我們應該找到I/O操作最為頻繁的資料檔案（如果有過多的排序操作，很有可能就是臨時檔案），分散負載，加快其寫入操作。

18) control file parallel write：當server 程式更新所有控制檔案時，這個事件可能出現。如果等待很短，可以不用考慮。如果等待時間較長，檢查存放控制檔案的物理磁碟I/O 是否存在瓶頸。
多個控制檔案是完全相同的複製，用於映象以提高安全性。對於業務系統，多個控制檔案應該存放在不同的磁碟上，一般來說三個是足夠的，如果只有兩個物理硬碟，那麼兩個控制檔案也是可以接受的。在同一個磁碟上儲存多個控制檔案是不具備實際意義的。減少這個等待，可以考慮如下方法:①減少控制檔案的個數(在確保安全的前提下)。②如果系統支援，使用非同步IO。③轉移控制檔案到IO 負擔輕的物理磁碟。

19) control file sequential read
control file single write ：控制檔案連續讀/控制檔案單個寫對單個控制檔案I/O 存在問題時，這兩個事件會出現。如果等待比較明顯，檢查單個控制檔案，看存放位置是否存在I/O 瓶頸。

20) library cache pin

該事件通常是發生在先有會話在執行PL/SQL,VIEW,TYPES等object時,又有另外的會話執行重新編譯這些object,即先給物件加上了一個共享鎖,然後又給它加排它鎖,這樣在加排它鎖的會話上就會出現這個等待。P1,P2可與x$kglpn和x$kglob表相關
X$KGLOB (Kernel Generic Library Cache Manager Object)
X$KGLPN (Kernel Generic Library Cache Manager Object Pins)
-- 查詢X$KGLOB,可找到相關的object,其SQL語句如下
(即把V$SESSION_WAIT中的P1raw與X$KGLOB中的KGLHDADR相關連)
select kglnaown,kglnaobj from X$KGLOB
where KGLHDADR =(select p1raw from v$session_wait
where event='library cache pin')
-- 查出引起該等待事件的阻塞者的sid
select sid from x$kglpn , v$session
where KGLPNHDL in
(select p1raw from v$session_wait
where wait_time=0 and event like 'library cache pin%')
and KGLPNMOD <> 0
and v$session.saddr=x$kglpn.kglpnuse
-- 查出阻塞者正執行的SQL語句
select sid,sql_text
from v$session, v$sqlarea
where v$session.sql_address=v$sqlarea.address
and sid=<阻塞者的sid>
這樣,就可找到"library cache pin"等待的根源，從而解決由此引起的效能問題。

21) library cache lock
該事件通常是由於執行多個DDL操作導致的,即在library cache object上新增一個排它鎖後,又從另一個會話給它新增一個排它鎖,這樣在第二個會話就會生成等待。可透過到基表x$kgllk中查詢其對應的物件。
-- 查詢引起該等待事件的阻塞者的sid、會話使用者、鎖住的物件
select b.sid,a.user_name,a.kglnaobj
from x$kgllk a , v$session b
where a.kgllkhdl in
(select p1raw from v$session_wait
where wait_time=0 and event = 'library cache lock')
and a.kgllkmod <> 0
and b.saddr=a.kgllkuse
當然也可以直接從v$locked_objects中檢視，但沒有上面語句直觀根據sid可以到v$process中查出pid，然後將其kill或者其它處理。

22)

對於常見的一些IDLE wait事件舉例：

dispatcher timer

lock element cleanup

Null event

parallel query dequeue wait

parallel query idle wait - Slaves

pipe get

PL/SQL lock timer

pmon timer- pmon

rdbms ipc message

slave wait

smon timer

SQL*Net break/reset to client

SQL*Net message from client

SQL*Net message to client

SQL*Net more data to client

virtual circuit status

client message

SQL*Net message from client

下面是關於這裡的常見的等待事件和解決方法的一個快速預覽

等待事件	一般解決方法
Sequential Read	調整相關的索引和選擇合適的驅動行源
Scattered Read	表明出現很多全表掃描。最佳化code，cache小表到記憶體中。
Free Buffer	增大DB_CACHE_SIZE，增大checkpoint的頻率，最佳化程式碼
Buffer Busy Segment header	增加freelist或者freelistgroups
Buffer Busy Data block	隔離熱塊；使用反轉索引；使用更小的塊；增大表的initrans
Buffer Busy Undo header	增加回滾段的數量或者大小
Buffer Busy Undo block	Commit more；增加回滾段的數量或者大小
Latch Free	檢查具體的等待latch型別，解決方法參考後面介紹
Enqueue–ST	使用本地管理的表空間或者增加預分配的盤區大小
Enqueue–HW	在HWM之上預先分配盤區
Enqueue–TX4	在表或者索引上增大initrans的值或者使用更小的塊
Log Buffer Space	增大LOG_BUFFER，改善I/O
Log File Switch	增加或者增大日誌檔案
Log file sync	減小提交的頻率；使用更快的I/O；或者使用裸裝置
Write complete waits	增加DBWR；提高CKPT的頻率；

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時間。

DB time=報表頭部顯示的db time=cpu time + all of nonidle wait event time

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

查詢Oracle 10gR1提供的12個等待事件類：

select wait_class#, wait_class_id, wait_class from v$event_name group by wait_class#, wait_class_id, wait_class order by wait_class#;

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)

（1）查詢所有等待事件及其屬性：

select event#, name, parameter1, parameter2, parameter3 from v$event_name order by name;

（2）查詢Oracle 10gR1提供的12個等待事件類：

select wait_class#, wait_class_id, wait_class from v$event_name group by wait_class#, wait_class_id, wait_class order by wait_class#;

wait_event.doc

下面顯示的內容可能來自下面幾個檢視）

V$EVENT_NAME檢視包含所有為資料庫例項定義的等待事件。

V$SYSTEM_EVENT檢視顯示自從例項啟動後，所有Oracle會話遇到的所有等待事件的總計統計。

V$SESSION_EVENT檢視包含當前連線到例項的所有會話的總計等待事件統計。該檢視包含了V$SYSTEM_EVENT檢視中出現的所有列。它記錄會話中每一個等待事件的總等待次數、已等待時間和最大等待時間。SID列標識出獨立的會話。每個會話中每個事件的最大等待時間在MAX_WAIT列中追蹤。透過用SID列將V$SESSION_EVENT檢視和V$SESSION檢視結合起來，可得到有關會話和使用者的更多資訊。

V$SESSION_WAIT檢視提供關於每個會話正在等待的事件或資源的詳細資訊。該檢視在任何給定時間，只包含每個會話的一行活動的或不活動的資訊。

自從OWI在Oracle 7.0.12中引入後，就具有下來4個V$檢視：

· V$EVENT_NAME

· V$SESSION_WAIT

· V$SESSION_EVENT

· V$SYSTEM_EVENT

除了這些等待事件檢視之外，Oracle 10gR1中引入了下列新檢視以從多個角度顯示等待資訊：

· V$SYSTEM_WAIT_CLASS

· V$SESSION_WAIT_CLASS

· V$SESSION_WAIT_HISTORY

· V$EVENT_HISTOGRAM

· V$ACTIVE_SESSION_HISTORY

然而，V$SESSION_WAIT、V$SESSION_WAIT和V$SESSION_WAIT仍然是3個重要的檢視，它們提供了不同粒度級的等待事件統計和計時資訊。三者的關係如下：

V$SESSION_WAIT ? V$SESSION_EVENT ? V$SYSTEM_EVENT

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	0.01
enq: TT - contention	46	0.00	0	0	0.01
enq: TD - KTF dump entries	12	0.00	0	1	0.00
read by other session	1	0.00	0	12	0.00
LGWR wait for redo copy	540	0.00	0	0	0.10
PX Deq Credit: send blkd	17	5.88	0	0	0.00
enq: TA - contention	14	0.00	0	0	0.00
latch: ges resource hash list	44	0.00	0	0	0.01
enq: PI - contention	8	0.00	0	0	0.00
write complete waits	1	0.00	0	2	0.00
enq: DR - contention	3	0.00	0	0	0.00
enq: MW - contention	3	0.00	0	0	0.00
enq: TS - contention	3	0.00	0	0	0.00
PX qref latch	150	100.00	0	0	0.03
PX qref latch 在並行執行的情況下偶然會發現PX qref latch等待事件，當系統高峰期同時採用了高併發的情況下最容易出現。看來要進行特殊照顧了。概念和原理在並行執行環境中，query slaves 和query coordinator之間是透過佇列交換資料和資訊的。PX qref latch 是用來保護這些佇列的。 PX qref latch 等待事件的出現一般表明資訊的傳送比接受快，這時需要調整buffer size（可以透過parallel_execution_message_size引數調整）。但是有些情況下也是難以避免發生這種情況的，比如consumer需要長時間的等待資料的處理，原因在於需要返回大批次的資料包，這種情況下很正常。調整和措施當系統的負載比較高時，需要把並行度降低；如果使用的是預設並行度，可以透過減小parallel_thread_per_cpu引數的值來達到效果。 DEFAULT degree = PARALLEL_THREADS_PER_CPU * #CPU's 最佳化parallel_execution_message_size引數 Tuning parallel_execution_message_size is a tradeoff between performance and memory. For parallel query, the connection topology between slaves and QC requires (n^2 + 2n) connections (where n is the DOP not the actual number of slaves) at maximum. If each connection has 3 buffers associated with it then you can very quickly get into high memory consumption on large machines doing high DOP queries
enq: MD - contention	2	0.00	0	0	0.00
latch: KCL gc element parent latch	11	0.00	0	0	0.00
enq: JS - job run lock - synchronize	1	0.00	0	1	0.00
SQL*Net more data to client	16	0.00	0	0	0.00
latch: cache buffers lru chain	1	0.00	0	0	0.00
enq: UL - contention	1	0.00	0	0	0.00
gc current split	1	0.00	0	0	0.00
enq: AF - task serialization	1	0.00	0	0	0.00
latch: object queue header operation	3	0.00	0	0	0.00
latch: cache buffers chains	1	0.00	0	0	0.00
latch: enqueue hash chains	2	0.00	0	0	0.00
SQL*Net message from client	1,544,113	0.00	12,626	8	275.83
gcs remote message	634,884	98.64	9,203	14	113.41
DIAG idle wait	23,628	0.00	4,616	195	4.22
ges remote message	149,591	93.45	4,612	31	26.72
Streams AQ: qmn slave idle wait	167	0.00	4,611	27611	0.03
Streams AQ: qmn coordinator idle wait	351	47.86	4,611	13137	0.06
Streams AQ: waiting for messages in the queue	488	100.00	4,605	9436	0.09
virtual circuit status	157	100.00	4,596	29272	0.03
PX Idle Wait	1,072	97.11	2,581	2407	0.19
jobq slave wait	145	97.93	420	2896	0.03
Streams AQ: waiting for time management or cleanup tasks	1	100.00	270	269747	0.00
PX Deq: Parse Reply	40	40.00	0	3	0.01
PX Deq: Execution Msg	121	26.45	0	0	0.02
PX Deq: Join ACK	38	42.11	0	1	0.01
PX Deq: Execute Reply	34	32.35	0	0	0.01
PX Deq: Msg Fragment	16	0.00	0	0	0.00
Streams AQ: RAC qmn coordinator idle wait	351	100.00	0	0	0.06
class slave wait	2	0.00	0	0	0.00

db file scattered read等待事件是當SESSION等待multi-block I/O時發生的，透過是由於full table scans或 index fast full scans。發生過多讀操作的Segments可以在“Segments by Physical Reads”和 “SQL ordered by Reads”節中識別（在其它版本的報告中，可能是別的名稱）。如果在OLTP應用中，不應該有過多的全掃描操作，而應使用選擇性好的索引操作。

DB file sequential read等待意味著發生順序I/O讀等待（通常是單塊讀取到連續的記憶體區域中），如果這個等待非常嚴重，應該使用上一段的方法確定執行讀操作的熱點SEGMENT，然後透過對大表進行分割槽以減少I/O量，或者最佳化執行計劃（透過使用儲存大綱或執行資料分析）以避免單塊讀操作引起的sequential read等待。透過在批次應用中，DB file sequential read是很影響效能的事件，總是應當設法避免。

Log File Parallel Write 事件是在等待LGWR程式將REDO記錄從LOG 緩衝區寫到聯機日誌檔案時發生的。雖然寫操作可能是併發的，但LGWR需要等待最後的I/O寫到磁碟上才能認為並行寫的完成，因此等待時間依賴於OS完成所有請求的時間。如果這個等待比較嚴重，可以透過將LOG檔案移到更快的磁碟上或者條帶化磁碟（減少爭用）而降低這個等待。

Buffer Busy Waits事件是在一個SESSION需要訪問BUFFER CACHE中的一個資料庫塊而又不能訪問時發生的。緩衝區“busy”的兩個原因是：1）另一個SESSION正在將資料塊讀進BUFFER。2）另一個SESSION正在以排它模式佔用著這塊被請求的BUFFER。可以在“Segments by Buffer Busy Waits”一節中找出發生這種等待的SEGMENT，然後透過使用reverse-key indexes並對熱表進行分割槽而減少這種等待事件。

Log File Sync事件，當使用者SESSION執行事務操作（COMMIT或ROLLBACK等）後，會通知 LGWR程式將所需要的所有REDO資訊從LOG BUFFER寫到LOG檔案，在使用者SESSION等待LGWR返回安全寫入磁碟的通知時發生此等待。減少此等待的方法寫Log File Parallel Write事件的處理。

Enqueue Waits是序列訪問本地資源的本鎖，表明正在等待一個被其它SESSION（一個或多個）以排它模式鎖住的資源。減少這種等待的方法依賴於生產等待的鎖型別。導致Enqueue等待的主要鎖型別有三種：TX（事務鎖）, TM D（ML鎖）和ST（空間管理鎖）。

Background Wait Events

ordered by wait time desc, waits desc (idle events last)

Event	Waits	%Time -outs	Total Wait Time (s)	Avg wait (ms)	Waits /txn
log file parallel write	5,497	0.00	47	9	0.98
db file parallel write	4,806	0.00	34	7	0.86
events in waitclass Other	69,002	83.25	22	0	12.33
control file sequential read	9,323	0.00	7	1	1.67
control file parallel write	1,946	0.00	3	1	0.35
os thread startup	18	5.56	2	89	0.00
direct path read	138	0.00	0	1	0.02
db file sequential read	21	0.00	0	5	0.00
direct path write	138	0.00	0	0	0.02
log file sequential read	36	0.00	0	2	0.01
gc cr block 2-way	96	0.00	0	0	0.02
gc current block 2-way	78	0.00	0	0	0.01
log buffer space	11	0.00	0	2	0.00
row cache lock	59	0.00	0	0	0.01
log file single write	36	0.00	0	0	0.01
buffer busy waits	151	0.66	0	0	0.03
gc current grant busy	29	0.00	0	0	0.01
library cache lock	4	0.00	0	1	0.00
enq: TM - contention	10	0.00	0	0	0.00
gc current grant 2-way	8	0.00	0	0	0.00
gc cr multi block request	7	0.00	0	0	0.00
gc cr grant 2-way	5	0.00	0	0	0.00
rdbms ipc message	97,288	73.77	50,194	516	17.38
gcs remote message	634,886	98.64	9,203	14	113.41
DIAG idle wait	23,628	0.00	4,616	195	4.22
pmon timer	1,621	100.00	4,615	2847	0.29
ges remote message	149,591	93.45	4,612	31	26.72
Streams AQ: qmn slave idle wait	167	0.00	4,611	27611	0.03
Streams AQ: qmn coordinator idle wait	351	47.86	4,611	13137	0.06
smon timer	277	6.50	4,531	16356	0.05
Streams AQ: waiting for time management or cleanup tasks	1	100.00	270	269747	0.00
PX Deq: Parse Reply	40	40.00	0	3	0.01
PX Deq: Join ACK	38	42.11	0	1	0.01
PX Deq: Execute Reply	34	32.35	0	0	0.01
Streams AQ: RAC qmn coordinator idle wait	351	100.00	0	0	0.06

Operating System Statistics

Statistic	Total
NUM_LCPUS	0
NUM_VCPUS	0
AVG_BUSY_TIME	101,442
AVG_IDLE_TIME	371,241
AVG_IOWAIT_TIME	5,460
AVG_SYS_TIME	25,795
AVG_USER_TIME	75,510
BUSY_TIME	812,644
IDLE_TIME	2,971,077
IOWAIT_TIME	44,794
SYS_TIME	207,429
USER_TIME	605,215
LOAD	0
OS_CPU_WAIT_TIME	854,100
RSRC_MGR_CPU_WAIT_TIME	0
PHYSICAL_MEMORY_BYTES	8,589,934,592
NUM_CPUS	8
NUM_CPU_CORES	4

NUM_LCPUS：如果顯示0，是因為沒有設定LPARS

NUM_VCPUS：同上。

AVG_BUSY_TIME： BUSY_TIME / NUM_CPUS

AVG_IDLE_TIME： IDLE_TIME / NUM_CPUS

AVG_IOWAIT_TIME： IOWAIT_TIME / NUM_CPUS

AVG_SYS_TIME： SYS_TIME / NUM_CPUS

AVG_USER_TIME： USER_TIME / NUM_CPUSar o

BUSY_TIME： time equiv of %usr+%sys in sar output

IDLE_TIME： time equiv of %idle in sar

IOWAIT_TIME： time equiv of %wio in sar

SYS_TIME： time equiv of %sys in sar

USER_TIME： time equiv of %usr in sar

LOAD：未知

OS_CPU_WAIT_TIME： supposedly time waiting on run queues

RSRC_MGR_CPU_WAIT_TIME： time waited coz of resource manager

PHYSICAL_MEMORY_BYTES： total memory in use supposedly

NUM_CPUS： number of CPUs reported by OS 作業系統CPU數

NUM_CPU_CORES： number of CPU sockets on motherboard 主機板上CPU插槽數

總的elapsed time也可以用以公式計算：

BUSY_TIME + IDLE_TIME + IOWAIT TIME

或：SYS_TIME + USER_TIME + IDLE_TIME + IOWAIT_TIME

（因為BUSY_TIME = SYS_TIME+USER_TIME）

Service Statistics

ordered by DB Time

Service Name	DB Time (s)	DB CPU (s)	Physical Reads	Logical Reads
ICCI	608.10	496.60	315,849	16,550,972
SYS$USERS	54.70	17.80	6,539	58,929
ICCIXDB	0.00	0.00	0	0
SYS$BACKGROUND	0.00	0.00	282	38,990

Service Wait Class Stats

Wait Class info for services in the Service Statistics section.
Total Waits and Time Waited displayed for the following wait classes: User I/O, Concurrency, Administrative, Network
Time Waited (Wt Time) in centisecond (100th of a second)

Service Name	User I/O Total Wts	User I/O Wt Time	Concurcy Total Wts	Concurcy Wt Time	Admin Total Wts	Admin Wt Time	Network Total Wts	Network Wt Time
ICCI	59826	8640	4621	338	0	0	1564059	6552
SYS$USERS	6567	3238	231	11	0	0	7323	3
SYS$BACKGROUND	443	115	330	168	0	0	0	0

SQL Statistics v$sqlarea

SQL ordered by Executions

本節按各種資源分別列出對資源消耗最嚴重的SQL語句，並顯示它們所佔統計期內全部資源的比例，這給出我們調優指南。例如在一個系統中，CPU資源是系統效能瓶頸所在，那麼最佳化buffer gets最多的SQL語句將獲得最大效果。在一個I/O等待是最嚴重事件的系統中，調優的目標應該是physical IOs最多的SQL語句。

在STATSPACK報告中，沒有完整的SQL語句，可使用報告中的Hash Value透過下面語句從資料庫中查到：

select sql_text

from stats$sqltext

where hash_value = &hash_value

order by piece;

SQL ordered by Elapsed Time

Resources reported for PL/SQL code includes the resources used by all SQL statements called by the code.
% Total DB Time is the Elapsed Time of the SQL statement divided into the Total Database Time multiplied by 100

Elapsed Time (s)	CPU Time (s)	Executions	Elap per Exec (s)	% Total DB Time	SQL Id	SQL Module	SQL Text
93	57	1	93.50	14.10		cuidmain@HPGICCI1 (TNS V1-V3)	insert into CUID select CUID_...
76	75	172,329	0.00	11.52		load_fnsact@HPGICCI1 (TNS V1-V3)	insert into ICCICCS values (:...
58	42	1	58.04	8.75		cumimain@HPGICCI1 (TNS V1-V3)	insert into CUMI select CUSV_...
51	42	1	50.93	7.68		cusmmain@HPGICCI1 (TNS V1-V3)	insert into CUSM select CUSM_...
38	36	166,069	0.00	5.67			select c.name, u.name from co...
35	3	1	35.00	5.28		SQL*Plus	SELECT F.TABLESPACE_NAME, TO_...
23	23	172,329	0.00	3.46		load_fnsact@HPGICCI1 (TNS V1-V3)	insert into iccifnsact values...
15	11	5	2.98	2.25			DECLARE job BINARY_INTEGER := ...
14	14	172,983	0.00	2.16		load_fnsact@HPGICCI1 (TNS V1-V3)	update ICCIFNSACT set BORM_AD...
13	13	172,337	0.00	2.00		load_oldnewact@HPGICCI1 (TNS V1-V3)	insert into OLDNEWACT values ...
13	13	166,051	0.00	1.89		icci_migact@HPGICCI1 (TNS V1-V3)	insert into ICCICCS values (:...
10	4	1	9.70	1.46		cuidmain@HPGICCI1 (TNS V1-V3)	select CUID_CUST_NO , CUID_ID_...
10	8	5	1.91	1.44			INSERT INTO STATS$SGA_TARGET_A...
8	8	172,329	0.00	1.25		load_fnsact@HPGICCI1 (TNS V1-V3)	update ICCICCS set CCSMAXOVER...
8	8	172,983	0.00	1.16		load_fnsact@HPGICCI1 (TNS V1-V3)	select * from ICCIPRODCODE wh...

SQL ordered by CPU Time

Resources reported for PL/SQL code includes the resources used by all SQL statements called by the code.
% Total DB Time is the Elapsed Time of the SQL statement divided into the Total Database Time multiplied by 100

CPU Time (s)	Elapsed Time (s)	Executions	CPU per Exec (s)	% Total DB Time	SQL Id	SQL Module	SQL Text
75	76	172,329	0.00	11.52		load_fnsact@HPGICCI1 (TNS V1-V3)	insert into ICCICCS values (:...
57	93	1	57.31	14.10		cuidmain@HPGICCI1 (TNS V1-V3)	insert into CUID select CUID_...
42	51	1	42.43	7.68		cusmmain@HPGICCI1 (TNS V1-V3)	insert into CUSM select CUSM_...
42	58	1	42.01	8.75		cumimain@HPGICCI1 (TNS V1-V3)	insert into CUMI select CUSV_...
36	38	166,069	0.00	5.67			select c.name, u.name from co...
23	23	172,329	0.00	3.46		load_fnsact@HPGICCI1 (TNS V1-V3)	insert into iccifnsact values...
14	14	172,983	0.00	2.16		load_fnsact@HPGICCI1 (TNS V1-V3)	update ICCIFNSACT set BORM_AD...
13	13	172,337	0.00	2.00		load_oldnewact@HPGICCI1 (TNS V1-V3)	insert into OLDNEWACT values ...
13	13	166,051	0.00	1.89		icci_migact@HPGICCI1 (TNS V1-V3)	insert into ICCICCS values (:...
11	15	5	2.23	2.25			DECLARE job BINARY_INTEGER := ...
8	8	172,329	0.00	1.25		load_fnsact@HPGICCI1 (TNS V1-V3)	update ICCICCS set CCSMAXOVER...
8	10	5	1.60	1.44			INSERT INTO STATS$SGA_TARGET_A...
8	8	172,983	0.00	1.16		load_fnsact@HPGICCI1 (TNS V1-V3)	select * from ICCIPRODCODE wh...
4	10	1	3.54	1.46		cuidmain@HPGICCI1 (TNS V1-V3)	select CUID_CUST_NO , CUID_ID_...
3	35	1	3.13	5.28		SQL*Plus	SELECT F.TABLESPACE_NAME, TO_...

SQL ordered by Gets

Resources reported for PL/SQL code includes the resources used by all SQL statements called by the code.
Total Buffer Gets: 16,648,792
Captured SQL account for 97.9% of Total

這一部分，透過Buffer Gets對SQL語句進行排序，即透過它執行了多少個邏輯I/O來排序。頂端的註釋表明一個PL/SQL單元的快取獲得(Buffer Gets)包括被這個程式碼塊執行的所有SQL語句的Buffer Gets。因此將經常在這個列表的頂端看到PL/SQL過程，因為儲存過程執行的單獨的語句的數目被總計出來。在這裡的Buffer Gets是一個累積值，所以這個值大並不一定意味著這條語句的效能存在問題。通常我們可以透過對比該條語句的Buffer Gets和physical reads值，如果這兩個比較接近，肯定這條語句是存在問題的，我們可以透過執行計劃來分析，為什麼physical reads的值如此之高。另外，我們在這裡也可以關注gets per exec的值，這個值如果太大，表明這條語句可能使用了一個比較差的索引或者使用了不當的表連線。

另外說明一點：大量的邏輯讀往往伴隨著較高的CPU消耗。所以很多時候我們看到的系統CPU將近100％的時候，很多時候就是SQL語句造成的，這時候我們可以分析一下這裡邏輯讀大的SQL。

select * from

(select substr(sql_text,1,40) sql, buffer_gets,

executions, buffer_gets/executions "Gets/Exec",

hash_value,address

from v$sqlarea

where buffer_gets > 0 and executions>0

order by buffer_gets desc)

where rownum <= 10 ;

Buffer Gets	Executions	Gets per Exec	%Total	CPU Time (s)	Elapsed Time (s)	SQL Id	SQL Module	SQL Text
3,305,363	172,329	19.18	19.85	74.57	76.41		load_fnsact@HPGICCI1 (TNS V1-V3)	insert into ICCICCS values (:...
2,064,414	1	2,064,414.00	12.40	57.31	93.50		cuidmain@HPGICCI1 (TNS V1-V3)	insert into CUID select CUID_...
1,826,869	166,069	11.00	10.97	35.84	37.60			select c.name, u.name from co...
1,427,648	172,337	8.28	8.58	12.97	13.29		load_oldnewact@HPGICCI1 (TNS V1-V3)	insert into OLDNEWACT values ...
1,278,667	172,329	7.42	7.68	22.85	22.94		load_fnsact@HPGICCI1 (TNS V1-V3)	insert into iccifnsact values...
1,216,367	1	1,216,367.00	7.31	42.43	50.93		cusmmain@HPGICCI1 (TNS V1-V3)	insert into CUSM select CUSM_...
1,107,305	1	1,107,305.00	6.65	42.01	58.04		cumimain@HPGICCI1 (TNS V1-V3)	insert into CUMI select CUSV_...
898,868	172,983	5.20	5.40	14.28	14.34		load_fnsact@HPGICCI1 (TNS V1-V3)	update ICCIFNSACT set BORM_AD...
711,450	166,051	4.28	4.27	12.52	12.55		icci_migact@HPGICCI1 (TNS V1-V3)	insert into ICCICCS values (:...
692,996	172,329	4.02	4.16	8.31	8.31		load_fnsact@HPGICCI1 (TNS V1-V3)	update ICCICCS set CCSMAXOVER...
666,748	166,052	4.02	4.00	6.36	6.36		icci_migact@HPGICCI1 (TNS V1-V3)	select NEWACTNO into :b0 from...
345,357	172,983	2.00	2.07	7.70	7.71		load_fnsact@HPGICCI1 (TNS V1-V3)	select * from ICCIPRODCODE wh...
231,756	51,633	4.49	1.39	5.75	5.83		load_fnsact@HPGICCI1 (TNS V1-V3)	insert into ICCIRPYV values (...

SQL ordered by Reads

Total Disk Reads: 322,678
Captured SQL account for 66.1% of Total

這部分透過物理讀對SQL語句進行排序。這顯示引起大部分對這個系統進行讀取活動的SQL，即物理I/O。當我們的系統如果存在I/O瓶頸時，需要關注這裡I/O操作比較多的語句。

select * from

(select substr(sql_text,1,40) sql, disk_reads,

executions, disk_reads/executions "Reads/Exec",

hash_value,address

from v$sqlarea where disk_reads > 0 and executions >0

order by disk_reads desc) where rownum <= 10;

Physical Reads	Executions	Reads per Exec	%Total	CPU Time (s)	Elapsed Time (s)	SQL Id	SQL Module	SQL Text
66,286	1	66,286.00	20.54	57.31	93.50		cuidmain@HPGICCI1 (TNS V1-V3)	insert into CUID select CUID_...
50,646	1	50,646.00	15.70	3.54	9.70		cuidmain@HPGICCI1 (TNS V1-V3)	select CUID_CUST_NO , CUID_ID_...
24,507	1	24,507.00	7.59	42.01	58.04		cumimain@HPGICCI1 (TNS V1-V3)	insert into CUMI select CUSV_...
21,893	1	21,893.00	6.78	42.43	50.93		cusmmain@HPGICCI1 (TNS V1-V3)	insert into CUSM select CUSM_...
19,761	1	19,761.00	6.12	2.14	6.04		cumimain@HPGICCI1 (TNS V1-V3)	select CUSV_CUST_NO from CUMI...
19,554	1	19,554.00	6.06	1.27	3.83		SQL*Plus	select count(*) from CUSVAA_T...
6,342	1	6,342.00	1.97	3.13	35.00		SQL*Plus	SELECT F.TABLESPACE_NAME, TO_...
4,385	1	4,385.00	1.36	1.59	2.43		cusmmain@HPGICCI1 (TNS V1-V3)	select CUSM_CUST_ACCT_NO from...
63	5	12.60	0.02	11.17	14.91			DECLARE job BINARY_INTEGER := ...
35	1	35.00	0.01	0.08	0.67		SQL*Plus	BEGIN dbms_workload_repository...

SQL ordered by Executions

Total Executions: 1,675,112
Captured SQL account for 99.8% of Total

這部分告訴我們在這段時間中執行次數最多的SQL語句。為了隔離某些頻繁執行的查詢，以觀察是否有某些更改邏輯的方法以避免必須如此頻繁的執行這些查詢，這可能是很有用的。或許一個查詢正在一個迴圈的內部執行，而且它可能在迴圈的外部執行一次，可以設計簡單的演算法更改以減少必須執行這個查詢的次數。即使它執行的飛快，任何被執行幾百萬次的操作都將開始耗盡大量的時間。

select * from

(select substr(sql_text,1,40) sql, executions,

rows_processed, rows_processed/executions "Rows/Exec",

hash_value,address

from v$sqlarea where executions > 0

order by executions desc) where rownum <= 10 ;

Executions	Rows Processed	Rows per Exec	CPU per Exec (s)	Elap per Exec (s)	SQL Id	SQL Module	SQL Text
172,983	172,329	1.00	0.00	0.00		load_fnsact@HPGICCI1 (TNS V1-V3)	select * from ICCIPRODCODE wh...
172,983	172,329	1.00	0.00	0.00		load_fnsact@HPGICCI1 (TNS V1-V3)	update ICCIFNSACT set BORM_AD...
172,337	172,337	1.00	0.00	0.00		load_oldnewact@HPGICCI1 (TNS V1-V3)	insert into OLDNEWACT values ...
172,329	172,329	1.00	0.00	0.00		load_fnsact@HPGICCI1 (TNS V1-V3)	insert into iccifnsact values...
172,329	172,329	1.00	0.00	0.00		load_fnsact@HPGICCI1 (TNS V1-V3)	update ICCICCS set CCSMAXOVER...
172,329	6,286	0.04	0.00	0.00		load_fnsact@HPGICCI1 (TNS V1-V3)	insert into ICCICCS values (:...
166,069	166,069	1.00	0.00	0.00			select c.name, u.name from co...
166,052	166,052	1.00	0.00	0.00		icci_migact@HPGICCI1 (TNS V1-V3)	select NEWACTNO into :b0 from...
166,051	166,051	1.00	0.00	0.00		icci_migact@HPGICCI1 (TNS V1-V3)	insert into ICCICCS values (:...
51,740	51,740	1.00	0.00	0.00		load_fnsact@HPGICCI1 (TNS V1-V3)	select count(*) into :b0 fro...
51,633	51,633	1.00	0.00	0.00		load_fnsact@HPGICCI1 (TNS V1-V3)	insert into ICCIRPYV values (...

SQL ordered by Parse Calls

Total Parse Calls: 182,780
Captured SQL account for 99.0% of Total

在這一部分，主要顯示PARSE與EXECUTIONS的對比情況。如果PARSE/EXECUTIONS>1，往往說明這個語句可能存在問題：沒有使用繫結變數，共享池設定太小，cursor_sharing被設定為exact，沒有設定session_cached_cursors等等問題。

select * from

(select substr(sql_text,1,40) sql, parse_calls,

executions, hash_value,address

from v$sqlarea where parse_calls > 0

order by parse_calls desc) where rownum <= 10 ;

Parse Calls	Executions	% Total Parses	SQL Id	SQL Module	SQL Text
166,069	166,069	90.86			select c.name, u.name from co...
6,304	6,304	3.45			select type#, blocks, extents,...
2,437	2,438	1.33			select file# from file$ where ...
1,568	1,568	0.86			update seg$ set type#=:4, bloc...
1,554	1,554	0.85			update tsq$ set blocks=:3, max...
444	444	0.24			select blocks, maxblocks, gran...
421	421	0.23			lock table sys.mon_mods$ in ex...
421	421	0.23			update sys.mon_mods$ set inser...
86	86	0.05			INSERT INTO sys.wri$_adv_messa...
81	81	0.04			SELECT sys.wri$_adv_seq_msggro...

SQL ordered by Sharable Memory

No data exists for this section of the report.

在這一部分，主要是針對shared memory佔用的情況進行排序。

select * from

(select substr(sql_text,1,40) sql, sharable_mem,

executions, hash_value,address

from v$sqlarea where sharable_mem > 1048576

order by sharable_mem desc)

where rownum <= 10;

Running Time top 10 sql

select * from

(select t.sql_fulltext,

(t.last_active_time-to_date(t.first_load_time,'yyyy-mm-dd hh24:mi:ss'))*24*60,

disk_reads,buffer_gets,rows_processed,

t.last_active_time,t.last_load_time,t.first_load_time

from v$sqlarea t order by t.first_load_time desc)

where rownum < 10;

SQL ordered by Version Count

No data exists for this section of the report.

在這一部分，主要是針對SQL語句的多版本進行排序。相同的SQL文字，但是不同屬性，比如物件owner不同，會話最佳化模式不同、型別不同、長度不同和繫結變數不同等等的語句，他們是不能共享的，所以再快取中會存在多個不同的版本。這當然就造成了資源上的更多的消耗。

SQL ordered by Cluster Wait Time

Cluster Wait Time (s)	CWT % of Elapsd Time	Elapsed Time(s)	CPU Time(s)	Executions	SQL Id	SQL Module	SQL Text
10.96	11.72	93.50	57.31	1		cuidmain@HPGICCI1 (TNS V1-V3)	insert into CUID select CUID_...
4.21	7.25	58.04	42.01	1		cumimain@HPGICCI1 (TNS V1-V3)	insert into CUMI select CUSV_...
3.62	7.12	50.93	42.43	1		cusmmain@HPGICCI1 (TNS V1-V3)	insert into CUSM select CUSM_...
2.39	6.35	37.60	35.84	166,069			select c.name, u.name from co...
2.38	3.12	76.41	74.57	172,329		load_fnsact@HPGICCI1 (TNS V1-V3)	insert into ICCICCS values (:...
1.64	16.91	9.70	3.54	1		cuidmain@HPGICCI1 (TNS V1-V3)	select CUID_CUST_NO , CUID_ID_...
1.06	3.02	35.00	3.13	1		SQL*Plus	SELECT F.TABLESPACE_NAME, TO_...
0.83	13.76	6.04	2.14	1		cumimain@HPGICCI1 (TNS V1-V3)	select CUSV_CUST_NO from CUMI...
0.66	87.90	0.75	0.42	444			select blocks, maxblocks, gran...
0.50	13.01	3.83	1.27	1		SQL*Plus	select count(*) from CUSVAA_T...
0.50	51.75	0.96	0.79	1,554			update tsq$ set blocks=:3, max...
0.33	91.11	0.36	0.33	187			select obj#, type#, ctime, mti...
0.33	2.47	13.29	12.97	172,337		load_oldnewact@HPGICCI1 (TNS V1-V3)	insert into OLDNEWACT values ...
0.29	1.26	22.94	22.85	172,329		load_fnsact@HPGICCI1 (TNS V1-V3)	insert into iccifnsact values...
0.25	10.14	2.43	1.59	1		cusmmain@HPGICCI1 (TNS V1-V3)	select CUSM_CUST_ACCT_NO from...
0.21	27.92	0.74	0.74	1,568			update seg$ set type#=:4, bloc...
0.20	3.49	5.83	5.75	51,633		load_fnsact@HPGICCI1 (TNS V1-V3)	insert into ICCIRPYV values (...
0.17	1.39	12.55	12.52	166,051		icci_migact@HPGICCI1 (TNS V1-V3)	insert into ICCICCS values (:...
0.16	57.64	0.28	0.24	39		cusvaamain@HPGICCI1 (TNS V1-V3)	BEGIN BEGIN IF (xdb.DBMS...
0.14	74.58	0.19	0.14	121			select o.owner#, o.name, o.nam...
0.11	64.72	0.18	0.15	80		cusvaamain@HPGICCI1 (TNS V1-V3)	SELECT /+ ALL_ROWS / COUNT(*...
0.11	94.54	0.12	0.01	17			delete from con$ where owner#=...
0.11	80.26	0.14	0.14	327			select intcol#, nvl(pos#, 0), ...
0.08	19.20	0.42	0.24	1			begin prvt_hdm.auto_execute( :...
0.07	54.97	0.13	0.13	83			select i.obj#, i.ts#, i.file#,...
0.06	5.22	1.13	0.72	77			select obj#, type#, flags, ...
0.06	86.50	0.06	0.06	45			select owner#, name from con$...
0.06	8.19	0.67	0.08	1		SQL*Plus	BEGIN dbms_workload_repository...
0.04	75.69	0.06	0.06	87			select pos#, intcol#, col#, sp...
0.04	48.05	0.09	0.07	7			select file#, block# from seg...
0.04	8.84	0.40	0.40	6,304			select type#, blocks, extents,...
0.03	28.15	0.12	0.12	49			delete from RecycleBin$ ...
0.03	66.23	0.05	0.05	85			select t.ts#, t.file#, t.block...
0.03	67.03	0.05	0.05	38		DBMS_SCHEDULER	update obj$ set obj#=:6, type#...
0.02	66.73	0.04	0.04	86			INSERT INTO sys.wri$_adv_messa...
0.02	26.94	0.09	0.09	38			delete from RecycleBin$ ...
0.02	76.76	0.03	0.03	51			select con# from con$ where ow...
0.02	51.91	0.05	0.05	84			select name, intcol#, segcol#,...
0.02	0.15	14.91	11.17	5			DECLARE job BINARY_INTEGER := ...
0.02	2.12	1.00	0.99	8,784		load_fnsact@HPGICCI1 (TNS V1-V3)	update ICCIFNSACT set BORM_FA...
0.02	53.82	0.03	0.03	39		cusvaamain@HPGICCI1 (TNS V1-V3)	SELECT count(*) FROM user_poli...
0.01	0.10	14.34	14.28	172,983		load_fnsact@HPGICCI1 (TNS V1-V3)	update ICCIFNSACT set BORM_AD...
0.01	8.29	0.16	0.13	421			update sys.mon_mods$ set inser...
0.01	1.65	0.56	0.54	2			insert into wrh$_latch (snap...
0.01	22.33	0.04	0.02	26		load_curmmast@HPGICCI1 (TNS V1-V3)	insert into ICCICURMMAST valu...
0.01	0.08	7.71	7.70	172,983		load_fnsact@HPGICCI1 (TNS V1-V3)	select * from ICCIPRODCODE wh...

對於出現在上面的可疑的sql語句，我們可以檢視語句相關的執行計劃，然後分析相關索引等是否合理。

透過語句檢視執行計劃的方法:

SELECT id,parent_id,LPAD(' ',4*(LEVEL-1))||operation||' '||options||' '||object_name "Execution plan" ,cost,cardinality,bytes

FROM (

SELECT p.* FROM v$sql_plan p,v$sql s WHERE p.address = s.ADDRESS

AND p.hash_value = s.HASH_VALUE

and p.hash_value = '&hash_value'

)

CONNECT BY PRIOR id = parent_id

START WITH id = 0;

檢視，分析，最佳化索引等在這裡就不再一一描述了。

Complete List of SQL Text

SQL Id	SQL Text
04xtrk7uyhknh	select obj#, type#, ctime, mtime, stime, status, dataobj#, flags, oid$, spare1, spare2 from obj$ where owner#=:1 and name=:2 and namespace=:3 and remoteowner is null and linkname is null and subname is null
0hhmdwwgxbw0r	select obj#, type#, flags, related, bo, purgeobj, con# from RecycleBin$ where ts#=:1 and to_number(bitand(flags, 16)) = 16 order by dropscn
0k8h617b8guhf	delete from RecycleBin$ where purgeobj=:1
0pvtkmrrq8usg	select file#, block# from seg$ where type# = 3 and ts# = :1
0v9t4qb1zb2b	select CUID_CUST_NO , CUID_ID_TYPE , CUID_ID_RECNO from CUID_TMP where CHGFLAG='D'
104pd9mm3fh9p	select blocks, maxblocks, grantor#, priv1, priv2, priv3 from tsq$ where ts#=:1 and user#=:2
1crajpb7j5tyz	INSERT INTO STATS$SGA_TARGET_ADVICE ( SNAP_ID , DBID , INSTANCE_NUMBER , SGA_SIZE , SGA_SIZE_FACTOR , ESTD_DB_TIME , ESTD_DB_TIME_FACTOR , ESTD_PHYSICAL_READS ) SELECT :B3 , :B2 , :B1 , SGA_SIZE , SGA_SIZE_FACTOR , ESTD_DB_TIME , ESTD_DB_TIME_FACTOR , ESTD_PHYSICAL_READS FROM V$SGA_TARGET_ADVICE
1dm3bq36vu3g8	insert into iccifnsact values (:b0, :b1, :b2, null , null , :b3, :b4, GREATEST(:b5, :b6), null , :b7, :b8, null , :b9, :b10, :b6, null , null , null , null , null , :b12, null , null , null , :b13, :b14, null , null , :b15, :b16, :b17)
1gu8t96d0bdmu	select t.ts#, t.file#, t.block#, nvl(t.bobj#, 0), nvl(t.tab#, 0), t.intcols, nvl(t.clucols, 0), t.audit$, t.flags, t.pctfree$, t.pctused$, t.initrans, t.maxtrans, t.rowcnt, t.blkcnt, t.empcnt, t.avgspc, t.chncnt, t.avgrln, t.analyzetime, t.samplesize, t.cols, t.property, nvl(t.degree, 1), nvl(t.instances, 1), t.avgspc_flb, t.flbcnt, t.kernelcols, nvl(t.trigflag, 0), nvl(t.spare1, 0), nvl(t.spare2, 0), t.spare4, t.spare6, ts.cachedblk, ts.cachehit, ts.logicalread from tab$ t, tab_stats$ ts where t.obj#= :1 and t.obj# = ts.obj# (+)
1uk5m5qbzj1vt	BEGIN dbms_workload_repository.create_snapshot; END;
2ym6hhaq30r73	select type#, blocks, extents, minexts, maxexts, extsize, extpct, user#, iniexts, NVL(lists, 65535), NVL(groups, 65535), cachehint, hwmincr, NVL(spare1, 0), NVL(scanhint, 0) from seg$ where ts#=:1 and file#=:2 and block#=:3
350f5yrnnmshs	lock table sys.mon_mods$ in exclusive mode nowait
38apjgr0p55ns	update ICCICCS set CCSMAXOVERDUE=GREATEST(:b0, CCSMAXOVERDUE) where FNSACTNO=:b1
38gak8u2qm11w	select count(*) from CUSVAA_TMP
3m8smr0v7v1m6	INSERT INTO sys.wri$_adv_message_groups (task_id, id, seq, message#, fac, hdr, lm, nl, p1, p2, p3, p4, p5) VALUES (:1, :2, :3, :4, :5, :6, :7, :8, :9, :10, :11, :12, :13)
44au3v5mzpc1c	insert into ICCICURMMAST values (:b0, :b1, :b2)
49ms69srnaxzj	insert into ICCIRPYV values (:b0, :b1, :b2, :b3, :b4, :b5, :b6, :b7, :b8, :b9, :b10, :b11, :b12, :b13, :b14, :b15, :b16, :b17, :b18, :b19, :b20, :b21, :b22, :b23, :b24, :b25, :b26, :b27, :b28, :b29, :b30, :b31, :b32, :b33, :b34, :b35, :b36, :b37, :b38, :b39, :b40, :b41, :b42, :b43, :b44, :b45, :b46, :b47, :b48, :b49, :b50, :b51)
4vja2k2gdtyup	insert into ICCICCS values (:b0, '////////////////////////', 0, 0, 0, 0, 0, ' ', 0, 0, 0, ' ', '0', null )
501v412s13r4m	update ICCIFNSACT set BORM_FACILITY_NO=:b0 where BORM_MEMB_CUST_AC=:b1
53saa2zkr6wc3	select intcol#, nvl(pos#, 0), col#, nvl(spare1, 0) from ccol$ where con#=:1
569r5k05drsj7	insert into CUMI select CUSV_CUST_NO , CUSV_EDUCATION_CODE , CHGDATE from CUMI_TMP where CHGFLAG<>'D'
5c4qu2zmj3gux	select * from ICCIPRODCODE where PRODCODE=to_char(:b0)
5ngzsfstg8tmy	select o.owner#, o.name, o.namespace, o.remoteowner, o.linkname, o.subname, o.dataobj#, o.flags from obj$ o where o.obj#=:1
6769wyy3yf66f	select pos#, intcol#, col#, spare1, bo#, spare2 from icol$ where obj#=:1
6z06gcfw39pkd	SELECT F.TABLESPACE_NAME, TO_CHAR ((T.TOTAL_SPACE - F.FREE_SPACE), '999, 999') "USED (MB)", TO_CHAR (F.FREE_SPACE, '999, 999') "FREE (MB)", TO_CHAR (T.TOTAL_SPACE, '999, 999') "TOTAL (MB)", TO_CHAR ((ROUND ((F.FREE_SPACE/T.TOTAL_SPACE)100)), '999')\|\|' %' PER_FREE FROM ( SELECT TABLESPACE_NAME, ROUND (SUM (BLOCKS(SELECT VALUE/1024 FROM V$PARAMETER WHERE NAME = 'db_block_size')/1024) ) FREE_SPACE FROM DBA_FREE_SPACE GROUP BY TABLESPACE_NAME ) F, ( SELECT TABLESPACE_NAME, ROUND (SUM (BYTES/1048576)) TOTAL_SPACE FROM DBA_DATA_FILES GROUP BY TABLESPACE_NAME ) T WHERE F.TABLESPACE_NAME = T.TABLESPACE_NAME
78m9ryygp65v5	SELECT /+ ALL_ROWS / COUNT(*) FROM ALL_POLICIES V WHERE V.OBJECT_OWNER = :B3 AND V.OBJECT_NAME = :B2 AND (POLICY_NAME LIKE '%xdbrls%' OR POLICY_NAME LIKE '%$xd_%') AND V.FUNCTION = :B1
7gtztzv329wg0	select c.name, u.name from con$ c, cdef$ cd, user$ u where c.con# = cd.con# and cd.enabled = :1 and c.owner# = u.user#
7ng34ruy5awxq	select i.obj#, i.ts#, i.file#, i.block#, i.intcols, i.type#, i.flags, i.property, i.pctfree$, i.initrans, i.maxtrans, i.blevel, i.leafcnt, i.distkey, i.lblkkey, i.dblkkey, i.clufac, i.cols, i.analyzetime, i.samplesize, i.dataobj#, nvl(i.degree, 1), nvl(i.instances, 1), i.rowcnt, mod(i.pctthres$, 256), i.indmethod#, i.trunccnt, nvl(c.unicols, 0), nvl(c.deferrable#+c.valid#, 0), nvl(i.spare1, i.intcols), i.spare4, i.spare2, i.spare6, decode(i.pctthres$, null, null, mod(trunc(i.pctthres$/256), 256)), ist.cachedblk, ist.cachehit, ist.logicalread from ind$ i, ind_stats$ ist, (select enabled, min(cols) unicols, min(to_number(bitand(defer, 1))) deferrable#, min(to_number(bitand(defer, 4))) valid# from cdef$ where obj#=:1 and enabled > 1 group by enabled) c where i.obj#=c.enabled(+) and i.obj# = ist.obj#(+) and i.bo#=:1 order by i.obj#
7v9dyf5r424yh	select NEWACTNO into :b0 from OLDNEWACT where OLDACTNO=:b1
7wwv1ybs9zguz	update ICCIFNSACT set BORM_ADV_DATE=:b0, BOIS_MATURITY_DATE=:b1, BOIS_UNPD_BAL=:b2, BOIS_UNPD_INT=:b3, BOIS_BAL_FINE=:b4, BOIS_INT_FINE=:b5, BOIS_FINE_FINE=:b6, BORM_LOAN_TRM=:b7, BORM_FIVE_STAT=:b8, BOIS_ARREARS_CTR=:b9, BOIS_ARREARS_SUM=:b10 where BORM_MEMB_CUST_AC=:b11
83taa7kaw59c1	select name, intcol#, segcol#, type#, length, nvl(precision#, 0), decode(type#, 2, nvl(scale, -127/MAXSB1MINAL/), 178, scale, 179, scale, 180, scale, 181, scale, 182, scale, 183, scale, 231, scale, 0), null$, fixedstorage, nvl(deflength, 0), default$, rowid, col#, property, nvl(charsetid, 0), nvl(charsetform, 0), spare1, spare2, nvl(spare3, 0) from col$ where obj#=:1 order by intcol#
4qubbrsr0kfn	insert into wrh$_latch (snap_id, dbid, instance_number, latch_hash, level#, gets, misses, sleeps, immediate_gets, immediate_misses, spin_gets, sleep1, sleep2, sleep3, sleep4, wait_time) select :snap_id, :dbid, :instance_number, hash, level#, gets, misses, sleeps, immediate_gets, immediate_misses, spin_gets, sleep1, sleep2, sleep3, sleep4, wait_time from v$latch order by hash
9qgtwh66xg6nz	update seg$ set type#=:4, blocks=:5, extents=:6, minexts=:7, maxexts=:8, extsize=:9, extpct=:10, user#=:11, iniexts=:12, lists=decode(:13, 65535, NULL, :13), groups=decode(:14, 65535, NULL, :14), cachehint=:15, hwmincr=:16, spare1=DECODE(:17, 0, NULL, :17), scanhint=:18 where ts#=:1 and file#=:2 and block#=:3
9vtm7gy4fr2ny	select con# from con$ where owner#=:1 and name=:2
a2any035u1qz1	select owner#, name from con$ where con#=:1
a7nh7j8zmfrzw	select CUSV_CUST_NO from CUMI_TMP where CHGFLAG='D'

Instance Activity Statistics

Instance Activity Stats

Statistic	Total	per Second	per Trans
CPU used by this session	23,388	4.95	4.18
CPU used when call started	21,816	4.61	3.90
CR blocks created	2,794	0.59	0.50
Cached Commit SCN referenced	237,936	50.33	42.50
Commit SCN cached	3	0.00	0.00
DB time	583,424	123.41	104.22
DBWR checkpoint buffers written	402,781	85.20	71.95
DBWR checkpoints	9	0.00	0.00
DBWR fusion writes	255	0.05	0.05
DBWR object drop buffers written	0	0.00	0.00
DBWR thread checkpoint buffers written	221,341	46.82	39.54
DBWR transaction table writes	130	0.03	0.02
DBWR undo block writes	219,272	46.38	39.17
DFO trees parallelized	16	0.00	0.00
PX local messages recv'd	40	0.01	0.01
PX local messages sent	40	0.01	0.01
PX remote messages recv'd	80	0.02	0.01
PX remote messages sent	80	0.02	0.01
Parallel operations not downgraded	16	0.00	0.00
RowCR - row contention	9	0.00	0.00
RowCR attempts	14	0.00	0.00
RowCR hits	5	0.00	0.00
SMON posted for undo segment recovery	0	0.00	0.00
SMON posted for undo segment shrink	9	0.00	0.00
SQL*Net roundtrips to/from client	1,544,063	326.62	275.82
active txn count during cleanout	276,652	58.52	49.42
application wait time	1,620	0.34	0.29
auto extends on undo tablespace	0	0.00	0.00
background checkpoints completed	7	0.00	0.00
background checkpoints started	9	0.00	0.00
background timeouts	21,703	4.59	3.88
branch node splits	337	0.07	0.06
buffer is not pinned count	1,377,184	291.32	246.01
buffer is pinned count	20,996,139	4,441.37	3,750.65
bytes received via SQL*Net from client	7,381,397,183	1,561,408.36	1,318,577.56
bytes sent via SQL*Net to client	149,122,035	31,544.22	26,638.45
calls to get snapshot scn: kcmgss	1,696,712	358.91	303.09
calls to kcmgas	433,435	91.69	77.43
calls to kcmgcs	142,482	30.14	25.45
change write time	4,707	1.00	0.84
cleanout - number of ktugct calls	282,045	59.66	50.38
cleanouts and rollbacks - consistent read gets	55	0.01	0.01
cleanouts only - consistent read gets	2,406	0.51	0.43
cluster key scan block gets	21,886	4.63	3.91
cluster key scans	10,540	2.23	1.88
cluster wait time	2,855	0.60	0.51
commit batch/immediate performed	294	0.06	0.05
commit batch/immediate requested	294	0.06	0.05
commit cleanout failures: block lost	2,227	0.47	0.40
commit cleanout failures: callback failure	750	0.16	0.13
commit cleanout failures: cannot pin	4	0.00	0.00
commit cleanouts	427,610	90.45	76.39
commit cleanouts successfully completed	424,629	89.82	75.85
commit immediate performed	294	0.06	0.05
commit immediate requested	294	0.06	0.05
commit txn count during cleanout	111,557	23.60	19.93
concurrency wait time	515	0.11	0.09
consistent changes	1,716	0.36	0.31
consistent gets	5,037,471	1,065.59	899.87
由consistent gets，db block gets和physical reads這三個值，我們也可以計算得到buffer hit ratio，計算的公式如下： buffer hit ratio = 100(1-physical reads /(consistent gets+ db block gets))，例如在這裡，我們可以計算得到：buffer hit ratio =100(1-26524/(16616758+2941398))= 99.86
consistent gets - examination	2,902,016	613.87	518.40
consistent gets direct	0	0.00	0.00
consistent gets from cache	5,037,471	1,065.59	899.87
current blocks converted for CR	0	0.00	0.00
cursor authentications	434	0.09	0.08
data blocks consistent reads - undo records applied	1,519	0.32	0.27
db block changes	8,594,158	1,817.95	1,535.22
db block gets	11,611,321	2,456.18	2,074.19
db block gets direct	1,167,830	247.03	208.62
db block gets from cache	10,443,491	2,209.14	1,865.58
deferred (CURRENT) block cleanout applications	20,786	4.40	3.71
dirty buffers inspected	25,007	5.29	4.47
髒資料從LRU列表中老化，A value here indicates that the DBWR is not keeping up。如果這個值大於0，就需要考慮增加DBWRs。 dirty buffers inspected: This is the number of dirty (modified) data buffers that were aged out on the LRU list. You may benefit by adding more DBWRs.If it is greater than 0, consider increasing the database writes.
drop segment calls in space pressure	0	0.00	0.00
enqueue conversions	6,734	1.42	1.20
enqueue releases	595,149	125.89	106.31
enqueue requests	595,158	125.90	106.32
enqueue timeouts	9	0.00	0.00
enqueue waits	7,901	1.67	1.41
exchange deadlocks	1	0.00	0.00
execute count	1,675,112	354.34	299.23
free buffer inspected	536,832	113.56	95.90
這個值包含dirty，pinned，busy的buffer區域，如果free buffer inspected - dirty buffers inspected - buffer is pinned count的值還是比較大，表明不能被重用的記憶體塊比較多，這將導致latch爭用，需要增大buffer cache
free buffer requested	746,999	158.01	133.44
gc CPU used by this session	9,099	1.92	1.63
gc cr block build time	13	0.00	0.00
gc cr block flush time	143	0.03	0.03
gc cr block receive time	474	0.10	0.08
gc cr block send time	36	0.01	0.01
gc cr blocks received	4,142	0.88	0.74
gc cr blocks served	10,675	2.26	1.91
gc current block flush time	23	0.00	0.00
gc current block pin time	34	0.01	0.01
gc current block receive time	1,212	0.26	0.22
gc current block send time	52	0.01	0.01
gc current blocks received	15,502	3.28	2.77
gc current blocks served	17,534	3.71	3.13
gc local grants	405,329	85.74	72.41
gc remote grants	318,630	67.40	56.92
gcs messages sent	1,129,094	238.84	201.70
ges messages sent	90,695	19.18	16.20
global enqueue get time	1,707	0.36	0.30
global enqueue gets async	12,731	2.69	2.27
global enqueue gets sync	190,492	40.30	34.03
global enqueue releases	190,328	40.26	34.00
global undo segment hints helped	0	0.00	0.00
global undo segment hints were stale	0	0.00	0.00
heap block compress	108,758	23.01	19.43
hot buffers moved to head of LRU	18,652	3.95	3.33
immediate (CR) block cleanout applications	2,462	0.52	0.44
immediate (CURRENT) block cleanout applications	325,184	68.79	58.09
index crx upgrade (positioned)	4,663	0.99	0.83
index fast full scans (full)	13	0.00	0.00
index fetch by key	852,181	180.26	152.23
index scans kdiixs1	339,583	71.83	60.66
leaf node 90-10 splits	34	0.01	0.01
leaf node splits	106,552	22.54	19.03
lob reads	11	0.00	0.00
lob writes	83	0.02	0.01
lob writes unaligned	83	0.02	0.01
local undo segment hints helped	0	0.00	0.00
local undo segment hints were stale	0	0.00	0.00
logons cumulative	61	0.01	0.01
messages received	20,040	4.24	3.58
messages sent	19,880	4.21	3.55
no buffer to keep pinned count	0	0.00	0.00
no work - consistent read gets	1,513,070	320.06	270.29
opened cursors cumulative	183,375	38.79	32.76
parse count (failures)	1	0.00	0.00
parse count (hard)	143	0.03	0.03
parse count (total)	182,780	38.66	32.65
透過parse count (hard)和parse count (total)，可以計算soft parse率為： 100-100(parse count (hard)/parse count (total)) =100-100(1-6090/191531)=96.82
parse time cpu	27	0.01	0.00
parse time elapsed	338	0.07	0.06
physical read IO requests	82,815	17.52	14.79
physical read bytes	2,643,378,176	559,161.45	472,200.46
physical read total IO requests	98,871	20.91	17.66
physical read total bytes	2,905,491,456	614,607.04	519,023.13
physical read total multi block requests	24,089	5.10	4.30
physical reads	322,678	68.26	57.64
physical reads cache	213,728	45.21	38.18
physical reads cache prefetch	191,830	40.58	34.27
physical reads direct	108,950	23.05	19.46
physical reads direct temporary tablespace	108,812	23.02	19.44
physical reads prefetch warmup	0	0.00	0.00
physical write IO requests	223,456	47.27	39.92
physical write bytes	14,042,071,040	2,970,360.02	2,508,408.55
physical write total IO requests	133,835	28.31	23.91
physical write total bytes	23,114,268,672	4,889,428.30	4,129,022.63
physical write total multi block requests	116,135	24.57	20.75
physical writes	1,714,120	362.59	306.20
physical writes direct	1,276,780	270.08	228.08
physical writes direct (lob)	0	0.00	0.00
physical writes direct temporary tablespace	108,812	23.02	19.44
physical writes from cache	437,340	92.51	78.12
physical writes non checkpoint	1,673,703	354.04	298.98
pinned buffers inspected	10	0.00	0.00
prefetch clients - default	0	0.00	0.00
prefetch warmup blocks aged out before use	0	0.00	0.00
prefetch warmup blocks flushed out before use	0	0.00	0.00
prefetched blocks aged out before use	0	0.00	0.00
process last non-idle time	4,730	1.00	0.84
queries parallelized	16	0.00	0.00
recursive calls	1,654,650	350.01	295.58
recursive cpu usage	2,641	0.56	0.47
redo blocks written	8,766,094	1,854.32	1,565.93
redo buffer allocation retries	24	0.01	0.00
redo entries	4,707,068	995.70	840.85
redo log space requests	34	0.01	0.01
redo log space wait time	50	0.01	0.01
redo ordering marks	277,042	58.60	49.49
redo size	4,343,559,400	918,805.72	775,912.72
redo subscn max counts	2,693	0.57	0.48
redo synch time	408	0.09	0.07
redo synch writes	6,984	1.48	1.25
redo wastage	1,969,620	416.64	351.84
redo write time	5,090	1.08	0.91
redo writer latching time	1	0.00	0.00
redo writes	5,494	1.16	0.98
rollback changes - undo records applied	166,609	35.24	29.76
rollbacks only - consistent read gets	1,463	0.31	0.26
rows fetched via callback	342,159	72.38	61.12
session connect time	1,461	0.31	0.26
session cursor cache hits	180,472	38.18	32.24
session logical reads	16,648,792	3,521.77	2,974.06
session pga memory	37,393,448	7,909.94	6,679.79
session pga memory max	45,192,232	9,559.64	8,072.92
session uga memory	30,067,312,240	6,360,225.77	5,371,081.14
session uga memory max	61,930,448	13,100.33	11,062.96
shared hash latch upgrades - no wait	6,364	1.35	1.14
shared hash latch upgrades - wait	0	0.00	0.00
sorts (disk)	4	0.00	0.00
磁碟排序一般不能超過5％。如果超過5％，需要設定引數PGA_AGGREGATE_TARGET或者 SORT_AREA_SIZE，注意，這裡SORT_AREA_SIZE是分配給每個使用者的，PGA_AGGREGATE_TARGET則是針對所有的session的一個總數設定。
sorts (memory)	2,857	0.60	0.51
記憶體中的排序數量
sorts (rows)	42,379,505	8,964.66	7,570.47
space was found by tune down	0	0.00	0.00
space was not found by tune down	0	0.00	0.00
sql area evicted	7	0.00	0.00
sql area purged	44	0.01	0.01
steps of tune down ret. in space pressure	0	0.00	0.00
summed dirty queue length	35,067	7.42	6.26
switch current to new buffer	17	0.00	0.00
table fetch by rowid	680,469	143.94	121.56
這是透過索引或者where rowid=語句來取得的行數，當然這個值越大越好。
table fetch continued row	0	0.00	0.00
這是發生行遷移的行。當行遷移的情況比較嚴重時，需要對這部分進行最佳化。檢查行遷移的方法： 1）執行$ORACLE_HOME/rdbms/admin/utlchain.sql 2） analyze table table_name list chained rows into CHAINED_ROWS 3） select * from CHAINED_ROWS where table_name='table_name'; 清除的方法：方法1：create table table_name_tmp as select * from table_name where rowed in (select head_rowid from chained_rows); Delete from table_name where rowed in (select head_rowid from chained_rows); Insert into table_name select * from table_name_tmp; 方法2：create table table_name_tmp select * from table_name ; truncate table table_name insert into table_name select * from table_name_tmp 方法3：用exp工具匯出表，然後刪除這個表，最後用imp工具匯入這表方法4：alter table table_name move tablespace tablespace_name，然後再重新表的索引上面的4種方法可以用以消除已經存在的行遷移現象，但是行遷移的產生很多情況下時由於PCT_FREE引數設定的太小所導致，所以需要調整PCT_FREE引數的值。
table scan blocks gotten	790,986	167.32	141.30
table scan rows gotten	52,989,363	11,208.99	9,465.77
table scans (long tables)	4	0.00	0.00
longtables就是表的大小超過buffer buffer* _SMALL_TABLE_THRESHOLD的表。如果一個資料庫的大表掃描過多，那麼db file scattered read等待事件可能同樣非常顯著。如果table scans (long tables)的per Trans值大於0，你可能需要增加適當的索引來最佳化你的SQL語句
table scans (short tables)	169,201	35.79	30.23
short tables是指表的長度低於buffer chache 2％（2％是有隱含引數_SMALL_TABLE_THRESHOLD定義的，這個引數在oracle不同的版本中，有不同的含義。在9i和10g中，該引數值定義為2%，在8i中，該引數值為20個blocks，在v7中，該引數為5個blocks）的表。這些表將優先使用全表掃描。一般不使用索引。_SMALL_TABLE_THRESHOLD值的計算方法如下（9i,8K）： (db_cache_size/8192)*2％。注意：_SMALL_TABLE_THRESHOLD引數修改是相當危險的操作
total number of times SMON posted	259	0.05	0.05
transaction lock background get time	0	0.00	0.00
transaction lock background gets	0	0.00	0.00
transaction lock foreground requests	0	0.00	0.00
transaction lock foreground wait time	0	0.00	0.00
transaction rollbacks	294	0.06	0.05
tune down retentions in space pressure	0	0.00	0.00
undo change vector size	1,451,085,596	306,952.35	259,215.00
user I/O wait time	11,992	2.54	2.14
user calls	1,544,383	326.69	275.88
user commits	812	0.17	0.15
user rollbacks	4,786	1.01	0.85
workarea executions - onepass	1	0.00	0.00
workarea executions - optimal	1,616	0.34	0.29
write clones created in background	0	0.00	0.00
write clones created in foreground	11	0.00	0.00

Instance Activity Stats - Absolute Values

Statistics with absolute values (should not be diffed)

Statistic	Begin Value	End Value
session cursor cache count	3,024	3,592
opened cursors current	37	39
logons current	24	26

Instance Activity Stats - Thread Activity

Statistics identified by '(derived)' come from sources other than SYSSTAT

Statistic	Total	per Hour
log switches (derived)	9	6.85

IO Stats

通常，在這裡期望在各裝置上的讀取和寫入操作是均勻分佈的。要找出什麼檔案可能非常“熱”。一旦DBA瞭解瞭如何讀取和寫入這些資料，他們也許能夠透過磁碟間更均勻的分配I/O而得到某些效能提升。

在這裡主要關注Av Rd(ms)列 (reads per millisecond)的值，一般來說，大部分的磁碟系統的這個值都能調整到14ms以下，oracle認為該值超過20ms都是不必要的。如果該值超過1000ms，基本可以肯定存在I/O的效能瓶頸。如果在這一列上出現######，可能是你的系統存在嚴重的I/O問題，也可能是格式的顯示問題。

當出現上面的問題，我們可以考慮以下的方法：

1）最佳化操作該表空間或者檔案的相關的語句。

2）如果該表空間包含了索引，可以考慮壓縮索引，是索引的分佈空間減小，從而減小I/O。

3）將該表空間分散在多個邏輯卷中，平衡I/O的負載。

4）我們可以透過設定引數DB_FILE_MULTIBLOCK_READ_COUNT來調整讀取的並行度，這將提高全表掃描的效率。但是也會帶來一個問題，就是oracle會因此更多的使用全表掃描而放棄某些索引的使用。為解決這個問題，我們需要設定另外一個引數OPTIMIZER_INDEX_COST_ADJ=30（一般建議設定10－50）。

關於OPTIMIZER_INDEX_COST_ADJ＝n：該引數是一個百分比值，預設值為100，可以理解為FULL SCAN COST/INDEX SCAN COST。當n%* INDEX SCAN COST<FULL SCAN COST時，oracle會選擇使用索引。在具體設定的時候，我們可以根據具體的語句來調整該值。如果我們希望某個statement使用索引，而實際它確走全表掃描，可以對比這兩種情況的執行計劃不同的COST，從而設定一個更合適的值。

5）檢查並調整I/O裝置的效能。

Tablespace IO Stats

ordered by IOs (Reads + Writes) desc

Tablespace	Reads	Av Reads/s	Av Rd(ms)	Av Blks/Rd	Writes	Av Writes/s	Buffer Waits	Av Buf Wt(ms)
ICCIDAT01	67,408	14	3.76	3.17	160,261	34	6	0.00
UNDOTBS1	10	0	12.00	1.00	57,771	12	625	0.02
TEMP	15,022	3	8.74	7.24	3,831	1	0	0.00
USERS	68	0	5.44	1.00	971	0	0	0.00
SYSAUX	263	0	5.48	1.00	458	0	0	0.00
SYSTEM	32	0	5.94	1.00	158	0	3	23.33
UNDOTBS2	6	0	16.67	1.00	6	0	0	0.00

顯示每個表空間的I/O統計。根據Oracle經驗，Av Rd(ms) [Average Reads in milliseconds]不應該超過30，否則認為有I/O爭用。

File IO Stats

ordered by Tablespace, File

Tablespace	Filename	Reads	Av Reads/s	Av Rd(ms)	Av Blks/Rd	Writes	Av Writes/s	Buffer Waits	Av Buf Wt(ms)
ICCIDAT01	/dev/rora_icci01	5,919	1	4.30	3.73	15,161	3	1	0.00
ICCIDAT01	/dev/rora_icci02	7,692	2	4.12	3.18	16,555	4	0	0.00
ICCIDAT01	/dev/rora_icci03	6,563	1	2.59	3.80	15,746	3	0	0.00
ICCIDAT01	/dev/rora_icci04	8,076	2	2.93	3.11	16,164	3	0	0.00
ICCIDAT01	/dev/rora_icci05	6,555	1	2.61	3.31	21,958	5	0	0.00
ICCIDAT01	/dev/rora_icci06	6,943	1	4.03	3.41	20,574	4	0	0.00
ICCIDAT01	/dev/rora_icci07	7,929	2	4.12	2.87	18,263	4	0	0.00
ICCIDAT01	/dev/rora_icci08	7,719	2	3.83	2.99	17,361	4	0	0.00
ICCIDAT01	/dev/rora_icci09	6,794	1	4.79	3.29	18,425	4	0	0.00
ICCIDAT01	/dev/rora_icci10	211	0	5.31	1.00	6	0	0	0.00
ICCIDAT01	/dev/rora_icci11	1,168	0	4.45	1.00	6	0	0	0.00
ICCIDAT01	/dev/rora_icci12	478	0	4.23	1.00	6	0	0	0.00
ICCIDAT01	/dev/rora_icci13	355	0	5.13	1.00	6	0	0	0.00
ICCIDAT01	/dev/rora_icci14	411	0	4.91	1.00	6	0	1	0.00
ICCIDAT01	/dev/rora_icci15	172	0	5.29	1.00	6	0	1	0.00
ICCIDAT01	/dev/rora_icci16	119	0	7.23	1.00	6	0	1	0.00
ICCIDAT01	/dev/rora_icci17	227	0	6.26	1.00	6	0	1	0.00
ICCIDAT01	/dev/rora_icci18	77	0	8.44	1.00	6	0	1	0.00
SYSAUX	/dev/rora_SYSAUX	263	0	5.48	1.00	458	0	0	0.00
SYSTEM	/dev/rora_SYSTEM	32	0	5.94	1.00	158	0	3	23.33
TEMP	/dev/rora_TEMP	3,653	1	5.67	6.61	827	0	0
TEMP	/dev/rora_TEMP2	2,569	1	4.42	6.70	556	0	0
TEMP	/dev/rora_TEMP3	1,022	0	2.50	16.86	557	0	0
TEMP	/dev/rora_TEMP5	7,778	2	12.43	6.46	1,891	0	0
UNDOTBS1	/dev/rora_UNDO0101	10	0	12.00	1.00	57,771	12	625	0.02
UNDOTBS2	/dev/rora_UNDO0201	6	0	16.67	1.00	6	0	0	0.00
USERS	/dev/rora_USERS	68	0	5.44	1.00	971	0	0	0.00

Buffer Pool Statistics

Standard block size Pools D: default, K: keep, R: recycle
Default Pools for other block sizes: 2k, 4k, 8k, 16k, 32k

P	Number of Buffers	Pool Hit%	Buffer Gets	Physical Reads	Physical Writes	Free Buff Wait	Writ Comp Wait	Buffer Busy Waits
D	401,071	99	15,480,754	213,729	437,340	0	0	634

這裡將buffer poll細分，列舉default、keep、recycle三種型別的buffer的詳細情況。在這份報告中，我們的系統中只使用Default size的buffer pool。這裡的3個waits統計，其實在前面的等待時間中已經包含，所以可以參考前面的描述。關於命中率也已經在前面討論。所以，其實這段資訊不需要怎麼關注。

Advisory Statistics

Instance Recovery Stats

B: Begin snapshot, E: End snapshot

	Targt MTTR (s)	Estd MTTR (s)	Recovery Estd IOs	Actual Redo Blks	Target Redo Blks	Log File Size Redo Blks	Log Ckpt Timeout Redo Blks	Log Ckpt Interval Redo Blks
B	0	11	369	2316	5807	1883700	5807
E	0	98	116200	1828613	1883700	1883700	5033355

Buffer Pool Advisory

Only rows with estimated physical reads >0 are displayed
ordered by Block Size, Buffers For Estimate

這是oracle的對buffer pool的大小的調整建議。從advisory的資料看，當然buffer是越大，物理讀更小，隨著buffer的增大，對物理讀的效能改進越來越小。當前buffer 設定為5,120M，物理讀因子=1。我們可以看到，buffer pool在3G之前的擴大，對物理讀的改善非常明顯，之後，這種改善的程度越來越低。

P	Size for Est (M)	Size Factor	Buffers for Estimate	Est Phys Read Factor	Estimated Physical Reads
D	320	0.10	38,380	1.34	10,351,726
D	640	0.19	76,760	1.25	9,657,000
D	960	0.29	115,140	1.08	8,365,242
D	1,280	0.38	153,520	1.04	8,059,415
D	1,600	0.48	191,900	1.02	7,878,202
D	1,920	0.57	230,280	1.01	7,841,140
D	2,240	0.67	268,660	1.01	7,829,141
D	2,560	0.77	307,040	1.01	7,817,370
D	2,880	0.86	345,420	1.01	7,804,884
D	3,200	0.96	383,800	1.00	7,784,014
D	3,344	1.00	401,071	1.00	7,748,403
D	3,520	1.05	422,180	0.99	7,702,243
D	3,840	1.15	460,560	0.99	7,680,429
D	4,160	1.24	498,940	0.99	7,663,046
D	4,480	1.34	537,320	0.99	7,653,232
D	4,800	1.44	575,700	0.99	7,645,544
D	5,120	1.53	614,080	0.98	7,630,008
D	5,440	1.63	652,460	0.98	7,616,886
D	5,760	1.72	690,840	0.98	7,614,591
D	6,080	1.82	729,220	0.98	7,613,191
D	6,400	1.91	767,600	0.98	7,599,930

PGA Aggr Summary

PGA cache hit % - percentage of W/A (WorkArea) data processed only in-memory

PGA Cache Hit %	W/A MB Processed	Extra W/A MB Read/Written
87.91	1,100	151

PGA Aggr Target Stats

B: Begin snap E: End snap (rows dentified with B or E contain data which is absolute i.e. not diffed over the interval)
Auto PGA Target - actual workarea memory target
W/A PGA Used - amount of memory used for all Workareas (manual + auto)
%PGA W/A Mem - percentage of PGA memory allocated to workareas
%Auto W/A Mem - percentage of workarea memory controlled by Auto Mem Mgmt
%Man W/A Mem - percentage of workarea memory under manual control

	PGA Aggr Target(M)	Auto PGA Target(M)	PGA Mem Alloc(M)	W/A PGA Used(M)	%PGA W/A Mem	%Auto W/A Mem	%Man W/A Mem	Global Mem Bound(K)
B	1,024	862	150.36	0.00	0.00	0.00	0.00	104,850
E	1,024	860	154.14	0.00	0.00	0.00	0.00	104,850

PGA Aggr Target Histogram

Optimal Executions are purely in-memory operations

Low Optimal	High Optimal	Total Execs	Optimal Execs	1-Pass Execs	M-Pass Execs
2K	4K	1,385	1,385	0	0
64K	128K	28	28	0	0
128K	256K	5	5	0	0
256K	512K	79	79	0	0
512K	1024K	108	108	0	0
1M	2M	7	7	0	0
8M	16M	1	1	0	0
128M	256M	3	2	1	0
256M	512M	1	1	0	0

PGA Memory Advisory

When using Auto Memory Mgmt, minimally choose a pga_aggregate_target value where Estd PGA Overalloc Count is 0

PGA Target Est (MB)	Size Factr	W/A MB Processed	Estd Extra W/A MB Read/ Written to Disk	Estd PGA Cache Hit %	Estd PGA Overalloc Count
128	0.13	4,652.12	2,895.99	62.00	0
256	0.25	4,652.12	2,857.13	62.00	0
512	0.50	4,652.12	2,857.13	62.00	0
768	0.75	4,652.12	2,857.13	62.00	0
1,024	1.00	4,652.12	717.82	87.00	0
1,229	1.20	4,652.12	717.82	87.00	0
1,434	1.40	4,652.12	717.82	87.00	0
1,638	1.60	4,652.12	717.82	87.00	0
1,843	1.80	4,652.12	717.82	87.00	0
2,048	2.00	4,652.12	717.82	87.00	0
3,072	3.00	4,652.12	717.82	87.00	0
4,096	4.00	4,652.12	717.82	87.00	0
6,144	6.00	4,652.12	717.82	87.00	0
8,192	8.00	4,652.12	717.82	87.00	0

Shared Pool Advisory

SP: Shared Pool Est LC: Estimated Library Cache Factr: Factor
Note there is often a 1:Many correlation between a single logical object in the Library Cache, and the physical number of memory objects associated with it. Therefore comparing the number of Lib Cache objects (e.g. in v$librarycache), with the number of Lib Cache Memory Objects is invalid.

Shared Pool Size(M)	SP Size Factr	Est LC Size (M)	Est LC Mem Obj	Est LC Time Saved (s)	Est LC Time Saved Factr	Est LC Load Time (s)	Est LC Load Time Factr	Est LC Mem Obj Hits
304	0.43	78	7,626	64,842	1.00	31	1.00	3,206,955
384	0.55	78	7,626	64,842	1.00	31	1.00	3,206,955
464	0.66	78	7,626	64,842	1.00	31	1.00	3,206,955
544	0.77	78	7,626	64,842	1.00	31	1.00	3,206,955
624	0.89	78	7,626	64,842	1.00	31	1.00	3,206,955
704	1.00	78	7,626	64,842	1.00	31	1.00	3,206,955
784	1.11	78	7,626	64,842	1.00	31	1.00	3,206,955
864	1.23	78	7,626	64,842	1.00	31	1.00	3,206,955
944	1.34	78	7,626	64,842	1.00	31	1.00	3,206,955
1,024	1.45	78	7,626	64,842	1.00	31	1.00	3,206,955
1,104	1.57	78	7,626	64,842	1.00	31	1.00	3,206,955
1,184	1.68	78	7,626	64,842	1.00	31	1.00	3,206,955
1,264	1.80	78	7,626	64,842	1.00	31	1.00	3,206,955
1,344	1.91	78	7,626	64,842	1.00	31	1.00	3,206,955
1,424	2.02	78	7,626	64,842	1.00	31	1.00	3,206,955

SGA Target Advisory

SGA Target Size (M)	SGA Size Factor	Est DB Time (s)	Est Physical Reads
1,024	0.25	9,060	9,742,760
2,048	0.50	7,612	7,948,245
3,072	0.75	7,563	7,886,258
4,096	1.00	7,451	7,748,338
5,120	1.25	7,423	7,713,470
6,144	1.50	7,397	7,680,927
7,168	1.75	7,385	7,666,980
8,192	2.00	7,385	7,666,980

Streams Pool Advisory

No data exists for this section of the report.

Java Pool Advisory

No data exists for this section of the report.

Wait Statistics

Buffer Wait Statistics

ordered by wait time desc, waits desc

Class	Waits	Total Wait Time (s)	Avg Time (ms)
data block	3	0	23
undo header	616	0	0
file header block	8	0	0
undo block	7	0	0

Enqueue Activity

only enqueues with waits are shown
Enqueue stats gathered prior to 10g should not be compared with 10g data
ordered by Wait Time desc, Waits desc

Enqueue Type (Request Reason)	Requests	Succ Gets	Failed Gets	Waits	Wt Time (s)	Av Wt Time(ms)
FB-Format Block	14,075	14,075	0	7,033	3	0.43
US-Undo Segment	964	964	0	556	0	0.32
WF-AWR Flush	24	24	0	14	0	9.00
HW-Segment High Water Mark	4,223	4,223	0	37	0	1.22
CF-Controlfile Transaction	10,548	10,548	0	58	0	0.67
TX-Transaction (index contention)	1	1	0	1	0	35.00
TM-DML	121,768	121,761	6	70	0	0.43
PS-PX Process Reservation	103	103	0	46	0	0.65
TT-Tablespace	9,933	9,933	0	39	0	0.54
TD-KTF map table enqueue (KTF dump entries)	12	12	0	12	0	1.42
TA-Instance Undo	18	18	0	13	0	0.38
PI-Remote PX Process Spawn Status	16	16	0	8	0	0.50
MW-MWIN Schedule	3	3	0	3	0	0.67
DR-Distributed Recovery	3	3	0	3	0	0.33
TS-Temporary Segment	14	11	3	3	0	0.33
AF-Advisor Framework (task serialization)	14	14	0	1	0	1.00
JS-Job Scheduler (job run lock - synchronize)	2	2	0	1	0	1.00
UL-User-defined	2	2	0	1	0	1.00
MD-Materialized View Log DDL	6	6	0	2	0	0.00

Undo Statistics

Undo從9i開始，回滾段一般都是自動管理的，一般情況下，這裡我們不需要太重點關注。

在這裡，主要關注pct waits，如果出現比較多的pct waits，那就需要增加回滾段的數量或者增大回滾段的空間。另外，觀察一下各個回滾段使用的情況，比較理想的是各個回滾段上Avg Active比較均衡。

在oracle 9i之前，回滾段時手工管理的，可以透過指定optimal值來設定一個回滾段收縮的值，如果不設定，預設也應當為initial+(minextents-1)*next extents ，這個指定的結果，就是限制了回滾段不能無限制的增長，當超過optimal的設定值後，在適當的時候，oracle會shrinks到optimal大小。但是9i之後，undo一般都設定為auto模式，在這種模式下，我們無法指定optimal值，好像也沒有預設值，所以無法shrinks，回滾段就會無限制的增長，一直到表空間利用率達到為100％，如果表空間設定為自動擴充套件的方式，這種情況下，就更糟糕，undo將無限制的增長。在這裡，我們也可以看到，shrinks的值為0，也就是說，從來就沒收縮過。

Segment Summary

Min/Max TR (mins) - Min and Max Tuned Retention (minutes)
STO - Snapshot Too Old count, OOS - Out of Space count
Undo segment block stats:
uS - unexpired Stolen, uR - unexpired Released, uU - unexpired reUsed
eS - expired Stolen, eR - expired Released, eU - expired reUsed

Undo TS#	Num Undo Blocks (K)	Number of Transactions	Max Qry Len (s)	Max Tx Concurcy	Min/Max TR (mins)	STO/ OOS	uS/uR/uU/ eS/eR/eU
1	219.12	113,405	0	6	130.95/239.25	0/0	0/0/0/13/24256/0

Undo Segment Stats

Most recent 35 Undostat rows, ordered by Time desc

End Time	Num Undo Blocks	Number of Transactions	Max Qry Len (s)	Max Tx Concy	Tun Ret (mins)	STO/ OOS	uS/uR/uU/ eS/eR/eU
25-Dec 15:18	182,021	74,309	0	5	131	0/0	0/0/0/13/24256/0
25-Dec 15:08	57	170	0	3	239	0/0	0/0/0/0/0/0
25-Dec 14:58	68	31	0	2	229	0/0	0/0/0/0/0/0
25-Dec 14:48	194	4,256	0	4	219	0/0	0/0/0/0/0/0
25-Dec 14:38	570	12,299	0	5	209	0/0	0/0/0/0/0/0
25-Dec 14:28	36,047	21,328	0	6	200	0/0	0/0/0/0/0/0
25-Dec 14:18	70	907	0	3	162	0/0	0/0/0/0/0/0
25-Dec 14:08	91	105	0	3	154	0/0	0/0/0/0/0/0

Latch Statistics

Latch是一種低階排隊機制，用於防止對記憶體結構的並行訪問，保護系統全域性區(SGA)共享記憶體結構。Latch是一種快速地被獲取和釋放的記憶體鎖。如果latch不可用，就會記錄latch free miss 。

有兩種型別的Latch:willing to wait和（immediate）not willing to wait。

對於願意等待型別(willing-to-wait)的latch,如果一個程式在第一次嘗試中沒有獲得latch,那麼它會等待並且再嘗試一次,如果經過_spin_count次爭奪不能獲得latch, 然後該程式轉入睡眠狀態，百分之一秒之後醒來，按順序重複以前的步驟。在8i/9i中預設值是_spin_count=2000。睡眠的時間會越來越長。

　　對於不願意等待型別(not-willing-to-wait)的latch，如果該閂不能立即得到的話，那麼該程式就不會為獲得該閂而等待。它將繼續執行另一個操作。

　　大多數Latch問題都可以歸結為以下幾種:

　　沒有很好的是用繫結變數(library cache latch和shared pool cache)、重作生成問題(redo allocation latch)、緩衝儲存競爭問題(cache buffers LRU chain)，以及buffer cache中的存在"熱點"塊(cache buffers chain)。

另外也有一些latch等待與bug有關，應當關注Metalink相關bug的公佈及補丁的釋出。

當latch miss ratios大於0.5%時，就需要檢查latch的等待問題。

如果SQL語句不能調整，在8.1.6版本以上，可以透過設定CURSOR_SHARING = force 在伺服器端強制繫結變數。設定該引數可能會帶來一定的副作用，可能會導致執行計劃不優，另外對於Java的程式，有相關的bug，具體應用應該關注Metalink的bug公告。

下面對幾個重要型別的latch等待加以說明：

1) latch free：當‘latch free’在報告的高等待事件中出現時，就表示可能出現了效能問題，就需要在這一部分詳細分析出現等待的具體的latch的型別，然後再調整。

2) cache buffers chain：cbc latch表明熱塊。為什麼這會表示存在熱塊？為了理解這個問題，先要理解cbc的作用。ORACLE對buffer cache管理是以hash連結串列的方式來實現的（oracle稱為buckets，buckets的數量由_db_block_hash_buckets定義）。cbc latch就是為了保護buffer cache而設定的。當有併發的訪問需求時，cbc會將這些訪問序列化，當我們獲得cbc latch的控制權時，就可以開始訪問資料，如果我們所請求的資料正好的某個buckets中，那就直接從記憶體中讀取資料，完成之後釋放cbc latch，cbc latch就可以被其他的使用者獲取了。cbc latch獲取和釋放是非常快速的，所以這種情況下就一般不會存在等待。但是如果我們請求的資料在記憶體中不存在，就需要到物理磁碟上讀取資料，這相對於latch來說就是一個相當長的時間了，當找到對應的資料塊時，如果有其他使用者正在訪問這個資料塊，並且資料塊上也沒有空閒的ITL槽來接收本次請求，就必須等待。在這過程中，我們因為沒有得到請求的資料，就一直佔有cbc latch，其他的使用者也就無法獲取cbc latch，所以就出現了cbc latch等待的情況。所以這種等待歸根結底就是由於資料塊比較hot的造成的。
解決方法可以參考前面在等待事件中的3) buffer busy wait中關於熱塊的解決方法。

3) cache buffers lru chain：該latch用於掃描buffer的LRU連結串列。三種情況可導致爭用：1）buffer cache太小；2）buffer cache的過度使用，或者太多的基於cache的排序操作；3）DBWR不及時。解決方法：查詢邏輯讀過高的statement，增大buffer cache。

4) Library cache and shared pool 爭用：
library cache是一個hash table，我們需要透過一個hash buckets陣列來訪問（類似buffer cache）。library cache latch就是將對library cache的訪問序列化。當有一個sql（或者PL/SQL procedure，package，function，trigger）需要執行的時候，首先需要獲取一個latch，然後library cache latch就會去查詢library cache以重用這些語句。在8i中，library cache latch只有一個。在9i中，有7個child latch，這個數量可以透過引數_KGL_LATCH_ COUNT修改（最大可以達到66個）。當共享池太小或者語句的reuse低的時候，會出現‘shared pool’、‘library cache pin’或者 ‘library cache’ latch的爭用。解決的方法是：增大共享池或者設定CURSOR_SHARING=FORCE|SIMILAR ，當然我們也需要tuning SQL statement。為減少爭用，我們也可以把一些比較大的SQL或者過程利用DBMS_SHARED_POOL.KEEP包來pinning在shared pool中。
shared pool記憶體結構與buffer cache類似，也採用的是hash方式來管理的。共享池有一個固定數量的hash buckets，透過固定數量的library cache latch來序列化保護這段記憶體的使用。在資料啟動的時候，會分配509個hash buctets，2*CPU_COUNT個library cache latch。當在資料庫的使用中，共享池中的物件越來越多，oracle就會以以下的遞增方式增加hash buckets的數量：509,1021,4093,8191,32749,65521,131071,4292967293。我們可以透過設定下面的引數來實現_KGL_BUCKET_COUNT，引數的預設值是0，代表數量509，最大我們可以設定為8，代表數量131071。
我們可以透過x$ksmsp來檢視具體的共享池記憶體段情況，主要關注下面幾個欄位：
KSMCHCOM—表示記憶體段的型別
ksmchptr—表示記憶體段的實體地址
ksmchsiz—表示記憶體段的大小
ksmchcls—表示記憶體段的分類。recr表示a recreatable piece currently in use that can be a candidate for flushing when the shared pool is low in available memory; freeabl表示當前正在使用的，能夠被釋放的段； free表示空閒的未分配的段； perm表示不能被釋放永久分配段。
降低共享池的latch 爭用，我們主要可以考慮如下的幾個事件：
1、使用繫結變數
2、使用cursor sharing
3、設定session_cached_cursors引數。該引數的作用是將cursor從shared pool轉移到pga中。減小對共享池的爭用。一般初始的值可以設定為100，然後視情況再作調整。
4、設定合適大小的共享池

5) Redo Copy：這個latch用來從PGA中copy redo records到redo log buffer。latch的初始數量是2*COU_OUNT，可以透過設定引數_LOG_SIMULTANEOUS_COPIES在增加latch的數量，減小爭用。

6) Redo allocation：該latch用於redo log buffer的分配。減小這種型別的爭用的方法有3個：
增大redo log buffer
適當使用nologging選項
避免不必要的commit操作

7) Row cache objects：該latch出現爭用，通常表明資料字典存在爭用的情況，這往往也預示著過多的依賴於公共同義詞的parse。解決方法：1）增大shared pool 2）使用本地管理的表空間，尤其對於索引表空間

Latch事件	建議解決方法
Library cache	使用繫結變數; 調整shared_pool_size.
Shared pool	使用繫結變數; 調整shared_pool_size.
Redo allocation	減小 redo 的產生；避免不必要的commits.
Redo copy	增加 _log_simultaneous_copies.
Row cache objects	增加shared_pool_size
Cache buffers chain	增大 _DB_BLOCK_HASH_BUCKETS ； make it prime.
Cache buffers LRU chain	使用多個緩衝池；調整引起大量邏輯讀的查詢

注：在這裡，提到了不少隱藏引數，也有利用隱藏引數來解決latch的方法描述，但是在實際的操作中，強烈建議儘量不要去更改隱藏引數的預設值。

Latch Activity

"Get Requests", "Pct Get Miss" and "Avg Slps/Miss" are statistics for willing-to-wait latch get requests
"NoWait Requests", "Pct NoWait Miss" are for no-wait latch get requests
"Pct Misses" for both should be very close to 0.0

Latch Name	Get Requests	Pct Get Miss	Avg Slps /Miss	Wait Time (s)	NoWait Requests	Pct NoWait Miss
ASM db client latch	11,883	0.00		0	0
AWR Alerted Metric Element list	18,252	0.00		0	0
Consistent RBA	5,508	0.02	0.00	0	0
FOB s.o list latch	731	0.00		0	0
JS broadcast add buf latch	6,193	0.00		0	0
JS broadcast drop buf latch	6,194	0.00		0	0
JS broadcast load blnc latch	6,057	0.00		0	0
JS mem alloc latch	8	0.00		0	0
JS queue access latch	8	0.00		0	0
JS queue state obj latch	218,086	0.00		0	0
JS slv state obj latch	31	0.00		0	0
KCL gc element parent latch	2,803,392	0.04	0.01	0	108	0.00
KJC message pool free list	43,168	0.06	0.00	0	14,532	0.01
KJCT flow control latch	563,875	0.00	0.00	0	0
KMG MMAN ready and startup request latch	1,576	0.00		0	0
KSXR large replies	320	0.00		0	0
KTF sga latch	23	0.00		0	1,534	0.00
KWQMN job cache list latch	352	0.00		0	0
KWQP Prop Status	5	0.00		0	0
MQL Tracking Latch	0			0	94	0.00
Memory Management Latch	0			0	1,576	0.00
OS process	207	0.00		0	0
OS process allocation	1,717	0.00		0	0
OS process: request allocation	73	0.00		0	0
PL/SQL warning settings	226	0.00		0	0
SGA IO buffer pool latch	20,679	0.06	0.00	0	20,869	0.00
SQL memory manager latch	7	0.00		0	1,575	0.00
SQL memory manager workarea list latch	439,442	0.00		0	0
Shared B-Tree	182	0.00		0	0
Undo Hint Latch	0			0	12	0.00
active checkpoint queue latch	7,835	0.00		0	0
active service list	50,936	0.00		0	1,621	0.00
archive control	5	0.00		0	0
begin backup scn array	72,901	0.00	0.00	0	0
business card	32	0.00		0	0
cache buffer handles	331,153	0.02	0.00	0	0
cache buffers chains	48,189,073	0.00	0.00	0	1,201,379	0.00
cache buffers lru chain	891,796	0.34	0.00	0	991,605	0.23
cache table scan latch	0			0	10,309	0.01
channel handle pool latch	99	0.00		0	0
channel operations parent latch	490,324	0.01	0.00	0	0
checkpoint queue latch	671,856	0.01	0.00	0	555,469	0.02
client/application info	335	0.00		0	0
commit callback allocation	12	0.00		0	0
compile environment latch	173,428	0.00		0	0
dml lock allocation	243,087	0.00	0.00	0	0
dummy allocation	134	0.00		0	0
enqueue hash chains	1,539,499	0.01	0.03	0	263	0.00
enqueues	855,207	0.02	0.00	0	0
error message lists	64	0.00		0	0
event group latch	38	0.00		0	0
file cache latch	4,694	0.00		0	0
gcs drop object freelist	8,451	0.19	0.00	0	0
gcs opaque info freelist	38,584	0.00	0.00	0	0
gcs partitioned table hash	9,801,867	0.00		0	0
gcs remaster request queue	31	0.00		0	0
gcs remastering latch	1,014,198	0.00	0.33	0	0
gcs resource freelist	1,154,551	0.03	0.00	0	771,650	0.00
gcs resource hash	3,815,373	0.02	0.00	0	2	0.00
gcs resource scan list	4	0.00		0	0
gcs shadows freelist	795,482	0.00	0.00	0	779,648	0.00
ges caches resource lists	209,655	0.02	0.00	0	121,613	0.01
ges deadlock list	840	0.00		0	0
ges domain table	366,702	0.00		0	0
ges enqueue table freelist	487,875	0.00		0	0
ges group table	543,887	0.00		0	0
ges process hash list	59,503	0.00		0	0
ges process parent latch	908,232	0.00		0	1	0.00
ges process table freelist	73	0.00		0	0
ges resource hash list	862,590	0.02	0.28	0	72,266	0.01
ges resource scan list	534	0.00		0	0
ges resource table freelist	135,406	0.00	0.00	0	0
ges synchronous data	160	0.63	0.00	0	2,954	0.07
ges timeout list	3,256	0.00		0	4,478	0.00
global KZLD latch for mem in SGA	21	0.00		0	0
hash table column usage latch	59	0.00		0	1,279	0.00
hash table modification latch	116	0.00		0	0
job workq parent latch	0			0	14	0.00
job_queue_processes parameter latch	86	0.00		0	0
kks stats	384	0.00		0	0
ksuosstats global area	329	0.00		0	0
ktm global data	296	0.00		0	0
kwqbsn:qsga	182	0.00		0	0
lgwr LWN SCN	6,547	0.18	0.00	0	0
library cache	235,060	0.00	0.00	0	22	0.00
library cache load lock	486	0.00		0	0
library cache lock	49,284	0.00		0	0
library cache lock allocation	566	0.00		0	0
library cache pin	27,863	0.00	0.00	0	0
library cache pin allocation	204	0.00		0	0
list of block allocation	10,101	0.00		0	0
loader state object freelist	108	0.00		0	0
longop free list parent	6	0.00		0	6	0.00
message pool operations parent latch	1,424	0.00		0	0
messages	222,581	0.00	0.00	0	0
mostly latch-free SCN	6,649	1.43	0.00	0	0
multiblock read objects	29,230	0.03	0.00	0	0
name-service memory objects	18,842	0.00		0	0
name-service namespace bucket	56,712	0.00		0	0
name-service namespace objects	15	0.00		0	0
name-service pending queue	6,436	0.00		0	0
name-service request	44	0.00		0	0
name-service request queue	57,312	0.00		0	0
ncodef allocation latch	77	0.00		0	0
object queue header heap	37,721	0.00		0	7,457	0.00
object queue header operation	2,706,992	0.06	0.00	0	0
object stats modification	22	0.00		0	0
parallel query alloc buffer	939	0.00		0	0
parallel query stats	72	0.00		0	0
parallel txn reco latch	630	0.00		0	0
parameter list	193	0.00		0	0
parameter table allocation management	68	0.00		0	0
post/wait queue	4,205	0.00		0	2,712	0.00
process allocation	46,895	0.00		0	38	0.00
process group creation	73	0.00		0	0
process queue	175	0.00		0	0
process queue reference	2,621	0.00		0	240	62.50
qmn task queue latch	668	0.15	1.00	0	0
query server freelists	159	0.00		0	0
query server process	8	0.00		0	7	0.00
queued dump request	23,628	0.00		0	0
redo allocation	21,206	0.57	0.00	0	4,706,826	0.02
redo copy	0			0	4,707,106	0.01
redo writing	29,944	0.01	0.00	0	0
resmgr group change latch	69	0.00		0	0
resmgr:actses active list	137	0.00		0	0
resmgr:actses change group	52	0.00		0	0
resmgr:free threads list	130	0.00		0	0
resmgr:schema config	7	0.00		0	0
row cache objects	1,644,149	0.00	0.00	0	321	0.00
rules engine rule set statistics	500	0.00		0	0
sequence cache	360	0.00		0	0
session allocation	535,514	0.00	0.00	0	0
session idle bit	3,262,141	0.00	0.00	0	0
session state list latch	166	0.00		0	0
session switching	77	0.00		0	0
session timer	1,620	0.00		0	0
shared pool	60,359	0.00	0.00	0	0
shared pool sim alloc	13	0.00		0	0
shared pool simulator	4,246	0.00		0	0
simulator hash latch	1,862,803	0.00		0	0
simulator lru latch	1,719,480	0.01	0.00	0	46,053	0.00
slave class	2	0.00		0	0
slave class create	8	12.50	1.00	0	0
sort extent pool	1,284	0.00		0	0
state object free list	4	0.00		0	0
statistics aggregation	280	0.00		0	0
temp lob duration state obj allocation	2	0.00		0	0
threshold alerts latch	202	0.00		0	0
transaction allocation	211	0.00		0	0
transaction branch allocation	77	0.00		0	0
undo global data	779,759	0.07	0.00	0	0
user lock	102	0.00		0	0

Latch Sleep Breakdown

ordered by misses desc

Latch Name	Get Requests	Misses	Sleeps	Spin Gets	Sleep1	Sleep2	Sleep3
cache buffers lru chain	891,796	3,061	1	3,060	0	0	0
object queue header operation	2,706,992	1,755	3	1,752	0	0	0
KCL gc element parent latch	2,803,392	1,186	11	1,176	0	0	0
cache buffers chains	48,189,073	496	1	495	0	0	0
ges resource hash list	862,590	160	44	116	0	0	0
enqueue hash chains	1,539,499	79	2	78	0	0	0
gcs remastering latch	1,014,198	3	1	2	0	0	0
qmn task queue latch	668	1	1	0	0	0	0
slave class create	8	1	1	0	0	0	0

Latch Miss Sources

only latches with sleeps are shown
ordered by name, sleeps desc

Latch Name	Where	NoWait Misses	Sleeps	Waiter Sleeps
KCL gc element parent latch	kclrwrite	0	8	0
KCL gc element parent latch	kclnfndnewm	0	4	6
KCL gc element parent latch	KCLUNLNK	0	1	1
KCL gc element parent latch	kclbla	0	1	0
KCL gc element parent latch	kclulb	0	1	1
KCL gc element parent latch	kclzcl	0	1	0
cache buffers chains	kcbnew: new latch again	0	2	0
cache buffers chains	kclwrt	0	1	0
cache buffers lru chain	kcbzgws	0	1	0
enqueue hash chains	ksqcmi: if lk mode not requested	0	2	0
event range base latch	No latch	0	1	1
gcs remastering latch	69	0	1	0
ges resource hash list	kjlmfnd: search for lockp by rename and inst id	0	23	0
ges resource hash list	kjakcai: search for resp by resname	0	13	0
ges resource hash list	kjrmas1: lookup master node	0	5	0
ges resource hash list	kjlrlr: remove lock from resource queue	0	2	33
ges resource hash list	kjcvscn: remove from scan queue	0	1	0
object queue header operation	kcbo_switch_q_bg	0	3	0
object queue header operation	kcbo_switch_mq_bg	0	2	4
object queue header operation	kcbw_unlink_q	0	2	0
object queue header operation	kcbw_link_q	0	1	0
slave class create	ksvcreate	0	1	0

Parent Latch Statistics

No data exists for this section of the report.

Child Latch Statistics

No data exists for this section of the report.

Segment Statistics

DBA_HIST_SEG_STAT

desc DBA_HIST_SEG_STAT

v$sesstat

v$statname

Segments by Logical Reads

Total Logical Reads: 16,648,792
Captured Segments account for 85.2% of Total

Owner	Tablespace Name	Object Name	Subobject Name	Obj. Type	Logical Reads	%Total
ICCI01	ICCIDAT01	ICCICCS_PK		INDEX	1,544,848	9.28
ICCI01	ICCIDAT01	CUSCAD_TMP		TABLE	1,349,536	8.11
ICCI01	ICCIDAT01	ICCIFNSACT_PK		INDEX	1,268,400	7.62
ICCI01	ICCIDAT01	IND_OLDNEWACT		INDEX	1,071,072	6.43
ICCI01	ICCIDAT01	CUID_PK		INDEX	935,584	5.62

Segments by Physical Reads

Total Physical Reads: 322,678
Captured Segments account for 64.2% of Total

Owner	Tablespace Name	Object Name	Subobject Name	Obj. Type	Physical Reads	%Total
ICCI01	ICCIDAT01	CUID_TMP		TABLE	116,417	36.08
ICCI01	ICCIDAT01	CUMI_TMP		TABLE	44,086	13.66
ICCI01	ICCIDAT01	CUSM_TMP		TABLE	26,078	8.08
ICCI01	ICCIDAT01	CUSVAA_TMP_PK		INDEX	19,554	6.06
ICCI01	ICCIDAT01	CUID		TABLE	259	0.08

Segments by Row Lock Waits

當一個程式予在正被其它程式鎖住的資料行上獲得排它鎖時發生這種等待。這種等待經常是由於在一個有主鍵索引的表上做大量INSERT操作。

No data exists for this section of the report.

Segments by ITL Waits

No data exists for this section of the report.

Segments by Buffer Busy Waits

No data exists for this section of the report.

Segments by Global Cache Buffer Busy

% of Capture shows % of GC Buffer Busy for each top segment compared
with GC Buffer Busy for all segments captured by the Snapshot

Owner	Tablespace Name	Object Name	Subobject Name	Obj. Type	GC Buffer Busy	% of Capture
SYS	SYSTEM	TSQ$		TABLE	2	100.00

Segments by CR Blocks Received

Total CR Blocks Received: 4,142
Captured Segments account for 95.6% of Total

Owner	Tablespace Name	Object Name	Subobject Name	Obj. Type	CR Blocks Received	%Total
SYS	SYSTEM	USER$		TABLE	1,001	24.17
SYS	SYSTEM	TSQ$		TABLE	722	17.43
SYS	SYSTEM	SEG$		TABLE	446	10.77
SYS	SYSTEM	OBJ$		TABLE	264	6.37
SYS	SYSTEM	I_OBJ2		INDEX	174	4.20

Segments by Current Blocks Received

Total Current Blocks Received: 15,502
Captured Segments account for 84.8% of Total

Owner	Tablespace Name	Object Name	Subobject Name	Obj. Type	Current Blocks Received	%Total
ICCI01	ICCIDAT01	CUSM_TMP		TABLE	5,764	37.18
ICCI01	ICCIDAT01	CUMI_TMP		TABLE	2,794	18.02
ICCI01	ICCIDAT01	CUID_TMP		TABLE	2,585	16.68
SYS	SYSTEM	SEG$		TABLE	361	2.33
SYS	SYSTEM	TSQ$		TABLE	361	2.33

Dictionary Cache Statistics

/* 庫快取詳細資訊，。

Get Requests：get表示一種型別的鎖，語法分析鎖。這種型別的鎖在引用了一個物件的那條SQL語句的語法分析階段被設定在該物件上。每當一條語句被語法分析一次時 ，Get Requests的值就增加1。

pin requests：pin也表示一種型別的鎖，是在執行發生的加鎖。每當一條語句執行一次，pin requests的值就增加1。

reloads：reloads列顯示一條已執行過的語句因Library Cache使該語句的已語法分析版本過期或作廢而需要被重新語法分析的次數。

invalidations：失效發生在一條已告訴快取的SQL語句即使已經在library cache中，但已被標記為無效並迎詞而被迫重新做語法分析的時候。每當已告訴快取的語句所引用的物件以某種方式被修改時，這些語句就被標記為無效。

pct miss應該不高於1％。

Reloads /pin requests <1％，否則應該考慮增大SHARED_POOL_SIZE。

該部分資訊透過v$librarycache檢視統計得到：

select namespace,gethitratio,pinhitratio,reloads,invalidations

from v$librarycache

where namespace in ('SQL AREA','TABLE/PROCEDURE','BODY','TRIGGER', 'INDEX');

Dictionary Cache Stats

"Pct Misses" should be very low (< 2% in most cases)
"Final Usage" is the number of cache entries being used

Cache	Get Requests	Pct Miss	Scan Reqs	Pct Miss	Mod Reqs	Final Usage
dc_awr_control	86	0.00	0		4	1
dc_constraints	59	91.53	0		20	1,350
dc_files	23	0.00	0		0	23
dc_global_oids	406	0.00	0		0	35
dc_histogram_data	673	0.15	0		0	1,555
dc_histogram_defs	472	24.36	0		0	4,296
dc_object_grants	58	0.00	0		0	154
dc_object_ids	1,974	6.13	0		0	1,199
dc_objects	955	19.58	0		56	2,064
dc_profiles	30	0.00	0		0	1
dc_rollback_segments	3,358	0.00	0		0	37
dc_segments	2,770	2.56	0		1,579	1,312
dc_sequences	9	33.33	0		9	5
dc_table_scns	6	100.00	0		0	0
dc_tablespace_quotas	1,558	28.50	0		1,554	3
dc_tablespaces	346,651	0.00	0		0	7
dc_usernames	434	0.00	0		0	14
dc_users	175,585	0.00	0		0	43
outstanding_alerts	57	71.93	0		0	1

Dictionary Cache Stats (RAC)

Cache	GES Requests	GES Conflicts	GES Releases
dc_awr_control	8	0	0
dc_constraints	88	22	0
dc_histogram_defs	115	0	0
dc_object_ids	143	101	0
dc_objects	253	111	0
dc_segments	3,228	49	0
dc_sequences	17	3	0
dc_table_scns	6	0	0
dc_tablespace_quotas	3,093	441	0
dc_users	8	1	0
outstanding_alerts	113	41	0

Library Cache Statistics

Library Cache Activity

"Pct Misses" should be very low

Namespace	Get Requests	Pct Miss	Pin Requests	Pct Miss	Reloads	Invali- dations
BODY	105	0.00	247	0.00	0	0
CLUSTER	3	0.00	4	0.00	0	0
INDEX	13	46.15	26	42.31	5	0
SQL AREA	56	100.00	1,857,002	0.02	32	12
TABLE/PROCEDURE	179	35.75	3,477	8.02	63	0
TRIGGER	323	0.00	386	0.00	0	0

Library Cache Activity (RAC)

Namespace	GES Lock Requests	GES Pin Requests	GES Pin Releases	GES Inval Requests	GES Invali- dations
BODY	5	0	0	0	0
CLUSTER	4	0	0	0	0
INDEX	26	22	6	17	0
TABLE/PROCEDURE	1,949	285	63	244	0

Memory Statistics

Process Memory Summary

B: Begin snap E: End snap
All rows below contain absolute values (i.e. not diffed over the interval)
Max Alloc is Maximum PGA Allocation size at snapshot time
Hist Max Alloc is the Historical Max Allocation for still-connected processes
ordered by Begin/End snapshot, Alloc (MB) desc

	Category	Alloc (MB)	Used (MB)	Avg Alloc (MB)	Std Dev Alloc (MB)	Max Alloc (MB)	Hist Max Alloc (MB)	Num Proc	Num Alloc
B	Other	136.42		5.25	8.55	24	27	26	26
	Freeable	13.50	0.00	1.50	1.11	3		9	9
	SQL	0.33	0.16	0.03	0.03	0	2	12	10
	PL/SQL	0.12	0.06	0.01	0.01	0	0	24	24
E	Other	138.65		4.78	8.20	24	27	29	29
	Freeable	14.94	0.00	1.36	1.04	3		11	11
	SQL	0.39	0.19	0.03	0.03	0	2	15	12
	PL/SQL	0.18	0.11	0.01	0.01	0	0	27	26

SGA Memory Summary

這部分是關於SGA記憶體分配的一個描述，我們可以透過show sga等命令也可以檢視到這裡的內容。

Fixed Size:

oracle 的不同平臺和不同版本下可能不一樣，但對於確定環境是一個固定的值，裡面儲存了SGA 各部分元件的資訊，可以看作引導建立SGA的區域。

Variable Size:

包含了shared_pool_size、java_pool_size、large_pool_size 等記憶體設定。

Database Buffers:

指資料緩衝區，在8i 中包含db_block_buffer*db_block_size、buffer_pool_keep、buffer_pool_recycle 三部分記憶體。在9i 中包含db_cache_size、db_keep_cache_size、db_recycle_cache_size、 db_nk_cache_size。

Redo Buffers:

指日誌緩衝區，log_buffer。對於logbuffer，我們會發現在v$parameter、v$sgastat、v$sga的值不一樣。v$parameter是我們可以自己設定的值，也可以設定為0，這時候，oracle降會以預設的最小值來設定v$sgastat的值，同時v$sga也是最小的值。v$sgastat的值是基於引數log_buffer的設定值，再根據一定的計算公式得到的一個值。v$sga的值，則是根據v$sgastat的值，然後選擇再加上8k－11k的一個值，得到min(n*4k)的一個值。就是說得到的結果是4k的整數倍，也就是說v$sga是以4k的單位遞增的。

SGA regions	Begin Size (Bytes)	End Size (Bytes) (if different)
Database Buffers	3,506,438,144
Fixed Size	2,078,368
Redo Buffers	14,696,448
Variable Size	771,754,336

SGA breakdown difference

ordered by Pool, Name
N/A value for Begin MB or End MB indicates the size of that Pool/Name was insignificant, or zero in that snapshot

Pool	Name	Begin MB	End MB	% Diff
java	free memory	16.00	16.00	0.00
large	PX msg pool	1.03	1.03	0.00
large	free memory	14.97	14.97	0.00
shared	ASH buffers	15.50	15.50	0.00
shared	CCursor	8.58	8.85	3.09
shared	KQR L PO	8.75	8.80	0.55
shared	db_block_hash_buckets	22.50	22.50	0.00
shared	free memory	371.80	369.61	-0.59
shared	gcs resources	66.11	66.11	0.00
shared	gcs shadows	41.65	41.65	0.00
shared	ges big msg buffers	13.75	13.75	0.00
shared	ges enqueues	7.44	7.56	1.63
shared	ges reserved msg buffers	7.86	7.86	0.00
shared	library cache	10.78	10.93	1.41
shared	row cache	7.16	7.16	0.00
shared	sql area	27.49	28.50	3.67
	buffer_cache	3,344.00	3,344.00	0.00
	fixed_sga	1.98	1.98	0.00
	log_buffer	14.02	14.02	0.00

Streams Statistics

Streams CPU/IO Usage

No data exists for this section of the report.

Streams Capture

No data exists for this section of the report.

Streams Apply

No data exists for this section of the report.

Buffered Queues

No data exists for this section of the report.

Buffered Subscribers

No data exists for this section of the report.

Rule Set

No data exists for this section of the report.

Resource Limit Stats

only rows with Current or Maximum Utilization > 80% of Limit are shown
ordered by resource name

Resource Name	Current Utilization	Maximum Utilization	Initial Allocation	Limit
gcs_resources	349,392	446,903	450063	450063
gcs_shadows	400,300	447,369	450063	450063

init.ora Parameters

Parameter Name	Begin value	End value (if different)
audit_file_dest	/oracle/app/oracle/admin/ICCI/adump
background_dump_dest	/oracle/app/oracle/admin/ICCI/bdump
cluster_database	TRUE
cluster_database_instances	2
compatible	10.2.0.3.0
control_files	/dev/rora_CTL01, /dev/rora_CTL02, /dev/rora_CTL03
core_dump_dest	/oracle/app/oracle/admin/ICCI/cdump
db_block_size	8192
db_domain
db_file_multiblock_read_count	16
db_name	ICCI
dispatchers	(PROTOCOL=TCP) (SERVICE=ICCIXDB)
instance_number	1
job_queue_processes	10
open_cursors	800
pga_aggregate_target	1073741824
processes	500
remote_listener	LISTENERS_ICCI
remote_login_passwordfile	EXCLUSIVE
sga_max_size	4294967296
sga_target	4294967296
sort_area_size	196608
spfile	/dev/rora_SPFILE
thread	1
undo_management	AUTO
undo_retention	900
undo_tablespace	UNDOTBS1
user_dump_dest	/oracle/app/oracle/admin/ICCI/udump

More RAC Statistics

Global Enqueue Statistics

Statistic	Total	per Second	per Trans
acks for commit broadcast(actual)	18,537	3.92	3.31
acks for commit broadcast(logical)	21,016	4.45	3.75
broadcast msgs on commit(actual)	5,193	1.10	0.93
broadcast msgs on commit(logical)	5,491	1.16	0.98
broadcast msgs on commit(wasted)	450	0.10	0.08
dynamically allocated gcs resources	0	0.00	0.00
dynamically allocated gcs shadows	0	0.00	0.00
false posts waiting for scn acks	0	0.00	0.00
flow control messages received	0	0.00	0.00
flow control messages sent	2	0.00	0.00
gcs assume cvt	0	0.00	0.00
gcs assume no cvt	9,675	2.05	1.73
gcs ast xid	1	0.00	0.00
gcs blocked converts	7,099	1.50	1.27
gcs blocked cr converts	8,442	1.79	1.51
gcs compatible basts	45	0.01	0.01
gcs compatible cr basts (global)	273	0.06	0.05
gcs compatible cr basts (local)	12,593	2.66	2.25
gcs cr basts to PIs	0	0.00	0.00
gcs cr serve without current lock	0	0.00	0.00
gcs dbwr flush pi msgs	223	0.05	0.04
gcs dbwr write request msgs	223	0.05	0.04
gcs error msgs	0	0.00	0.00
gcs forward cr to pinged instance	0	0.00	0.00
gcs immediate (compatible) converts	2,998	0.63	0.54
gcs immediate (null) converts	170,925	36.16	30.53
gcs immediate cr (compatible) converts	0	0.00	0.00
gcs immediate cr (null) converts	722,748	152.88	129.11
gcs indirect ast	306,817	64.90	54.81
gcs lms flush pi msgs	0	0.00	0.00
gcs lms write request msgs	189	0.04	0.03
gcs msgs process time(ms)	16,164	3.42	2.89
gcs msgs received	1,792,132	379.09	320.14
gcs out-of-order msgs	0	0.00	0.00
gcs pings refused	0	0.00	0.00
gcs pkey conflicts retry	0	0.00	0.00
gcs queued converts	2	0.00	0.00
gcs recovery claim msgs	0	0.00	0.00
gcs refuse xid	0	0.00	0.00
gcs regular cr	0	0.00	0.00
gcs retry convert request	0	0.00	0.00
gcs side channel msgs actual	437	0.09	0.08
gcs side channel msgs logical	21,086	4.46	3.77
gcs stale cr	3,300	0.70	0.59
gcs undo cr	5	0.00	0.00
gcs write notification msgs	23	0.00	0.00
gcs writes refused	3	0.00	0.00
ges msgs process time(ms)	1,289	0.27	0.23
ges msgs received	138,891	29.38	24.81
global posts dropped	0	0.00	0.00
global posts queue time	0	0.00	0.00
global posts queued	0	0.00	0.00
global posts requested	0	0.00	0.00
global posts sent	0	0.00	0.00
implicit batch messages received	81,181	17.17	14.50
implicit batch messages sent	19,561	4.14	3.49
lmd msg send time(ms)	0	0.00	0.00
lms(s) msg send time(ms)	0	0.00	0.00
messages flow controlled	15,306	3.24	2.73
messages queue sent actual	108,411	22.93	19.37
messages queue sent logical	222,518	47.07	39.75
messages received actual	474,202	100.31	84.71
messages received logical	1,931,144	408.50	344.97
messages sent directly	25,742	5.45	4.60
messages sent indirectly	137,725	29.13	24.60
messages sent not implicit batched	88,859	18.80	15.87
messages sent pbatched	1,050,224	222.16	187.61
msgs causing lmd to send msgs	61,682	13.05	11.02
msgs causing lms(s) to send msgs	85,978	18.19	15.36
msgs received queue time (ms)	911,013	192.71	162.74
msgs received queued	1,931,121	408.50	344.97
msgs sent queue time (ms)	5,651	1.20	1.01
msgs sent queue time on ksxp (ms)	66,767	14.12	11.93
msgs sent queued	215,124	45.51	38.43
msgs sent queued on ksxp	243,729	51.56	43.54
process batch messages received	120,003	25.38	21.44
process batch messages sent	181,019	38.29	32.34

Global CR Served Stats

Statistic	Total
CR Block Requests	10,422
CURRENT Block Requests	251
Data Block Requests	10,422
Undo Block Requests	2
TX Block Requests	20
Current Results	10,664
Private results	4
Zero Results	5
Disk Read Results	0
Fail Results	0
Fairness Down Converts	1,474
Fairness Clears	0
Free GC Elements	0
Flushes	370
Flushes Queued	0
Flush Queue Full	0
Flush Max Time (us)	0
Light Works	2
Errors	0

Global CURRENT Served Stats

Pins = CURRENT Block Pin Operations
Flushes = Redo Flush before CURRENT Block Served Operations
Writes = CURRENT Block Fusion Write Operations

Statistic	Total	% <1ms	% <10ms	% <100ms	% <1s	% <10s
Pins	17,534	99.96	0.01	0.03	0.00	0.00
Flushes	77	48.05	46.75	5.19	0.00	0.00
Writes	255	5.49	53.73	40.00	0.78	0.00

Global Cache Transfer Stats

Immediate (Immed) - Block Transfer NOT impacted by Remote Processing Delays
Busy (Busy) - Block Transfer impacted by Remote Contention
Congested (Congst) - Block Transfer impacted by Remote System Load
ordered by CR + Current Blocks Received desc

		CR				Current
Inst No	Block Class	Blocks Received	% Immed	% Busy	% Congst	Blocks Received	% Immed	% Busy	% Congst
2	data block	3,945	87.20	12.80	0.00	13,324	99.71	0.26	0.04
2	Others	191	100.00	0.00	0.00	2,190	96.48	3.52	0.00
2	undo header	11	100.00	0.00	0.00	2	100.00	0.00	0.00

End of Report

 OLAP:聯機分析處理

OLTP:聯機事務處理

OLAP是主要應用資料倉儲系統

OLTP是一般的專案開發用到的基本的、日常的事務處理；比如資料庫記錄的增、刪、改、查。

ORACLE AWR報告詳細分析

Report Summary

Cache Sizes

Load Profile

Instance Efficiency Percentages (Target 100%)

Shared Pool Statistics

Top 5 Timed Events

RAC Statistics

Global Cache Load Profile

Global Cache Efficiency Percentages (Target local+remote 100%)

Global Cache and Enqueue Services - Workload Characteristics

Global Cache and Enqueue Services - Messaging Statistics

Main Report

Wait Events Statistics

Time Model Statistics

Wait Class 等待事件的型別

Wait Events 現實非空閒等待事件 後面是空閒等待事件

Background Wait Events

Operating System Statistics

Service Statistics

Service Wait Class Stats

SQL Statistics v$sqlarea

SQL ordered by Elapsed Time

SQL ordered by CPU Time

SQL ordered by Gets

SQL ordered by Reads

SQL ordered by Executions

SQL ordered by Parse Calls

SQL ordered by Sharable Memory

SQL ordered by Version Count

SQL ordered by Cluster Wait Time

Complete List of SQL Text

Instance Activity Statistics

Instance Activity Stats

Instance Activity Stats - Absolute Values

Instance Activity Stats - Thread Activity

IO Stats

Tablespace IO Stats

File IO Stats

Buffer Pool Statistics

Advisory Statistics

Instance Recovery Stats

Buffer Pool Advisory

PGA Aggr Summary

PGA Aggr Target Stats

PGA Aggr Target Histogram

PGA Memory Advisory

Shared Pool Advisory

SGA Target Advisory

Streams Pool Advisory

Java Pool Advisory

Wait Statistics

Buffer Wait Statistics

Enqueue Activity

Undo Statistics

Segment Summary

Undo Segment Stats

Latch Statistics

Latch Activity

Latch Sleep Breakdown

Latch Miss Sources

Parent Latch Statistics

Child Latch Statistics

Segment Statistics

Segments by Logical Reads

Segments by Physical Reads

Segments by Row Lock Waits

Segments by Buffer Busy Waits

Segments by Global Cache Buffer Busy

Segments by CR Blocks Received

Segments by Current Blocks Received

Dictionary Cache Statistics

Dictionary Cache Stats

Dictionary Cache Stats (RAC)

Library Cache Statistics

Library Cache Activity

Library Cache Activity (RAC)

Memory Statistics

Process Memory Summary

SGA Memory Summary

Wait Events 現實非空閒等待事件後面是空閒等待事件