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

最新推荐文章于 2023-08-03 14:53:28 发布

转载最新推荐文章于 2023-08-03 14:53:28 发布 · 160 阅读

本文通过具体示例展示了在Oracle数据库中执行大型DDL操作时如何引发多个会话间的阻塞情况，并分析了cursor:pinSwaitonX等待事件并非总是由硬解析引起。

-------------------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/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/22034023/viewspace-701956/