通過11G的V$SESSION來分析鎖阻塞關係

wei-xh發表於2011-07-12
Session
-------------------SESSION 1,SID=3252
create table wxh_tbd tablespace apollo_data as select a.* from dba_objects a ,dba_objects b where rownum<50000000;

Table created.

alter table wxh_tbd modify OBJECT_NAME not null;-------------表要足夠大，使這個操作足夠長

-------------------SESSION 2,等待,,SID=3250
select count(*) from wxh_tbd where rownum=1;

-------------------SESSION 3,等待,SID=3248
select count(*) from wxh_tbd where rownum=1;

-------------------SESSION 4
set linesize 200
col action for a15
col event for a25
col sql_id for a15
select sid,serial#, SQL_ID, ACTION, BLOCKING_SESSION, BLOCKING_SESSION_STATUS, EVENT
from v$session where BLOCKING_SESSION is not null;
       SID    SERIAL# SQL_ID          ACTION          BLOCKING_SESSION BLOCKING_SESSION_STATU EVENT
---------- ---------- --------------- --------------- ---------------- ---------------------- -------------------------
      3248       3365 4vuw3tfxd9kd2                               3250 VALID                  cursor: pin S wait on X
      3250      18443 4vuw3tfxd9kd2                               3252 VALID                  library cache lock

從結果非常容易看出,3252阻塞了3250,3250又阻塞了3248.
一般我們都認為 cursor: pin S wait on X等待是由於硬解析過多導致的
從這個例子來看,如果系統中存在比較耗時的DDL，會導致大量的這種
cursor: pin S wait on X等待，這種情況下的cursor: pin S wait on X等待
並不是由於硬解析導致的。     
這幾個等待事件的詳細分析，見我的另一個文章：
http://space.itpub.net/22034023/viewspace-701368

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

相關文章