等待事件cursor: pin S wait on X

等待事件cursor: pin S wait on X

 

是10.2版本提出的mutex(互斥)机制用来解决library cache bin latch争夺问题引入的新事件,是否使用这种机制受到隐含参数_kks_use_mutex_pin的限制,从10.2.0.2开始该参数default为true,使用这种机制oracle是为了解决library cache bin latch的串行使用问题,但是mutex貌似还不是很稳定,在很多系统中会出现cursor: pin S wait on X等待事件,这个事件和mutex的使用有关:
SQL> SELECT nam.ksppinm NAME, val.ksppstvl VALUE
  2  FROM x$ksppi nam, x$ksppsv val
  3  WHERE nam.indx = val.indx AND nam.ksppinm LIKE '%mutex%'
  4  ORDER BY 1;
NAME                                               VALUE
-------------------------------------------------- ----------------------------------------
_kks_use_mutex_pin                                 TRUE

最近在生产库上执行一个修改表结构的sql时，数据库hang住，以下是对该问题的模拟：

Session 1，执行修改表结构操作：

SQL> alter table BC_REGISTED_SUBSCRIBE modify SUBSCRIBE_CODE char(5);
…….执行过程中

Session 2，在表BC_REGISTED_SUBSCRIBE上执行查询：

SQL> select sid from v$mystat where rownum=1;
       SID
----------
       141

SQL>  select * from BC_REGISTED_SUBSCRIBE where rownum=1;

……..session 2被堵塞

此时查看数据中等待事件，

SQL> select sid,event from v$session where wait_class<>'Idle';
       SID EVENT
---------- ----------------------------------------------------------------
       141 library cache lock
       159 db file scattered read
       166 log file parallel write

Session 3，对表执行select查询：

SQL> select sid from v$mystat where rownum=1;

       SID
----------
       155
SQL>  select * from BC_REGISTED_SUBSCRIBE where rownum=1;
…….hang住

此时再查看数据库中等待事件：

SQL> select sid,event from v$session where wait_class<>'Idle';
       SID EVENT
---------- ----------------------------------------------------------------
       141 library cache lock
       155 cursor: pin S wait on X
       159 db file scattered read

Session 4：对表执行select查询：

SQL> select sid from v$mystat where rownum=1;
       SID
----------
       147

SQL>  select * from BC_REGISTED_SUBSCRIBE where rownum=1;
…….hang住

此时查看数据库中等待事件：

SQL> select sid,event from v$session where wait_class<>'Idle';
       SID EVENT
---------- ----------------------------------------------------------------
       141 library cache lock
       147 cursor: pin S wait on X
       149 SQL*Net message to client
       155 cursor: pin S wait on X
       159 db file sequential read
    当session 1执行修改表结构的操作时，对于第一个执行select查询的session，将在library cache lock上等待，而后续的session将在cursor:pin S wait on X上等待，而在生产库中观察到的等待事件也是如此，只有一个session在等待library cache lock，而大量的session在等待cursor:pin S wait on X。

如果我们把mutex机制关闭，再来观察系统的等待情况：
SQL> alter system set "_kks_use_mutex_pin"=false scope=spfile;

System altered.

SQL> startup force
ORACLE instance started.

Total System Global Area  260046848 bytes
Fixed Size                  1266944 bytes
Variable Size              79694592 bytes
Database Buffers          167772160 bytes
Redo Buffers               11313152 bytes
Database mounted.
Database opened.
SQL> SELECT nam.ksppinm NAME, val.ksppstvl VALUE
  2  FROM x$ksppi nam, x$ksppsv val
  3  WHERE nam.indx = val.indx AND nam.ksppinm LIKE '%mutex%'
  4  ORDER BY 1;

NAME                                               VALUE
-------------------------------------------------- ----------------------------------------
_kks_use_mutex_pin                                 FALSE

session 1：

SQL> alter table BC_REGISTED_SUBSCRIBE modify SUBSCRIBE_CODE char(5);
.......执行中

session 2：

SQL> select sid from v$mystat where rownum=1;

       SID
----------
       150

SQL> select * from BC_REGISTED_SUBSCRIBE where rownum=1;
........hang

session 3：SQL> select sid from v$mystat where rownum=1;

       SID
----------
       149

SQL> select * from BC_REGISTED_SUBSCRIBE where rownum=1;
........hang

session 4:

SQL> select sid from v$mystat where rownum=1;

       SID
----------
       144

SQL> select * from BC_REGISTED_SUBSCRIBE where rownum=1;
........hang

查看系统中等待事件：

SQL> select sid,event from v$session where wait_class<>'Idle';

       SID EVENT
---------- ----------------------------------------------------------------
       144 library cache pin
       149 library cache pin
       150 library cache lock
       159 db file scattered read
       166 log file parallel write

可见，当关闭mutex机制时，原来的cursor: pin S wait on X等待变成了library cache pin的等待，很明显，在10g中oracle是用mutex的机制来取代了原来的library cache pin的机制。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/8102208/viewspace-667249/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/8102208/viewspace-667249/