statspack中報告中的等待事件

eric0435發表於2012-05-30
原文網址 : http://blog.itpub.net/26015009/viewspace-731424/
事件
什麼是等待事件
Oracle的等待事件是衡量Oracle執行狀況的重要依據及指標。
等待事件的概念是在Oracle7.0.1.2中引入的，大致有100個等待事件。在Oracle 8.0中這個數目增加到了大約
150個，在Oracle8i中大約有200個事件,在Oracle9i中大約有360個等待事件。
主要有兩種類別的等待事件，即空閒（idle）等待事件和非空閒（non-idle）等待事件。
空閒事件指Oracle正等待某種工作,在診斷和最佳化資料庫的時候,我們不用過多注意這部分事件。
常見的空閒事件有:
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
非空閒等待事件專門針對Oracle的活動,指資料庫任務或應用執行過程中發生的等待，這些等待事件是我們
在調整資料庫的時候應該關注與研究的。
一些常見的非空閒等待事件有:
db file scattered read
db file sequential read
buffer busy waits
free buffer waits
enqueue
latch free
log file parallel write
log file sync

1. db file scattered read-DB 檔案分散讀取
這種情況通常顯示與全表掃描相關的等待。
當資料庫進行全表掃時，基於效能的考慮，資料會分散(scattered)讀入Buffer Cache。如果這個等
待事件比較顯著，可能說明對於某些全表掃描的表，沒有建立索引或者沒有建立合適的索引，我們可
能需要檢查這些資料表已確定是否進行了正確的設定。
然而這個等待事件不一定意味著效能低下，在某些條件下 Oracle 會主動使用全表掃描來替換索
引掃描以提高效能，這和訪問的資料量有關，在CBO 下Oracle 會進行更為智慧的選擇，在RBO 下
Oracle 更傾向於使用索引。
因為全表掃描被置於 LRU（Least Recently Used，最近最少適用）列表的冷端（cold end），對於
頻繁訪問的較小的資料表，可以選擇把他們Cache 到記憶體中，以避免反覆讀取。
當這個等待事件比較顯著時，可以結合 v$session_longops 動態效能檢視來進行診斷，該檢視中
記錄了長時間（執行時間超過6 秒的）執行的事物，可能很多是全表掃描操作（不管怎樣，這部分信
息都是值得我們注意的）。
我們透過透過一個案例分析來熟悉一下這個等待事件:
DB Name      DB Id     Instance    Inst Num Release   OPS Host
---------- ----------- ---------- -------- ---------- ---- ----------
K2         1999167370   k2          1       8.1.5.0.0   NO  k2
這是一個8.1.5 的資料庫系統，透過指令碼增強，我們可以在8.1.5 的資料庫上使用statspack 來進行數
據庫診斷。
Snap Length
Start Id End Id Start Time End Time (Minutes)
-------- -------- -------------------- -------------------- -----------
170 176 25-Feb-03 10:00:11 25-Feb-03 15:00:05 299.90
Cache Sizes
~~~~~~~~~~~
db_block_buffers: 64000
db_block_size: 8192
log_buffer: 8388608
shared_pool_size: 157286400
………………
Top 5 Wait Events
~~~~~~~~~~~~~~~~~ Wait % Total
Event Waits Time (cs) Wt Time
-------------------------------------------- ------------ ----------------------- -------
db file scattered read 16,842,920 3,490,719 43.32
latch free 844,272 3,270,073 40.58
buffer busy waits 114,421 933,136 11.58
db file sequential read 2,067,910 117,750 1.46
enqueue 464 110,840 1.38
-------------------------------------------------------------
這是一個典型的效能低下的系統，幾個重要的等待事件都在Top 5 中出現，其中，前3 個等待極為顯
著，需要進行相應的調整。
在 5 小時的取樣間隔內，其中db file scattered read 累計等待時間約10 小時，已經成為影響系統效能
的主要原因。瞭解了這些以後我們就可以進一步察看相關SQL 看是否存在可以的SQL 語句。
SQL ordered by Gets for DB: K2 Instance: k2 Snaps: 170 - 176
Gets % of
Buffer Gets Executes per Exec Total Hash Value
-------------- ------------ ------------ ------ ------------
SQL statement
------------------------------------------------------------------------------
6,480,163 12 540,013.6 2.4 3791855498
SELECT "PROCESS_REQ"."WORK_ID", "PROCESS_REQ"."STOCK_NO", "PROCESS_R
3,784,566 16 236,535.4 1.4 2932917818
SELECT * FROM FIND_LATER_WO ORDER BY NOTE,ORDER_NO
1,200,976 3 400,325.3 .4 4122791109
SELECT "ITEM_STOCK"."ITEM_NO", "ITEM"."NOTE", "ITEM"
923,944 9 102,660.4 .3 2200071737
SELECT "ITEM_STOCK"."ITEM_NO" , "ITEM_STOCK"."STOCK_NO" ,
921,301 3 307,100.3 .3 2218843294
SELECT "ITEM_STOCK"."ITEM_NO", "ITEM"."NOTE", "ITEM"
911,285 3 303,761.7 .3 1769130587
SELECT "LISTS"."ITEM_NO" , "LISTS"."SUB_ITEM" , "LISTS"
831,439 2 415,719.5 .3 1349577999
SELECT "GROUP_OPER"."ITEM_NO" , "GROUP_OPER"."PROCESS_ID" ,
802,918 1 802,918.0 .3 3613809507
SELECT "LISTS"."ITEM_NO" , "LISTS"."SUB_ITEM" , "ITEM".
800,548 2 400,274.0 .3 2643788247
SELECT "ITEM_STOCK"."ITEM_NO", "ITEM"."NOTE", "ITEM"
666,085 2 333,042.5 .2 3391363608
SELECT "ITEM_STOCK"."ITEM_NO", "ITEM_STOCK"."STOCK_NO",
………..
注意到以上很多查詢導致的Buffer Gets 都非常龐大，我們非常有理由懷疑索引存在問題，甚至缺少必
要的索引。以上記錄的是SQL 的片段，透過Hash Value 值結合v$sql_text 我們可以獲得完整的SQL
語句。
在這次診斷中，我緊接著去查詢的是 v$session_longops 資料表，一個分組查詢的結果如下:
TARGET COUNT(*)
---------------------------------------------------------------- ----------
SA.PPBT_GRAPHOBJTABLE 418
SA.PPBT_PPBTOBJRELATTABLE 53
我們發現這些問題SQL 的全表掃描(結合v$session_longops 檢視中的OPNAME)主要集中在
PPBT_GRAPHOBJTABLE 和PPBT_PPBTOBJRELATTABLE 兩張資料表上。
進一步研究發現這兩個資料表上沒有任何索引，並且有相當的資料量:
SQL> select count(*) from SA.PPBT_PPBTOBJRELATTABLE;
COUNT(*)
----------
1209017
SQL> select count(*) from SA.PPBT_GRAPHOBJTABLE;
COUNT(*)
----------
2445
在建立了合適的索引後，系統效能得到了大幅提高!

2. db file sequential read-DB 檔案順序讀取。
這一事件通常顯示與單個資料塊相關的讀取操作(如索引讀取)。
如果這個等待事件比較顯著，可能表示在多表連線中，表的連線順序存在問題，可能沒有正確
的使用驅動表；或者可能說明不加選擇地進行索引。
在大多數情況下我們說，透過索引可以更為快速的獲取記錄，所以對於一個編碼規範、調整良
好的資料庫，這個等待很大是很正常的。
但是在很多情況下，使用索引並不是最佳的選擇，比如讀取較大表中大量的資料，全表掃描可
能會明顯快於索引掃描，所以在開發中我們就應該注意，對於這樣的查詢應該進行避免使用索引掃描。

3. Free Buffer-釋放緩衝區
這個等待事件表明系統正在等待記憶體中的可用空間，這說明當前 Buffer 中已經沒有Free 的記憶體
空間。
如果應用設計良好，SQL 書寫規範，充分繫結變數，那這種等待可能說明Buffer Cache 設定的
偏小，你可能需要增大DB_BUFFER_CACHE。
Free Buffer 等待可能說明DBWR 的寫出速度不夠，或者磁碟存在嚴重的競爭，可以需要考慮增
加檢查點、使用更多的DBWR 程式，或者增加物理磁碟的數量,分散負載，平衡IO。
4. Buffer Busy-緩衝區忙
該等待事件表示正在等待一個以unshareable方式使用的緩衝區，或者表示當前正在被讀入buffer
cache。一般來說Buffer Busy Wait不應大於1%。
檢查緩衝等待統計部分（或V$WAITSTAT），看一下等待是否位於段頭(Segment Header)。如
果是，可以考慮增加自由列表（freelist，對於Oracle8i DMT）或者增加freelist groups（在很多時候這
個調整是立竿見影的，在8.1.6之前，這個freelists引數不能動態修改；在8.1.6及以後版本，動態修改
feelists需要設定COMPATIBLE至少為8.1.6）.
其修改語法為：
SQL> alter table sp_item storage (freelists 2);
表已更改。
如果這一等待位於undo header，可以透過增加回滾段（rollback segment）來解決緩衝區的問題。
如果等待位於undo block上，我們可能需要檢查相關應用，適當減少大規模的一致性讀取，或者
降低一致性讀取(consistent read)的表中的資料密度或者增大DB_CACHE_SIZE。
如果等待處於data block，可以考慮將頻繁併發訪問的表或資料移到另一資料塊或者進行更大範
圍的分佈（可以增加pctfree值 ，擴大資料分佈，減少競爭），以避開這個"熱點"資料塊，或者可以考
慮增加表中的自由列表或使用本地化管理的表空間（Locally Managed Tablespaces）。
如果等待處於索引塊，應該考慮重建索引、分割索引或使用反向鍵索引。
為了防止與資料塊相關的緩衝忙等待，也可以使用較小的塊：在這種情況下，單個塊中的記錄
就較少，所以這個塊就不是那麼"繁忙"；或者可以設定更大的pctfree,使資料擴大物理分佈，減少記錄
間的熱點競爭。

在執行DML (insert/update/ delete)時，Oracle向資料塊中寫入資訊，對於多事務併發訪問的資料表，
關於ITL的競爭和等待可能出現，為了減少這個等待，可以增加initrans，使用多個ITL槽。
以下是一個生產系統v$waitstat試圖所顯示的等待資訊:
SQL> select * from v$waitstat where count<>0 or time <>0;
CLASS COUNT TIME
--------- --------------------------------
data block 453 6686
undo header 391 1126
undo block 172 3
在Oracle9i 中，引入了一個新概念:ASSM（Segment Space Management Auto）。透過這個新特性
Oracle 使用點陣圖來管理空間使用。
ASSM 結合LMT 徹底改變了Oracle 的儲存機制，點陣圖freelist 能夠減輕緩衝區忙等待（buffer busy
wait），這個問題在Oracle9i 以前的版本里曾是一個嚴重的問題。
Oracle 宣稱ASSM 顯著地提高了DML 併發操作的效能，因為（同一個）點陣圖的不同部分可以被
同時使用，這樣就消除了尋找剩餘空間的序列化。根據Oracle 的測試結果，使用點陣圖freelist 會消除
所有分段頭部（對資源）的爭奪，還能獲得超快的併發插入操作
在 Oracle9i 之中，Buffer Busy wait 不再常見！

5. latch free-latch 釋放
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公告。
以下我們簡單來看一下對栓的查詢及跟蹤:
SQL> select addr,name
2 from v$latch_children
3 where name like '%chain%'
4 /
ADDR NAME
---------------- ------------------------------
00000003C0558AE8 enqueue hash chains
00000003C0558A58 enqueue hash chains
00000003C05589C8 enqueue hash chains
00000003C0558938 enqueue hash chains
00000003C05588A8 enqueue hash chains
00000003C0558818 enqueue hash chains
00000003C0558788 enqueue hash chains
00000003C05586F8 enqueue hash chains
00000003C1FC7830 cache buffers lru chain
00000003C1FC7448 cache buffers lru chain
00000003C1FC7060 cache buffers lru chain
ADDR NAME
---------------- ------------------------------
00000003C1FC6C78 cache buffers lru chain
00000003C247D970 cache buffers chains
00000003C247C8C0 cache buffers chains
00000003C247B810 cache buffers chains
00000003C247A760 cache buffers chains
00000003C24796B0 cache buffers chains
00000003C2478600 cache buffers chains
00000003C2477550 cache buffers chains
00000003C24764A0 cache buffers chains
00000003C24753F0 cache buffers chains

00000003C2474340 cache buffers chains
……….
SQL> col segment_name for a40
SQL> set linesize 120
SQL> l
1 select /*+ ordered */
2 e.owner ||'.'|| e.segment_name segment_name,
3 e.extent_id extent#,
4 x.dbablk - e.block_id + 1 block#,
5 x.tch,
6 l.child#
7 from
8 sys.v$latch_children l,
9 sys.x$bh x,
10 sys.dba_extents e
11 where
12 l.name = 'cache buffers chains' and
13 l.sleeps > &sleep_count and
14 x.hladdr = l.addr and
15 e.file_id = x.file# and
16* x.dbablk between e.block_id and e.block_id + e.blocks - 1
SQL> /
Enter value for sleep_count: 10000
old 13: l.sleeps > &sleep_count and
new 13: l.sleeps > 10000 and
SEGMENT_NAME EXTENT# BLOCK# TCH CHILD#
---------------------------------------- ---------- ---------- ---------- ----------
SYS.I_ACCESS1 14 16 12 1001
SYS.I_DEPENDENCY2 2 11 25 804
SYS.I_DEPENDENCY2 2 13 23 806
SYS.I_DEPENDENCY1 2 10 1 1019
SYS.I_DEPENDENCY1 2 11 2 1020
………..
HSCONTENT.HSIDX_INFO_PARAM 50 2 35635 1017
HSCONTENT.HSIDX_INFO_PARAM 50 3 51269 1018
HSCONTENT.HSIDX_INFO_PARAM 50 4 32415 1019
HSCONTENT.HSIDX_INFO_PARAM 50 5 51956 1020
HSCONTENT.HSIDX_INFO_PARAM 50 6 57509 1021
HSCONTENT.PK_HS_DLF_OBJECT 11 2 4434 809
HSCONTENT.PK_HS_DLF_OBJECT 11 6 5738 813
HSCONTENT.PK_HS_DLF_OBJECT 14 2 524 1001
HSCONTENT.PK_HS_DLF_OBJECT 23 2 4843 1001
HSCONTENT.PK_HS_DLF_OBJECT 24 2 4361 1001
HSCONTENT.PK_HS_DLF_OBJECT 25 13 2507 804

6. Enqueue。
enqueue是一種保護共享資源的鎖定機制。該鎖定機制保護共享資源，如記錄中的資料，以避免
兩個人在同一時間更新同一資料。enqueue包括一個排隊機制，即FIFO（先進先出）排隊機制。
Enqueue等待常見的有ST、HW 、TX 、TM等
ST enqueue，用於空間管理和字典管理的表空間(DMT)的區間分配，在DMT中典型的是對於uet$
和fet$資料字典表的爭用。對於支援LMT的版本，應該儘量使用本地管理表空間. 或者考慮手工預分
配一定數量的區(Extent)，減少動態擴充套件時發生的嚴重佇列競爭。
我們透過一個例項來看一下:
DB Name DB Id Instance Inst Num Release OPS Host
------------ ----------- ------------ -------- ----------- --- ------------------
DB 40757346 aaa 1 8.1.7.4.0 NO server
Snap Id Snap Time Sessions
------- ------------------ --------
Begin Snap: 2845 31-10月-03 02:10:16 46
End Snap: 2848 31-10月-03 03:40:05 46
Elapsed: 89.82 (mins)
對於一個Statspack的report,取樣時間是非常重要的維度，離開時間做參考，任何等待都不足以說明問題。
Cache Sizes
~~~~~~~~~~~
db_block_buffers: 51200 log_buffer: 2097152
db_block_size: 16384 shared_pool_size: 209715200
………..
Top 5 Wait Events
~~~~~~~~~~~~~~~~~ Wait % Total
Event Waits Time (cs) Wt Time
-------------------------------------------- ------------ ------------ -------
enqueue 53,793 16,192,686 67.86
rdbms ipc message 19,999 5,927,350 24.84
pmon timer 1,754 538,797 2.26
smon timer 17 522,281 2.19
SQL*Net message from client 94,525 520,104 2.18
-------------------------------------------------------------
在Statspack分析中，Top 5等待事件是我們最為關注的部分。
這個系統中，除了enqueue 等待事件以外，其他4個都屬於空閒等待事件，無須關注。我們來關注一下enqueue
等待事件，在89.82 (mins)的取樣間隔內，累計enqueue等待長達16,192,686cs,即45小時左右。這個等待已經
太過顯著，實際上這個系統也正因此遭遇了巨大的困難，觀察到佇列等待以後，我們就應該關注佇列等待
在等待什麼資源。快速跳轉的Statspack的其他部分，我們看到以下詳細內容:
Enqueue activity for DB: DB Instance: aaa Snaps: 2716 -2718
-> ordered by waits desc, gets desc
Enqueue Gets Waits
---------- ------------ ----------
ST 1,554 1,554
-------------------------------------------------------------
我們看到主要佇列等待在等待ST鎖定，對於DMT，我們說這個等待跟FET$,UET$的爭用緊密相關。我們在回
過頭來研究捕獲的SQL語句:
-> End Buffer Gets Threshold: 10000
-> Note that resources reported for PL/SQL includes the resources used by
all SQL statements called within the PL/SQL code. As individual SQL
statements are also reported, it is possible and valid for the summed
total % to exceed 100
Buffer Gets Executions Gets per Exec % Total Hash Value
--------------- ------------ -------------- ------- ------------
4,800,073 10,268 467.5 51.0 2913840444
select length from fet$ where file#=:1 and block#=:2 and ts#=:3
803,187 10,223 78.6 8.5 528349613
delete from uet$ where ts#=:1 and segfile#=:2 and segblock#=:3 a
nd ext#=:4
454,444 10,300 44.1 4.8 1839874543
select file#,block#,length from uet$ where ts#=:1 and segfile#=:
2 and segblock#=:3 and ext#=:4
23,110 10,230 2.3 0.2 3230982141
insert into fet$ (file#,block#,ts#,length) values (:1,:2,:3,:4)
21,201 347 61.1 0.2 1705880752
select file# from file$ where ts#=:1
….
9,505 12 792.1 0.1 1714733582
select f.file#, f.block#, f.ts#, f.length from fet$ f, ts$ t whe
re t.ts#=f.ts# and t.dflextpct!=0 and t.bitmapped=0
6,426 235 27.3 0.1 1877781575
delete from fet$ where file#=:1 and block#=:2 and ts#=:3

我們看到資料庫頻繁操作UET$,FET$系統表已經成為了系統的主要瓶頸。
至此，我們已經可以準確的為該系統定位問題，相應的解決方案也很容易確定，在8.1.7中，使用LMT代替
DMT，這是解決問題的根本辦法，當然實施起來還要進行綜合考慮，實際情況還要複雜得多。
HW enqueue指和段的高水位標記相關等待；手動分配適當區可以避免這一等待。
TX是最常見的enqueue等待。TX enqueue等待通常是以下三個問題之一產生的結果。
第一個問題是唯一索引中的重複索引，你需要執行提交（commit）/回滾（rollback）操作來釋放
enqueue。
第二個問題是對同一點陣圖索引段的多次更新。因為單個點陣圖段可能包含多個行地址（rowid），
所以當多個使用者試圖更新同一段時，可能一個使用者會鎖定其他使用者請求的記錄，這時等待出現。直到
獲得鎖定的使用者提交或回滾， enqueue釋放。
第三個問題，也是最可能發生的問題是多個使用者同時更新同一個塊。如果沒有足夠的ITL槽，就
會發生塊級鎖定。透過增大initrans和/或maxtrans以允許使用多個ITL槽（對於頻繁併發進行DML操作的
資料表，在建表之初就應該考慮為相應引數設定合理的數值，避免系統執行以後線上的更改，在8i之
前，freelists等引數不能線上更改，設計時的考慮就尤為重要），或者增大表上的pctfree值，就可以
很容易的避免這種情況。
TM enqueue佇列鎖在進行DML操作前獲得，以阻止對正在操作的資料表進行任何DDL操作(在DML
操作一個資料表時，其結構不能被更改)。

7. Log Buffer Space-日誌緩衝空間
當你將日誌緩衝（log buffer）產生重做日誌的速度比LGWR 的寫出速度快，或者是當日志切換
（log switch）太慢時，就會發生這種等待。
這個等待出現時，通常表明 redo log buffer 過小，為解決這個問題，可以考慮增大日誌檔案的大
小，或者增加日誌緩衝器的大小。
另外一個可能的原因是磁碟 I/O 存在瓶頸，可以考慮使用寫入速度更快的磁碟。在允許的條件下
設定可以考慮使用裸裝置來存放日誌檔案，提高寫入效率。在一般的系統中，最低的標準是，不要把
日誌檔案和資料檔案存放在一起，因為通常日誌檔案只寫不讀，分離存放可以獲得效能提升。
以下是一個 log buffer 存在問題的statspack Top5 等待事件的系統:
Top 5 Wait Events
~~~~~~~~~~~~~~~                                           Wait %      Total
Event                                        Waits        Time (cs)   Wt Time
-------------------------------------------- ------------ ------------ -------
log file parallel write                         1,436,993    1,102,188   10.80
log buffer space                                   16,698      873,203    8.56
log file sync                                   1,413,374      654,587    6.42
control file parallel write                       329,777      510,078    5.00
db file scattered read                            425,578      132,537    1.30

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

9. log file sync-日誌檔案同步
當一個使用者提交或回滾資料時，LGWR 將會話期的重做由日誌緩衝器寫入到重做日誌中。日誌
檔案同步過程必須等待這一過程成功完成。
為了減少這種等待事件，可以嘗試一次提交更多的記錄（頻繁的提交會帶來更多的系統開銷）。
將重做日誌置於較快的磁碟上，或者交替使用不同物理磁碟上的重做日誌，以降低歸檔對LGWR
的影響。
對於軟 RAID，一般來說不要使用RAID 5，RAID5 對於頻繁寫入得系統會帶來較大的效能損失，
可以考慮使用檔案系統直接輸入/輸出，或者使用裸裝置（raw device），這樣可以獲得寫入的效能提高。
10. log file single write
該事件僅與寫日誌檔案頭塊相關，通常發生在增加新的組成員和增進序列號時。頭塊寫單個進
行，因為頭塊的部分資訊是檔案號，每個檔案不同。更新日誌檔案頭這個操作在後臺完成，一般很少
出現等待，無需太多關注。
11. 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 的寫入成本。通常稱為同步成本率。

12. control file parallel write-控制檔案並行寫
當 server 程式更新所有控制檔案時，這個事件可能出現。
如果等待很短，可以不用考慮。如果等待時間較長，檢查存放控制檔案的物理磁碟I/O 是否存在
瓶頸。
多個控制檔案是完全相同的複製，用於映象以提高安全性。對於業務系統，多個控制檔案應該
存放在不同的磁碟上，一般來說三個是足夠的，如果只有兩個物理硬碟，那麼兩個控制檔案也
是可以接受的。在同一個磁碟上儲存多個控制檔案是不具備實際意義的。
減少這個等待，可以考慮如下方法：
減少控制檔案的個數(在確保安全的前提下)
如果系統支援，使用非同步IO
轉移控制檔案到IO 負擔輕的物理磁碟
13. control file sequential read/ control file single write 控制檔案連續讀/控制檔案單個
寫
對單個控制檔案 I/O 存在問題時，這兩個事件會出現。
如果等待比較明顯，檢查單個控制檔案，看存放位置是否存在 I/O 瓶頸。
使用查詢獲得控制檔案訪問狀態：
select P1 from V$SESSION_WAIT
where EVENT like 'control file%' and STATE='WAITING';

解決辦法：
移動有問題的控制檔案到快速磁碟
如果系統支援，啟用非同步I/O
14. direct path write-直接路徑寫
該等待發生在，系統等待確認所有未完成的非同步 I/O 都已寫入磁碟。
對於這一寫入等待，我們應該找到 I/O 操作最為頻繁的資料檔案(如果有過多的排序操作，很有
可能就是臨時檔案)，分散負載，加快其寫入操作。
如果系統存在過多的磁碟排序，會導致臨時表空間操作頻繁，對於這種情況，可以考慮使用Local
管理表空間，分成多個小檔案，寫入不同磁碟或者裸裝置。
我們可以看一個 report 的典型例子:
DB Name DB Id Instance Inst Num Release OPS Host
---------- ----------- ---------- -------- ---------- ---- ----------
DB 294605295 db 1 8.1.5.0.0 NO IBM
Snap Length
Start Id End Id Start Time End Time (Minutes)
-------- -------- -------------------- -------------------- -----------
65 66 08-11 月-03 16:32:42 08-11 月-03 16:54:00 21.30
這是一個 20 分鐘的取樣報告
Top 5 Wait Events
~~~~~~~~~~~~~~~~~ Wait % Total
Event Waits Time (cs) Wt Time
-------------------------------------------- ------------ ------------ -------
direct path write 98,631 3,651 44.44
log file switch completion 62 2,983 36.31
direct path read 37,434 1,413 17.20
db file sequential read 86 109 1.33
control file sequential read 3,862 34 .41
-------------------------------------------------------------
我們注意到在 Top 5 等待事件中，最為顯著的等待事件就是direct path write。
基於此，我們繼續向下追查相關排序部分統計資料:
Instance Activity Stats for DB: DB Instance: db Snaps: 65 -
Statistic Total per Second per Trans
--------------------------------- ---------------- ------------ ------------

sorts (disk) 64 0.1 0.4
sorts (memory) 861 0.7 4.7
sorts (rows) 2,804,580 2,194.5 15,159.9
64 次的sort disk,相當顯著的磁碟排序，對於這種情況，我們可以很容易的猜測到，臨時表空間的讀寫
操作肯定相當頻繁:
File IO Statistics for DB: GHCXSDB Instance: ghcxsdb Snaps: 65 - 66
Tablespace Filename
------------------------ ----------------------------------------------------
Reads Avg Blks Rd Avg Rd (ms) Writes Tot Waits Avg Wait (ms)
-------------- ----------- ----------- -------------- ---------- -------------
………..
PERFSTAT D:\ORACLE\ORADATA\PERFSTAT.DBF
88 1.0 12.5 821 0
RBS D:\ORACLE\ORADATA\GHCXSDB\RBS01.DBF
7 1.0 0.0 1,399 0
SYSTEM D:\ORACLE\ORADATA\GHCXSDB\SYSTEM01.DBF
17 1.0 11.8 50 0
TEMP D:\ORACLE\ORADATA\GHCXSDB\TEMP01.DBF
223,152 1.5 0.2 371,303 0
對於這種情況，我們建議，可以適當增加sort_area_size 的大小，以縮減磁碟排序對於硬碟的寫入，從
而提高系統及應用相應。有一個測試數字可以參考:磁碟排序的時間大約是記憶體排序的14000 倍

15. slave wait-從屬程式等
Slave Wait 是Slave I/O 程式等待請求，是一個空閒引數，一般不說明問題。
16. Idle Event-空閒事件
最後我們來看幾個空閒等待事件。
一般來說，空閒等待是指系統因為無事可做的等待，或者等待使用者的請求或響應等，通常我們
可以忽略這些等待事件。
空閒事件可以透過 stats$idle_event 表查詢得到。
我們看一下系統的主要空閒等待事件，對這些事件大家應該有個大致的印象，如果你的Top 5 等
待事件中，主要都是這些事件，那麼一般來說你的系統是比價清閒的:

SQL> select * from stats$idle_event;
EVENT
----------------------------------------------------------------
smon timer
pmon timer
rdbms ipc message
Null event
parallel query dequeue
pipe get
client message
SQL*Net message to client
SQL*Net message from client
SQL*Net more data from client
dispatcher timer
virtual circuit status
lock manager wait for remote message
PX Idle Wait
wakeup time manager
15 rows selected.

 

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/26015009/viewspace-731424/，如需轉載，請註明出處，否則將追究法律責任。

相關文章