Oracle cursor pin S wait on X 等待事件 说明

　　这个等待事件也算一个常见的等待事件。在warehouseviewspaceblog和itpub上有相关的2个帖子。连接如下：
　　
　　cursor: pin S wait on X等待事件模拟
　　http://warehouse.itpub.net/post/777/493962
　　
　　cursor: pin S wait on X
　　http://space.itpub.net/756652/viewspace-348176
　　
　　一.Mutex说明
　　Oracle Mutex机制说明
　　http://blog.csdn.net/xujinyang/article/details/6831253
　　
　　To improve cursor execution and also hard parsing, a new memory serialization mechanism has been created in 10gR2.
For certain shared-cursor related operations,mutexes are used as a replacement for library cache latches and librarycache pins.
　　-- mutexes替代library cache latches和librarycache pins。
　　
　　Using mutexes is faster, uses less CPU and also allows significantly improved concurrency over the existing latch mechanism.
The use of mutexes for cursor pinscan be enabled by setting the init.ora parameter _use_kks_mutex toTRUE.
　　
　　Btw, things get more fun in 10.2,you can pin cursors without getting library cache pin latch, using KGX mutexes.Mutexes are new thing in 10.2 and they enable shared access to objects in somewhat similar manner than shared latches, that every successfulget of particular mutex will increment its value and release will decrement. When the count is zero, no-one has the mutex and it is safe to get it in exclusive mode too. However they are more fine grained than kgl latches and provide better waiting mechanismas far as I understand.

So if your environment supports atomic compare and swap operation (as CMPXCHG on Intel), you might get away without cursor_space_for_time setting for ultrahigh execution rates. Otherwise the atomic mutex operations would be achieved using new KGX latches.

At least on my laptop this feature isn’t enabled by default (from andOracleWorld’s paper I remember that it should become default in 10.2.0.2), butso far you can experiment with it if you set _kks_use_mutex_pin = true and bounce the instance(mutexstructures will be stored in shared pool, so you might need to increase SP size).


　　There are alsox$mutex_sleepand x$mutex_sleep_history fixed tables that can show some interesting information if you generate some mutex waits into them.
　　
　　在Oracle 10.2中，对shared pool中的一些Serialization operation使用更轻量的KGX mutexes (_use_kks_mutex)取代library cache pin，从而降低CPU Usage,是否使用这种muetx机制受到隐含参数_kks_use_mutex_pin的限制。
　　
　　从10.2.0.2开始该参数default为true,使用这种机制oracle是为了解决library cache bin latch的串行使用问题,但是mutex貌似还不是很稳定,在很多系统中会出现cursor: pin S wait on X等待事件,这个事件和mutex的使用有关,最近一客户受到cursor: pin S wait on X等待事件的困扰,出现cursor: pin S wait on X等待事件时通常等待比较严重,系统会出现hang。
　　
　　cursor: pin S wait on X
A session waits for this event when it is requesting a shared mutex pin and another session is holding an exclusive mutex pin on the same cursor object.
　　
　　Wait Time: Microseconds
　　
　　Parameter Description
P1 Hash value of cursor
P2 Mutex value (top 2 bytes contains SID holding mutex in exclusive mode, and bottom two bytes usually hold the value 0)
P3 Mutex where (an internal code locator) OR'd with Mutex Sleeps
　　
　　
　　这个事件的出现受到很多因素的影响，在高并发的情况下:
　　（1）sga自动管理,sga的频繁扩展和收缩
　　（2）过渡硬解析,造成library cache中的cursor object被频繁的reload
　　（3）bug
　　
　　_kks_use_mutex_pin是隐含参数，通过v$parameter视图查不到，需要通过如下SQL来查看。
　　
　　SELECTi.ksppinmname,
　　i.ksppdesc description,
　　CV.ksppstvlVALUE,
　　CV.ksppstdf isdefault,
　　DECODE(BITAND(CV.ksppstvf,7),
　　1,'MODIFIED',
　　4,'SYSTEM_MOD',
　　'FALSE')
　　ismodified,
　　DECODE(BITAND(CV.ksppstvf,2),2,'TRUE','FALSE')isadjusted
　　FROMsys.x$ksppi i,sys.x$ksppcvCV
　　WHEREi.inst_id=USERENV('Instance')
　　ANDCV.inst_id=USERENV('Instance')
　　ANDi.indx=CV.indx
　　ANDi.ksppinmLIKE'/_%'ESCAPE'/'
　　andi.ksppinmlike'_kks%'
　　ORDERBYREPLACE(i.ksppinm,'_','');
　　

　　
　　Oracle参数分类和参数的查看方法
　　http://blog.csdn.net/xujinyang/article/details/6829538
　　
　　二.相关测试
　　SYS@anqing2(rac2)> select * from v$version where rownum<2;
　　
　　BANNER
　　----------------------------------------------------------------
　　Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Prod
　　
　　SESSION 1：
　　-------------------------
　　
　　--创建测试表
　　SYS@anqing2(rac2)> create table t as select * from dba_objects;
　　Table created.
　　
　　--查看session ID
　　SYS@anqing2(rac2)> select sid from v$mystat where rownum=1;
　　SID
　　----------
　　125
　　
　　SYS@anqing2(rac2)> declare
　　2v_string varchar2(100) := 'alter system flush shared_pool';
　　3msql varchar2(200);
　　4begin
　　5loop
　　6execute immediate v_string;
　　7for i in 1..100 loop
　　8msql:='select object_id from t where object_id='||i;
　　9execute immediate msql;
　　10end loop;
　　11end loop;
　　12end;
　　13/
　　
　　session 2：
　　-------------------------
　　--查看session ID
　　SYS@anqing2(rac2)> select sid from v$mystat where rownum=1;
　　SID
　　----------
　　130
　　
　　SYS@anqing2(rac2)> declare
　　2v_string varchar2(100) := 'alter system flush shared_pool';
　　3msql varchar2(200);
　　4begin
　　5loop
　　6execute immediate v_string;
　　7for i in 1..100 loop
　　8msql:='select object_id from t where object_id='||i;
　　9execute immediate msql;
　　10end loop;
　　11end loop;
　　12end;
　　13/
　　
　　session 3：
　　------------------------
　　用如下SQL进行监控，在sqlplus里看起来格式有点乱，我放到Toad执行了。
　　
　　/* Formatted on 2011/6/16 16:06:44 (QP5 v5.163.1008.3004) */
　　SELECTb.*,sq.sql_text
　　FROMv$session se,
　　v$sql sq,
　　(SELECTa.*,s.sql_text
　　FROMv$sql s,
　　(SELECTsid,
　　event,
　　wait_class,
　　p1,
　　p2raw,
　　TO_NUMBER(SUBSTR(p2raw,1,4),'xxxx')
　　sid_hold_mutex_x
　　FROMv$session_wait
　　WHEREeventLIKE'cursor%')a
　　WHEREs.HASH_VALUE=a.p1)b
　　WHEREse.sid=b.sidANDse.sql_hash_value=sq.hash_value;
　　

　　
　　通过监控发现两个session在执行相同的sql,他们在相同的cursor object上交互请求a shared mutex pin或者an exclusive mutex pin从而造成等待。
　　
　　--监视sql reae区的cursor object reload情况
　　SYS@anqing2(rac2)>select namespace ,reloads from v$librarycache;
　　
　　NAMESPACERELOADS
　　--------------- ----------
　　SQL AREA790805
　　TABLE/PROCEDURE103713
　　BODY59
　　TRIGGER27
　　INDEX94280
　　CLUSTER11
　　OBJECT0
　　PIPE0
　　JAVA SOURCE0
　　JAVA RESOURCE0
　　JAVA DATA0
　　
　　11 rows selected.
　　
　　--监视parse情况
　　SYS@anqing2(rac2)> col name format a40
　　SYS@anqing2(rac2)> select s.sid, s.serial#,b.name,a.value
　　2from v$sesstat a, v$statname b, v$session s
　　3where a.statistic# = b.statistic# and s.sid=a.sid
　　4and b.name like '%parse%'
　　5and s.sid in (130,125);
　　
　　sidserial# namevalue
　　---------- ---------- ---------------------------------------- ----------
　　12541915 parse time cpu115260
　　12541915 parse time elapsed146605
　　12541915 parse count (total)633792
　　12541915 parse count (hard)602732
　　12541915 parse count (failures)4
　　1306074 parse time cpu69559
　　1306074 parse time elapsed99149
　　1306074 parse count (total)394689
　　1306074 parse count (hard)365538
　　1306074 parse count (failures)0
　　
　　从这里看出，硬解析很多，library cache中的cursor object被频繁的reload。
　　
　　三.几个与mutex相关的视图
　　在第一部分，提到了x$mutex_sleep和x$mutex_sleep_history。我们在联机文档里看不到相关的说明。
　　
　　不过可以查看到v$mutex_sleep和v$mutex_sleep_history的说明。但是v$比x$字典显示的列要少。
　　
　　select*fromx$mutex_sleep;

　　
　　select*fromv$mutex_sleep;

　　
　　SYS@anqing2(rac2)> desc x$mutex_sleep_history
　　NameNull?Type
　　----------------------------------------- -------- ----------------------------
　　ADDRRAW(4)
　　INDXNUMBER
　　INST_IDNUMBER
　　MUTEX_ADDRRAW(4)
　　MUTEX_IDENTIFIERNUMBER
　　SLEEP_TIMESTAMPTIMESTAMP(6)
　　MUTEX_TYPEVARCHAR2(32)
　　MUTEX_TYPE_IDNUMBER
　　GETSNUMBER
　　SLEEPSNUMBER
　　REQUESTING_SESSIONNUMBER
　　BLOCKING_SESSIONNUMBER
　　LOCATION_IDNUMBER
　　LOCATIONVARCHAR2(40)
　　MUTEX_VALUERAW(4)
　　P1NUMBER
　　P1RAWRAW(4)
　　P2NUMBER
　　P3NUMBER
　　P4NUMBER
　　P5VARCHAR2(64)
　　
　　SYS@anqing2(rac2)> desc v$mutex_sleep_history
　　NameNull?Type
　　----------------------------------------- -------- ----------------------------
　　MUTEX_IDENTIFIERNUMBER
　　SLEEP_TIMESTAMPTIMESTAMP(6)
　　MUTEX_TYPEVARCHAR2(32)
　　GETSNUMBER
　　SLEEPSNUMBER
　　REQUESTING_SESSIONNUMBER
　　BLOCKING_SESSIONNUMBER
　　LOCATIONVARCHAR2(40)
　　MUTEX_VALUERAW(4)
　　P1NUMBER
　　P1RAWRAW(4)
　　P2NUMBER
　　P3NUMBER
　　P4NUMBER
　　P5VARCHAR2(64)
　　

　　-------------------------------------------------------------------------------------------------------