基於等待事件的效能診斷

什麼是瓶頸？一旦熟悉了系統的等待事件，就能夠把握問題的關鍵，並能夠用相應的方法去處理阻塞系統的瓶頸，一定不要隨意的進行最佳化，否則一波不息一波又起，可以透過v$system_event獲取系統總的等待情況，然後透過v$session_event檢視系統中session的等待情況，最後透過v$session_wait定位瓶頸物件。v$session_wait是會話級的，它包含session的實時資訊，最重要的是：它顯示了等待事件與相應資源的更深入資訊，可確定出產生瓶頸的型別及其物件。
v$session_wait的p1、p2、p3告訴我們等待事件的具體含義，如果wait event是db file scattered read，p1=file_id/p2=block_id/p3=blocks，然後透過dba_extents即可確定出熱點物件；如果是latch free的話,p2為閂鎖號，它指向v$latch。

--等待事件及其對應的latch

col event format a32
col name format a32
select sid,event,p1 as file_id, p2 as "block_id/latch", p3 as blocks,l.name
from v$session_wait sw,v$latch l
where event not like '%SQL%' and event not like '%rdbms%'
and event not like '%mon%' and sw.p2 = l.latch#(+);

--等待事件及其熱點物件

col owner format a18
col segment_name format a32
col segment_type format a32
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;

--綜合以上兩條sql，同時顯示latch及熱點物件(速度較慢)

select sw.sid,event,l.name,de.segment_name
from v$session_wait sw,v$latch l,dba_extents de
where event not like '%SQL%' and event not like '%rdbms%'
and event not like '%mon%' and sw.p2 = l.latch#(+) and sw.p1 = de.file_id(+) and p2 between de.block_id and de.block_id + de.blocks - 1;

--如果是非空閒等待事件，透過等待會話的sid可以求出該會話在執行的sql

select sql_text
from v$sqltext_with_newlines st,v$session se
where st.address=se.sql_address and st.hash_value=se.sql_hash_value
and se.sid =&wait_sid order by piece;

透過等待事件找出系統中消耗資源較嚴重的sql，是dba進行系統診斷的手段之一。只是過程稍嫌煩瑣，由於session是動態的、瞬息萬變、不可捕獲，當你想捕獲時，該session可能已經釋放，但這種捕獲很有針對性；也可以透過對v$sql或v$sqlarea進行過濾，找出存在效能問題的sql,長時間地對v$sql進行監控，並對捕獲的sql進行最佳化處理，可以在很大程度上解決系統的效能問題。