常見等待事件的分析解決方法

v$session_wait:當前的等待事件/與等待事件相對應的資源的相關資訊，從而確定出產生瓶頸的型別及其物件。

v$session_wait的p1、p2、p3告訴我們等待事件的具體含義，根據事件不同其內容也不相同，下面就一些常見的等待事件如何處理以及如何定位熱點物件和阻塞會話作一些介紹.

<1> db file scattered read DB
檔案分散讀取:通常顯示與全表掃描相關的等待。如果這個數目很大，就表明該表找不到
索引，或者只能找到有限的索引。儘管在特定條件下執行全表掃描可能比索引掃描更有效，
但如果出現這種等待時，最好檢查一下這些全表掃描是否必要。因為全表掃描被置於LRU
(Least Recently Used，最近最少適用)列表的冷端（cold end），所以應儘量儲存較小
的表，以避免一次又一次地重複讀取它們。

該類事件的p1text=file#,p1是file_id，p2是block_id,透過dba_extents即可確定出熱點
物件(表或索引)

select owner,segment_name,segment_type
from dba_extents
where file_id = &file_id
and &block_id between block_id and block_id + &blocks - 1;

<2> db file sequential read DB 檔案順序讀取
這一事件通常顯示單個塊的讀取(如索引讀取)。這種等待的數目很多時，可能顯示錶的連
接順序不佳，或者不加選擇地進行索引。對於大量事務處理、調整良好的系統，這一數值
大多是很正常的，但在某些情況下，它可能暗示著系統中存在問題。你應當將這一等待統
計量與Statspack 報告中的已知問題（如效率較低的）聯絡起來。檢查索引掃描，以保
證每個掃描都是必要的，並檢查多表連線的連線順序。DB_CACHE_SIZE 也是這些等待出現
頻率的決定因素。有問題的雜湊區域（Hash-area）連線應當出現在PGA 記憶體中，但它們也
會消耗大量記憶體，從而在順序讀取時導致大量等待。它們也可能以直接路徑讀／寫等待的
形式出現。

該類事件的p1text=file#,p1是file_id，p2是block_id,透過dba_extents即可確定出熱點
物件(表或索引)

select owner,segment_name,segment_type
from dba_extents
where file_id = &file_id
and &block_id between block_id and block_id + &blocks - 1;

<3> free buffer waits 釋放緩衝區等待

這種等待表明系統正在等待記憶體中的緩衝，因為記憶體中已經沒有可用的緩衝空間了。如果
所有SQL 都得到了調優，這種等待可能表示你需要增大DB_BUFFER_CACHE。釋放緩衝區等待
也可能表示不加選擇的SQL 導致資料溢位了帶有索引塊的緩衝儲存器，沒有為等待系統處
理的特定語句留有緩衝區。這種情況通常表示正在執行相當多數量的DML（插入／更新／刪
除），並且書寫器(DBWR)寫的速度不夠快，緩衝儲存器可能充滿了相同緩衝器的多
個版本，從而導致效率非常低。為了解決這個問題，可能需要考慮增加檢查點、利用更多
的DBWR 程式，或者增加物理磁碟的數量。

<4> buffer busy waits 緩衝區忙等待

這是為了等待一個以非共享方式使用的緩衝區，或者正在被讀入緩衝儲存器的緩衝區。緩
衝區忙等待不應大於百分之一。檢查緩衝等待統計部分（或V$WAITSTAT）:

A、如果等待處於欄位頭部，應增加自由列表（freelist）的組數，或者增加pctused到
pctfree之間的距離。
B、如果等待處於回退段（undo）頭部塊，可以透過增加回滾段(rollback segment)來解決
緩衝區的問題；
C、如果等待處於回退段（undo）非頭部塊上，就需要降低驅動一致讀取的表中的資料密
度,或者增大DB_CACHE_SIZE；
D、如果等待處於資料塊，可以將資料移到另一資料塊以避開這個"熱"資料塊、增加表中的
自由列表或使用LMT表空間；
E、如果等待處於索引塊，應該重建索引、分割索引或使用反向鍵索引。

為了防止與資料塊相關的緩衝忙等待，也可以使用較小的塊：在這種情況下，單個塊中的
記錄就較少，所以這個塊就不是那麼"繁忙"。在執行DML(插入/更新/刪除)時,Oracle
DBWR就向塊中寫入資訊，包括所有對塊狀態"感興趣"的使用者(感興趣的事務表，ITL)。為
了減少這一區域的等待，可以增加initrans，這樣會在塊中建立空間，從而使你能夠使用
多個ITL槽。你也可以增加該塊所在表中的pctfree(當根據指定的initrans 建立的槽數量
不足時，這樣可以使ITL 資訊數量達到maxtrans 指定的數量）。

<5> latch free

latch是一種低階排隊機制(它們被準確地稱為相互排斥機制),用於保護系統全域性區域(SGA)
中共享記憶體結構。latch 就像是一種快速地被獲取和釋放的記憶體鎖。latch 用於防止共享
記憶體結構被多個使用者同時訪問。如果latch 不可用，就會記錄latch 釋放失敗。大多數
latch 問題都與以下操作相關：不能使用邦定變數（庫快取latch）、重複生成問題（重
復分配latch）、緩衝儲存器競爭問題（緩衝器儲存LRU 鏈），以及緩衝儲存器中的"熱"塊
（緩衝儲存器鏈）。也有一些latch 等待與bug（程式錯誤）有關，如果懷疑是這種情況，
可以檢查MetaLink 上的bug 報告。

該事件的熱點物件可透過以下語句查詢，其中00000400837D7800值是v$session_wait中的
P1RAW

x$bh中的欄位Hladdr表示該block buffer在哪個cache buffer chain latch 上，可以透過
v$latch_children定位哪些segment是熱點塊。

select a.hladdr, a.file#, a.dbablk, a.tch, a.obj, b.object_name
from x$bh a, dba_objects b
where (a.obj = b.object_id or a.obj = b.data_object_id)
and a.hladdr = '00000400837D7800'
union
select hladdr, file#, dbablk, tch, obj, null
from x$bh
where obj in
(select obj from x$bh
where hladdr = '00000400837D7800'
minus
select object_id from dba_objects
minus
select data_object_id from dba_objects)
and hladdr = '00000400837D7800'
order by 4;

<6> enqueue

enqueue 是一種保護共享資源的鎖定機制。該鎖定機制保護共享資源，如記錄中的資料，
以避免兩個人在同一時間更新同一資料。enqueue 包括一個排隊機制，即FIFO(先進先出)
排隊機制。注意：Oracle 的latch 機制不是FIFO。Enqueue 等待通常指的是ST enqueue、
HW enqueue、TX4 enqueue 和TM enqueue。

A、ST enqueue 用於空間和字典管理的表空間的分配。利用LMT，或者試圖對區域進行
預分配，或者至少使下一個區域大於有問題的字典管理的表空間。
B、HW enqueue 與段的高水位標記一起使用；手動分配區域可以避免這一等待。
C、TX4 enqueue是最常見的enqueue 等待，通常是以下三個問題之一產生的結果:
第一個問題是唯一索引中的重複索引，需要執行提交（commit）/回滾（rollback）操
作來釋放enqueue。
第二個問題是對同一點陣圖索引段的多次更新。因為單個點陣圖段可能包含多個行地址
(rowid),所以當多個使用者試圖更新同一段時,你需要執行提交或回滾操作,以釋放enqueue。
第三個問題，也是最可能發生的問題是多個使用者同時更新同一個塊。如果沒有自由的
ITL槽，就會發生塊級鎖定。透過增大initrans 和/或maxtrans以允許使用多個ITL槽，
或者增大表上的pctfree 值，就可以很輕鬆地避免這種情況。
D、TM enqueue 在DML 期間產生，以避免對受影響的物件使用DDL。如果有外來關鍵字，一
定要對它們進行索引，以避免這種常見的鎖定問題。

<7> log buffer space 日誌緩衝空間

當日志緩衝(log buffer)寫入重做日誌(redo log)的速度比LGWR 的寫入速度慢，或者是
當日志轉換(log switch)太慢時，就會發生這種等待。為解決這個問題，可以增大日誌文
件的大小，或者增加日誌緩衝器的大小，或者使用寫入速度更快的磁碟。甚至可以考慮使
用固態磁碟，因為它們的速度很高。

<8> log file switch 日誌檔案轉換

有兩種情況：
A、log file switch (archiving needed)
當日志切換的時候由於日誌組迴圈使用了一圈但日誌歸檔還沒有完成，通常是io有嚴重
問題，可增大日誌檔案和增加日誌組，調整log_archive_max_processes

B、log file switch (checkpoint incomplete)
當日志切換的時候由於日誌組迴圈使用了一圈但將被使用的日誌組中的checkpoint還沒
有完成造成，通常是io有嚴重問題，可增大日誌檔案和增加日誌組

<9> log file sync 日誌檔案同步

當使用者commit的時候通知lgwr寫日誌但lwgr正忙，造成的可能原因是commit太頻繁或者
lgwr一次寫日誌時間太長（可能是因為一次log io size 太大），可調整 _log_io_size，
結合log_buffer,使得 (_log_io_size*db_block_size)*n = log_buffer,這樣可避免和增
大log_buffer引起衝突;放置日誌檔案於高速磁碟上

<10> 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=

這樣,就可找到"library cache pin"等待的根源，從而解決由此引起的效能問題。

<11> 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或者其它處理