等待事件在10G中的加強(二)

kewin發表於2009-11-28

等待事件在10G中的加強(二)
2009-11-27
檢視的加強:
v$event_name
9I
SQL> desc  v$event_name
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 EVENT#                                             NUMBER
 NAME                                               VARCHAR2(64)
 PARAMETER1                                         VARCHAR2(64)
 PARAMETER2                                         VARCHAR2(64)
 PARAMETER3                                         VARCHAR2(64)

10G
SQL> desc v$event_name
 Name                    Null?    Type
 ----------------------- -------- ----------------
 EVENT#                           NUMBER
 EVENT_ID                         NUMBER
 NAME                             VARCHAR2(64)
 PARAMETER1                       VARCHAR2(64)
 PARAMETER2                       VARCHAR2(64)
 PARAMETER3                       VARCHAR2(64)
 WAIT_CLASS_ID                    NUMBER
 WAIT_CLASS#                      NUMBER
 WAIT_CLASS                       VARCHAR2(64)
紅色的欄位是在10G中新加的。主要是用來把等待事件歸併到合適的類別中。至於劃分類別的好處看前一篇文章。
v$sql 和 v$sqlarea
在10g,和等待事件有關的欄位增加了以下內容:
application_wait_time 
concurrency_wait_time 
cluster_wait_time 
user_io_wait_time 
plsql_exec_time 
java_exec_time 
Oracle官方文件對此沒有做任何有意義的說明,還是通過例子來說明。
環境:
T2裡有10多萬的記錄,一個session需要更新前99行。
SQL> update t2 set wner='KK' where rownum < 100;

99 rows updated.
另外的一個session同時執行相同的sql:
SQL> update t2 set wner='KK' where rownum < 100;

這是會導致等待事件。
我們可以通過v$session試圖來檢視:
select sid, sql_id,  PREV_SQL_ID , BLOCKING_SESSION_STATUS , BLOCKING_SESSION ,WAIT_CLASS_ID,SECONDS_IN_WAIT   ,WAIT_CLASS   from v$session  where
  2   username='KONG';
SID SQL_ID        PREV_SQL_ID   BLOCKING_SESSION_STATUS           BLOCKING_SESSION WAIT_CLASS_ID SECONDS_IN_WAIT WAIT_CLASS
---------- ------------- ------------- --------------------------------- ---------------- ------------- --------------- ----------------------------------------------------------------
       290 0hcsvq77pq2a8 dyk4dprp70d74 VALID                                          300    4217450380             118 Application
       300               0hcsvq77pq2a8 NO HOLDER                                             2723168908             124 Idle
可以看到SID 為300的session阻塞了SID為290的session,等待的原因為Application。
這是不再需要聯合v$session和v$session_wait試圖。

 

 

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

相關文章