這句話通常出自一位嚴格的用戶之口
那麼
Oracle 提供了一個簡單但一流的機制來達到此目的
對於大多數等待事件而言
該視圖是當前情況的一個快照
V$SESSION_WAIT 包含了只與等待事件相關的信息
在 Oracle 數據庫
增強的會話等待
第一個增強涉及到 V$SESSION_WAIT 本身
假定您的用戶抱怨會話掛起了
SID :
SEQ# :
EVENT :enq:TX
P
P
P
P
P2 : 327681
P2RAW : 00050001
P3TEXT :sequence
P3 : 43
P3RAW :0000002B
WAIT_CLASS_ID : 4217450380
WAIT_CLASS# : 1
WAIT_CLASS : Application
WAIT_TIME : -2
SECONDS_IN_WAIT : 0
STATE :WAITED UNKNOWN TIME
注意以黑體顯示的列；在這些列中，WAIT_CLASS_ID、WAIT_CLASS# 和 WAIT_CLASS 是 10g 中新增的列。TW.wInGWiT.cOM列 WAIT_CLASS 指示等待的類型，必須將其作為有效的等待事件解決或者作為空閒的等待事件退出。在上面的例子中，等待類顯示為 Application，這表示它是一個需要您注意的等待。
該列突出顯示那些能夠證明與您的調整最相關的少數幾條記錄。例如，您可以使用如下查詢來獲取事件的等待會話。
select wait_class, event, sid, state, wait_time, seconds_in_wait
from v$session_wait
order by wait_class, event, sid
/
下面是一個樣例輸出：
WAIT_CLASS EVENT SID STATE WAIT_TIME SECONDS_IN_WAIT
---------- -------------------- ---------- ------------------- ---------- ---------------
Application enq:TX - 269 WAITING 0 73
row lock contention
Idle Queue Monitor Wait 270 WAITING 0 40
Idle SQL*Net message from client 265 WAITING 0 73
Idle jobq slave wait 259 WAITING 0 8485
Idle pmon timer 280 WAITING 0 73
Idle rdbms ipc message 267 WAITING 0 184770
Idle wakeup time manager 268 WAITING 0 40
Network SQL*Net message to client 272 WAITED SHORT TIME -1 0
在這，您可以看到幾個事件（如 Queue Monitor Wait 和 JobQueue Slave）被明確地歸為 Idle 事件。您可以將它們作為非阻塞等待消除掉；不過，有時這些“空閒”事件可能指示一個內在的問題。例如，與 SQL*Net 相關的事件可能指示高網絡延遲（除其他因素外）。
另一件要注意的重要的事情是，WAIT_TIME 的值為 -2。某些平台（如 Windows）不支持快速計時機制。如果在這些平台上沒有設定初始化參數 TIMED_STATISTICS，那麼將無法獲得准確的計時統計數據。在這種情況下，在 Oracle9i 中，該列將顯示一個非常大的數字，這使問題變得更加不清晰。在 10g 中，值 -2 指示這種情況 — 平台不支持快速定時機制並且沒有設定 TIMED_STATISTICS。（對於本文剩下的部分，我們將假定存在一個快速計時機制。）
會話也顯示等待
記得長期以來一直需要將 V$SESSION_WAIT 與 V$SESSION 結合使用以獲得有關會話的其他詳細信息嗎？嗯，這已經成為歷史了。在 10g 中，V$SESSION 視圖還顯示由 V$SESSION_WAIT 顯示的等待。下面是 V$SESSION 視圖其余的列，這些列顯示了會話當前等待的等待事件。
EVENT# NUMBER
EVENT VARCHAR2(64)
P1TEXT VARCHAR2(64)
P1 NUMBER
P1RAW RAW(4)
P2TEXT VARCHAR2(64)
P2 NUMBER
P2RAW RAW(4)
P3TEXT VARCHAR2(64)
P3 NUMBER
P3RAW RAW(4)
WAIT_CLASS_ID NUMBER
WAIT_CLASS# NUMBER
WAIT_CLASS VARCHAR2(64)
WAIT_TIME NUMBER
SECONDS_IN_WAIT NUMBER
STATE VARCHAR2(19)
這些列與 V$SESSION_WAIT 中的那些列相同，且顯示相同的信息，從而不再需要在那個視圖中查看它們了。因此，對於等待任意事件的任意會話，您僅需要查看一個視圖。
讓我們回到原來的問題：SID 為 269 的會話正等待事件 enq:TX — row lock contention，指示它正等待被另一個會話占用的鎖。要診斷該問題，您必須識別占用鎖的那個會話。但您如何才能做到這一點？
在 Oracle9i 及更低版本中，您可能得編寫復雜（和極耗資源）的查詢來獲得占用鎖的會話的 SID。而在 10g 中，您所要做的就是執行以下查詢：
select BLOCKING_SESSION_STATUS, BLOCKING_SESSION
from v$session
where sid = 269
BLOCKING_SE BLOCKING_SESSION
----------- ----------------
VALID 265
找到了：SID 為 265 的會話阻塞了會話 269。還能更容易嗎？
有多少等待？
用戶仍然在纏著您，因為用戶的問題仍然沒有得到滿意的解答。為什麼用戶的會話花了這麼長時間才完成？您可以執行以下命令來找出原因：
select * from v$session_wait_class where sid = 269;
輸出返回為：
SID SERIAL# WAIT_CLASS_ID WAIT_CLASS# WAIT_CLASS TOTAL_WAITS TIME_WAITED
---- ------- ------------- ----------- ------------- ----------- -----------
269 1106 4217450380 1 Application 873 261537
269 1106 3290255840 2 Configuration 4 4
269 1106 3386400367 5 Commit 1 0
269 1106 2723168908 6 Idle 15 148408
269 1106 2000153315 7 Network 15 0
269 1106 1740759767 8 User I/O 26 1
注意這裡有關會話等待的大量信息。現在您知道了，該會話已經為與應用程序相關的等待等待了 873 次（共 261,537 厘秒），在與網絡相關的事件中等待了 15 次等等。
以此類推，您可以使用以下查詢來查看系統范圍的等待類的統計數據。同樣，時間是以厘秒為單位的。
select * from v$system_wait_class;
WAIT_CLASS_ID WAIT_CLASS# WAIT_CLASS TOTAL_WAITS TIME_WAITED
------------- ----------- ------------- ----------- -----------
1893977003 0 Other 2483 18108
4217450380 1 Application 1352 386101
3290255840 2 Configuration 82 230
3875070507 4 Concurrency 80 395
33864003
From:http://tw.wingwit.com/Article/program/Oracle/201311/16917.html