ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 通过11G的V$SESSION来分析锁阻塞关系

通过11G的V$SESSION来分析锁阻塞关系

原创 Linux操作系统 作者:wei-xh 时间:2011-07-12 12:32:22 0 删除 编辑
-------------------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/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
Oracle ACE组成员,DBGeeK用户组发起人。曾在DTCC、ORACLE技术嘉年华、Gdevops等公开场合做过数据库技术专题分享,2017年应Oracle邀请在世界最大的数据库会议OOW上做技术分享。组织翻译了《拨云见日,解密Oracle ASM内核》一书。

注册时间:2009-07-04

  • 博文量
    422
  • 访问量
    2341164