怎么理解ORACLE AWR報告

發布時間：2021-11-11 15:14:58 來源：億速云閱讀：427 作者：iii 欄目：關系型數據庫

這篇文章主要介紹“怎么理解ORACLE AWR報告”，在日常操作中，相信很多人在怎么理解ORACLE AWR報告問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”怎么理解ORACLE AWR報告”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

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的經驗，對于OLTP系統，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
SQL Statistics
Instance Activity Statistics
IO Stats
Buffer Pool Statistics
Advisory Statistics
Wait Statistics
Undo Statistics
Latch Statistics
Segment Statistics
Dictionary Cache Statistics
Library Cache Statistics
Memory Statistics
Streams Statistics
Resource Limit Statistics
init.ora Parameters

Wait Events Statistics

Time Model Statistics
Wait Class
Wait Events
Background Wait Events
Operating System Statistics
Service Statistics
Service Wait Class Stats

Back to Top

/* 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事件。

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

Oracle 9i
SQL> 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：
進程經常性的訪問data 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

Back to Wait Events Statistics
Back to Top

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

Back to Wait Events Statistics
Back to Top

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（空間管理鎖）。

Back to Wait Events Statistics
Back to Top

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

Back to Wait Events Statistics
Back to Top

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）

Back to Wait Events Statistics
Back to Top

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

Back to Wait Events Statistics
Back to Top

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

Back to Wait Events Statistics
Back to Top

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

本節按各種資源分別列出對資源消耗最嚴重的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;

Back to Top

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	d8z0u8hgj8xdy	cuidmain@HPGICCI1 (TNS V1-V3)	insert into CUID select CUID_...
76	75	172,329	0.00	11.52	4vja2k2gdtyup	load_fnsact@HPGICCI1 (TNS V1-V3)	insert into ICCICCS values (:...
58	42	1	58.04	8.75	569r5k05drsj7	cumimain@HPGICCI1 (TNS V1-V3)	insert into CUMI select CUSV_...
51	42	1	50.93	7.68	ackxqhnktxnbc	cusmmain@HPGICCI1 (TNS V1-V3)	insert into CUSM select CUSM_...
38	36	166,069	0.00	5.67	7gtztzv329wg0		select c.name, u.name from co...
35	3	1	35.00	5.28	6z06gcfw39pkd	SQL*Plus	SELECT F.TABLESPACE_NAME, TO_...
23	23	172,329	0.00	3.46	1dm3bq36vu3g8	load_fnsact@HPGICCI1 (TNS V1-V3)	insert into iccifnsact values...
15	11	5	2.98	2.25	djs2w2f17nw2z		DECLARE job BINARY_INTEGER := ...
14	14	172,983	0.00	2.16	7wwv1ybs9zguz	load_fnsact@HPGICCI1 (TNS V1-V3)	update ICCIFNSACT set BORM_AD...
13	13	172,337	0.00	2.00	gmn2w09rdxn14	load_oldnewact@HPGICCI1 (TNS V1-V3)	insert into OLDNEWACT values ...
13	13	166,051	0.00	1.89	chjmy0dxf9mbj	icci_migact@HPGICCI1 (TNS V1-V3)	insert into ICCICCS values (:...
10	4	1	9.70	1.46	0yv9t4qb1zb2b	cuidmain@HPGICCI1 (TNS V1-V3)	select CUID_CUST_NO , CUID_ID_...
10	8	5	1.91	1.44	1crajpb7j5tyz		INSERT INTO STATS$SGA_TARGET_A...
8	8	172,329	0.00	1.25	38apjgr0p55ns	load_fnsact@HPGICCI1 (TNS V1-V3)	update ICCICCS set CCSMAXOVER...
8	8	172,983	0.00	1.16	5c4qu2zmj3gux	load_fnsact@HPGICCI1 (TNS V1-V3)	select * from ICCIPRODCODE wh...

Back to SQL Statistics
Back to Top

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	4vja2k2gdtyup	load_fnsact@HPGICCI1 (TNS V1-V3)	insert into ICCICCS values (:...
57	93	1	57.31	14.10	d8z0u8hgj8xdy	cuidmain@HPGICCI1 (TNS V1-V3)	insert into CUID select CUID_...
42	51	1	42.43	7.68	ackxqhnktxnbc	cusmmain@HPGICCI1 (TNS V1-V3)	insert into CUSM select CUSM_...
42	58	1	42.01	8.75	569r5k05drsj7	cumimain@HPGICCI1 (TNS V1-V3)	insert into CUMI select CUSV_...
36	38	166,069	0.00	5.67	7gtztzv329wg0		select c.name, u.name from co...
23	23	172,329	0.00	3.46	1dm3bq36vu3g8	load_fnsact@HPGICCI1 (TNS V1-V3)	insert into iccifnsact values...
14	14	172,983	0.00	2.16	7wwv1ybs9zguz	load_fnsact@HPGICCI1 (TNS V1-V3)	update ICCIFNSACT set BORM_AD...
13	13	172,337	0.00	2.00	gmn2w09rdxn14	load_oldnewact@HPGICCI1 (TNS V1-V3)	insert into OLDNEWACT values ...
13	13	166,051	0.00	1.89	chjmy0dxf9mbj	icci_migact@HPGICCI1 (TNS V1-V3)	insert into ICCICCS values (:...
11	15	5	2.23	2.25	djs2w2f17nw2z		DECLARE job BINARY_INTEGER := ...
8	8	172,329	0.00	1.25	38apjgr0p55ns	load_fnsact@HPGICCI1 (TNS V1-V3)	update ICCICCS set CCSMAXOVER...
8	10	5	1.60	1.44	1crajpb7j5tyz		INSERT INTO STATS$SGA_TARGET_A...
8	8	172,983	0.00	1.16	5c4qu2zmj3gux	load_fnsact@HPGICCI1 (TNS V1-V3)	select * from ICCIPRODCODE wh...
4	10	1	3.54	1.46	0yv9t4qb1zb2b	cuidmain@HPGICCI1 (TNS V1-V3)	select CUID_CUST_NO , CUID_ID_...
3	35	1	3.13	5.28	6z06gcfw39pkd	SQL*Plus	SELECT F.TABLESPACE_NAME, TO_...

Back to SQL Statistics
Back to Top

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	4vja2k2gdtyup	load_fnsact@HPGICCI1 (TNS V1-V3)	insert into ICCICCS values (:...
2,064,414	1	2,064,414.00	12.40	57.31	93.50	d8z0u8hgj8xdy	cuidmain@HPGICCI1 (TNS V1-V3)	insert into CUID select CUID_...
1,826,869	166,069	11.00	10.97	35.84	37.60	7gtztzv329wg0		select c.name, u.name from co...
1,427,648	172,337	8.28	8.58	12.97	13.29	gmn2w09rdxn14	load_oldnewact@HPGICCI1 (TNS V1-V3)	insert into OLDNEWACT values ...
1,278,667	172,329	7.42	7.68	22.85	22.94	1dm3bq36vu3g8	load_fnsact@HPGICCI1 (TNS V1-V3)	insert into iccifnsact values...
1,216,367	1	1,216,367.00	7.31	42.43	50.93	ackxqhnktxnbc	cusmmain@HPGICCI1 (TNS V1-V3)	insert into CUSM select CUSM_...
1,107,305	1	1,107,305.00	6.65	42.01	58.04	569r5k05drsj7	cumimain@HPGICCI1 (TNS V1-V3)	insert into CUMI select CUSV_...
898,868	172,983	5.20	5.40	14.28	14.34	7wwv1ybs9zguz	load_fnsact@HPGICCI1 (TNS V1-V3)	update ICCIFNSACT set BORM_AD...
711,450	166,051	4.28	4.27	12.52	12.55	chjmy0dxf9mbj	icci_migact@HPGICCI1 (TNS V1-V3)	insert into ICCICCS values (:...
692,996	172,329	4.02	4.16	8.31	8.31	38apjgr0p55ns	load_fnsact@HPGICCI1 (TNS V1-V3)	update ICCICCS set CCSMAXOVER...
666,748	166,052	4.02	4.00	6.36	6.36	7v9dyf5r424yh	icci_migact@HPGICCI1 (TNS V1-V3)	select NEWACTNO into :b0 from...
345,357	172,983	2.00	2.07	7.70	7.71	5c4qu2zmj3gux	load_fnsact@HPGICCI1 (TNS V1-V3)	select * from ICCIPRODCODE wh...
231,756	51,633	4.49	1.39	5.75	5.83	49ms69srnaxzj	load_fnsact@HPGICCI1 (TNS V1-V3)	insert into ICCIRPYV values (...

Back to SQL Statistics
Back to Top

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	d8z0u8hgj8xdy	cuidmain@HPGICCI1 (TNS V1-V3)	insert into CUID select CUID_...
50,646	1	50,646.00	15.70	3.54	9.70	0yv9t4qb1zb2b	cuidmain@HPGICCI1 (TNS V1-V3)	select CUID_CUST_NO , CUID_ID_...
24,507	1	24,507.00	7.59	42.01	58.04	569r5k05drsj7	cumimain@HPGICCI1 (TNS V1-V3)	insert into CUMI select CUSV_...
21,893	1	21,893.00	6.78	42.43	50.93	ackxqhnktxnbc	cusmmain@HPGICCI1 (TNS V1-V3)	insert into CUSM select CUSM_...
19,761	1	19,761.00	6.12	2.14	6.04	a7nh7j8zmfrzw	cumimain@HPGICCI1 (TNS V1-V3)	select CUSV_CUST_NO from CUMI...
19,554	1	19,554.00	6.06	1.27	3.83	38gak8u2qm11w	SQL*Plus	select count(*) from CUSVAA_T...
6,342	1	6,342.00	1.97	3.13	35.00	6z06gcfw39pkd	SQL*Plus	SELECT F.TABLESPACE_NAME, TO_...
4,385	1	4,385.00	1.36	1.59	2.43	cp5duhcsj72q0	cusmmain@HPGICCI1 (TNS V1-V3)	select CUSM_CUST_ACCT_NO from...
63	5	12.60	0.02	11.17	14.91	djs2w2f17nw2z		DECLARE job BINARY_INTEGER := ...
35	1	35.00	0.01	0.08	0.67	1uk5m5qbzj1vt	SQL*Plus	BEGIN dbms_workload_repository...

Back to SQL Statistics
Back to Top

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	5c4qu2zmj3gux	load_fnsact@HPGICCI1 (TNS V1-V3)	select * from ICCIPRODCODE wh...
172,983	172,329	1.00	0.00	0.00	7wwv1ybs9zguz	load_fnsact@HPGICCI1 (TNS V1-V3)	update ICCIFNSACT set BORM_AD...
172,337	172,337	1.00	0.00	0.00	gmn2w09rdxn14	load_oldnewact@HPGICCI1 (TNS V1-V3)	insert into OLDNEWACT values ...
172,329	172,329	1.00	0.00	0.00	1dm3bq36vu3g8	load_fnsact@HPGICCI1 (TNS V1-V3)	insert into iccifnsact values...
172,329	172,329	1.00	0.00	0.00	38apjgr0p55ns	load_fnsact@HPGICCI1 (TNS V1-V3)	update ICCICCS set CCSMAXOVER...
172,329	6,286	0.04	0.00	0.00	4vja2k2gdtyup	load_fnsact@HPGICCI1 (TNS V1-V3)	insert into ICCICCS values (:...
166,069	166,069	1.00	0.00	0.00	7gtztzv329wg0		select c.name, u.name from co...
166,052	166,052	1.00	0.00	0.00	7v9dyf5r424yh	icci_migact@HPGICCI1 (TNS V1-V3)	select NEWACTNO into :b0 from...
166,051	166,051	1.00	0.00	0.00	chjmy0dxf9mbj	icci_migact@HPGICCI1 (TNS V1-V3)	insert into ICCICCS values (:...
51,740	51,740	1.00	0.00	0.00	bu8tnqr3xv25q	load_fnsact@HPGICCI1 (TNS V1-V3)	select count(*) into :b0 fro...
51,633	51,633	1.00	0.00	0.00	49ms69srnaxzj	load_fnsact@HPGICCI1 (TNS V1-V3)	insert into ICCIRPYV values (...

Back to SQL Statistics
Back to Top

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	7gtztzv329wg0		select c.name, u.name from co...
6,304	6,304	3.45	2ym6hhaq30r73		select type#, blocks, extents,...
2,437	2,438	1.33	bsa0wjtftg3uw		select file# from file$ where ...
1,568	1,568	0.86	9qgtwh76xg6nz		update seg$ set type#=:4, bloc...
1,554	1,554	0.85	aq4js2gkfjru8		update tsq$ set blocks=:3, max...
444	444	0.24	104pd9mm3fh9p		select blocks, maxblocks, gran...
421	421	0.23	350f5yrnnmshs		lock table sys.mon_mods$ in ex...
421	421	0.23	g00cj285jmgsw		update sys.mon_mods$ set inser...
86	86	0.05	3m8smr0v7v1m6		INSERT INTO sys.wri$_adv_messa...
81	81	0.04	f80h0xb1qvbsk		SELECT sys.wri$_adv_seq_msggro...

Back to SQL Statistics
Back to Top

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;

Back to SQL Statistics
Back to Top

Running Time top 10 sql

select * from

(select t.sql_fulltext,

(t.last_active_time-to_date(t.first_load_time,'yyyy-mm-dd hh34: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不同，會話優化模式不同、類型不同、長度不同和綁定變量不同等等的語句，他們是不能共享的，所以再緩存中會存在多個不同的版本。這當然就造成了資源上的更多的消耗。

Back to SQL Statistics
Back to Top

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	d8z0u8hgj8xdy	cuidmain@HPGICCI1 (TNS V1-V3)	insert into CUID select CUID_...
4.21	7.25	58.04	42.01	1	569r5k05drsj7	cumimain@HPGICCI1 (TNS V1-V3)	insert into CUMI select CUSV_...
3.62	7.12	50.93	42.43	1	ackxqhnktxnbc	cusmmain@HPGICCI1 (TNS V1-V3)	insert into CUSM select CUSM_...
2.39	6.35	37.60	35.84	166,069	7gtztzv329wg0		select c.name, u.name from co...
2.38	3.12	76.41	74.57	172,329	4vja2k2gdtyup	load_fnsact@HPGICCI1 (TNS V1-V3)	insert into ICCICCS values (:...
1.64	16.91	9.70	3.54	1	0yv9t4qb1zb2b	cuidmain@HPGICCI1 (TNS V1-V3)	select CUID_CUST_NO , CUID_ID_...
1.06	3.02	35.00	3.13	1	6z06gcfw39pkd	SQL*Plus	SELECT F.TABLESPACE_NAME, TO_...
0.83	13.76	6.04	2.14	1	a7nh7j8zmfrzw	cumimain@HPGICCI1 (TNS V1-V3)	select CUSV_CUST_NO from CUMI...
0.66	87.90	0.75	0.42	444	104pd9mm3fh9p		select blocks, maxblocks, gran...
0.50	13.01	3.83	1.27	1	38gak8u2qm11w	SQL*Plus	select count(*) from CUSVAA_T...
0.50	51.75	0.96	0.79	1,554	aq4js2gkfjru8		update tsq$ set blocks=:3, max...
0.33	91.11	0.36	0.33	187	04xtrk7uyhknh		select obj#, type#, ctime, mti...
0.33	2.47	13.29	12.97	172,337	gmn2w09rdxn14	load_oldnewact@HPGICCI1 (TNS V1-V3)	insert into OLDNEWACT values ...
0.29	1.26	22.94	22.85	172,329	1dm3bq36vu3g8	load_fnsact@HPGICCI1 (TNS V1-V3)	insert into iccifnsact values...
0.25	10.14	2.43	1.59	1	cp5duhcsj72q0	cusmmain@HPGICCI1 (TNS V1-V3)	select CUSM_CUST_ACCT_NO from...
0.21	27.92	0.74	0.74	1,568	9qgtwh76xg6nz		update seg$ set type#=:4, bloc...
0.20	3.49	5.83	5.75	51,633	49ms69srnaxzj	load_fnsact@HPGICCI1 (TNS V1-V3)	insert into ICCIRPYV values (...
0.17	1.39	12.55	12.52	166,051	chjmy0dxf9mbj	icci_migact@HPGICCI1 (TNS V1-V3)	insert into ICCICCS values (:...
0.16	57.64	0.28	0.24	39	cn1gtsav2d5jh	cusvaamain@HPGICCI1 (TNS V1-V3)	BEGIN BEGIN IF (xdb.DBMS...
0.14	74.58	0.19	0.14	121	5ngzsfstg8tmy		select o.owner#, o.name, o.nam...
0.11	64.72	0.18	0.15	80	78m9ryygp65v5	cusvaamain@HPGICCI1 (TNS V1-V3)	SELECT /+ ALL_ROWS / COUNT(*...
0.11	94.54	0.12	0.01	17	bwt0pmxhv7qk7		delete from con$ where owner#=...
0.11	80.26	0.14	0.14	327	53saa2zkr6wc3		select intcol#, nvl(pos#, 0), ...
0.08	19.20	0.42	0.24	1	d92h4rjp0y217		begin prvt_hdm.auto_execute( :...
0.07	54.97	0.13	0.13	83	7ng34ruy5awxq		select i.obj#, i.ts#, i.file#,...
0.06	5.22	1.13	0.72	77	0hhmdwwgxbw0r		select obj#, type#, flags, ...
0.06	86.50	0.06	0.06	45	a2any035u1qz1		select owner#, name from con$...
0.06	8.19	0.67	0.08	1	1uk5m5qbzj1vt	SQL*Plus	BEGIN dbms_workload_repository...
0.04	75.69	0.06	0.06	87	6769wyy3yf66f		select pos#, intcol#, col#, sp...
0.04	48.05	0.09	0.07	7	0pvtkmrrq8usg		select file#, block# from seg...
0.04	8.84	0.40	0.40	6,304	2ym6hhaq30r73		select type#, blocks, extents,...
0.03	28.15	0.12	0.12	49	b52m6vduutr8j		delete from RecycleBin$ ...
0.03	66.23	0.05	0.05	85	1gu8t96d0bdmu		select t.ts#, t.file#, t.block...
0.03	67.03	0.05	0.05	38	btzq46kta67dz	DBMS_SCHEDULER	update obj$ set obj#=:6, type#...
0.02	66.73	0.04	0.04	86	3m8smr0v7v1m6		INSERT INTO sys.wri$_adv_messa...
0.02	26.94	0.09	0.09	38	0k8h717b8guhf		delete from RecycleBin$ ...
0.02	76.76	0.03	0.03	51	9vtm7gy4fr2ny		select con# from con$ where ow...
0.02	51.91	0.05	0.05	84	83taa7kaw59c1		select name, intcol#, segcol#,...
0.02	0.15	14.91	11.17	5	djs2w2f17nw2z		DECLARE job BINARY_INTEGER := ...
0.02	2.12	1.00	0.99	8,784	501v412s13r4m	load_fnsact@HPGICCI1 (TNS V1-V3)	update ICCIFNSACT set BORM_FA...
0.02	53.82	0.03	0.03	39	bdv0rkkssq2jm	cusvaamain@HPGICCI1 (TNS V1-V3)	SELECT count(*) FROM user_poli...
0.01	0.10	14.34	14.28	172,983	7wwv1ybs9zguz	load_fnsact@HPGICCI1 (TNS V1-V3)	update ICCIFNSACT set BORM_AD...
0.01	8.29	0.16	0.13	421	g00cj285jmgsw		update sys.mon_mods$ set inser...
0.01	1.65	0.56	0.54	2	84qubbrsr0kfn		insert into wrh$_latch (snap...
0.01	22.33	0.04	0.02	26	44au3v5mzpc1c	load_curmmast@HPGICCI1 (TNS V1-V3)	insert into ICCICURMMAST valu...
0.01	0.08	7.71	7.70	172,983	5c4qu2zmj3gux	load_fnsact@HPGICCI1 (TNS V1-V3)	select * from ICCIPRODCODE wh...

Back to SQL Statistics
Back to Top

對于出現在上面的可疑的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
0k8h717b8guhf	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
9qgtwh76xg6nz	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'

Back to SQL Statistics
Back to Top

Instance Activity Statistics

Instance Activity Stats
Instance Activity Stats - Absolute Values
Instance Activity Stats - Thread Activity

Back to Top

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

Back to Instance Activity Statistics
Back to Top

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

Back to Instance Activity Statistics
Back to Top

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

Back to Instance Activity Statistics
Back to Top

IO Stats

Tablespace IO Stats
File IO Stats

Back to Top

通常，在這里期望在各設備上的讀取和寫入操作是均勻分布的。要找出什么文件可能非常“熱”。一旦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爭用。

Back to IO Stats
Back to Top

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

Back to IO Stats
Back to Top

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統計，其實在前面的等待時間中已經包含，所以可以參考前面的描述。關于命中率也已經在前面討論。所以，其實這段信息不需要怎么關注。
Back to Top

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

Back to Top

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

Back to Advisory Statistics
Back to Top

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

Back to Advisory Statistics
Back to Top

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

Back to Advisory Statistics
Back to Top

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

Back to Advisory Statistics
Back to Top

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

Back to Advisory Statistics
Back to Top

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

Back to Advisory Statistics
Back to Top

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

Back to Advisory Statistics
Back to Top

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

Back to Advisory Statistics
Back to Top

Streams Pool Advisory

No data exists for this section of the report.

Back to Advisory Statistics
Back to Top

Java Pool Advisory

No data exists for this section of the report.

Back to Advisory Statistics
Back to Top

Wait Statistics

Buffer Wait Statistics
Enqueue Activity

Back to Top

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

Back to Wait Statistics
Back to Top

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

Back to Wait Statistics
Back to Top

Undo Statistics

Undo Segment Summary
Undo Segment Stats

Back to Top

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

Back to Undo Statistics
Back to Top

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

Back to Undo Statistics
Back to Top

Latch Statistics

Latch Activity
Latch Sleep Breakdown
Latch Miss Sources
Parent Latch Statistics
Child Latch Statistics

Back to Top

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

Back to Latch Statistics
Back to Top

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

Back to Latch Statistics
Back to Top

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

Back to Latch Statistics
Back to Top

Parent Latch Statistics

No data exists for this section of the report.

Back to Latch Statistics
Back to Top

Child Latch Statistics

No data exists for this section of the report.

Back to Latch Statistics
Back to Top

Segment Statistics

Segments by Logical Reads
Segments by Physical Reads
Segments by Row Lock Waits
Segments by ITL Waits
Segments by Buffer Busy Waits
Segments by Global Cache Buffer Busy
Segments by CR Blocks Received
Segments by Current Blocks Received

Back to Top

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

Back to Segment Statistics
Back to Top

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

Back to Segment Statistics
Back to Top

Segments by Row Lock Waits

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

No data exists for this section of the report.

Back to Segment Statistics
Back to Top

Segments by ITL Waits

No data exists for this section of the report.

Back to Segment Statistics
Back to Top

Segments by Buffer Busy Waits

No data exists for this section of the report.

Back to Segment Statistics
Back to Top

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

Back to Segment Statistics
Back to Top

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

Back to Segment Statistics
Back to Top

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

Back to Segment Statistics
Back to Top

Dictionary Cache Statistics

Dictionary Cache Stats
Dictionary Cache Stats (RAC)

Back to Top

/* 庫緩存詳細信息，。

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

Back to Dictionary Cache Statistics
Back to Top

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

Back to Dictionary Cache Statistics
Back to Top

Library Cache Statistics

Library Cache Activity
Library Cache Activity (RAC)

Back to Top

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

Back to Library Cache Statistics
Back to Top

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

Back to Library Cache Statistics
Back to Top

Memory Statistics

Process Memory Summary
SGA Memory Summary
SGA breakdown difference

Back to Top

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

Back to Memory Statistics
Back to Top

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

Back to Memory Statistics
Back to Top

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

Back to Memory Statistics
Back to Top

Streams Statistics

Streams CPU/IO Usage
Streams Capture
Streams Apply
Buffered Queues
Buffered Subscribers
Rule Set

Back to Top

Streams CPU/IO Usage

No data exists for this section of the report.

Back to Streams Statistics
Back to Top

Streams Capture

No data exists for this section of the report.

Back to Streams Statistics
Back to Top

Streams Apply

No data exists for this section of the report.

Back to Streams Statistics
Back to Top

Buffered Queues

No data exists for this section of the report.

Back to Streams Statistics
Back to Top

Buffered Subscribers

No data exists for this section of the report.

Back to Streams Statistics
Back to Top

Rule Set

No data exists for this section of the report.

Back to Streams Statistics
Back to Top

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

Back to Top

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

Back to Top

More RAC Statistics

Global Enqueue Statistics
Global CR Served Stats
Global CURRENT Served Stats
Global Cache Transfer Stats

Back to Top

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

Back to Top

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

Back to Top

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

Back to Top

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

Back to Top

End of Report

 [FF1]OLAP:聯機分析處理

OLTP:聯機事務處理

OLAP是主要應用數據倉庫系統

OLTP是一般的項目開發用到的基本的、日常的事務處理；比如數據庫記錄的增、刪、改、查。

到此，關于“怎么理解ORACLE AWR報告”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！

向AI問一下細節

亚洲激情专区-91九色丨porny丨老师-久久久久久久女国产乱让韩-国产精品午夜小视频观看

怎么理解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

Wait Events 現實非空閑等待事件后面是空閑等待事件