這個等待事件也算一個常見的等待事件。 在warehouse blog和itpub 上有相關的2個帖子。 連線如下：

cursor: pin S wait on X等待事件模擬

cursor: pin S wait on X

一.Mutex 說明

Oracle Mutex 機制說明

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 pins can 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 successful get 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 mechanism as 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), but so far you can experiment with it if you set _kks_use_mutex_pin = true and bounce the instance (mutex structures will be stored in shared pool, so you might need to increase SP size).

There are also x$mutex_sleep and 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.ksppinm name,

i.ksppdesc description,

CV.ksppstvl VALUE,

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$ksppcv CV

WHEREi.inst_id =USERENV('Instance')

ANDCV.inst_id =USERENV('Instance')

AND i.indx =CV.indx

AND i.ksppinm LIKE'/_%'ESCAPE'/'

and i.ksppinm like'_kks%'

ORDERBYREPLACE(i.ksppinm,'_','');

Oracle 引數分類和 引數的檢視方法

二. 相關測試

[email protected](rac2)> select * from v$version where rownum<2;

BANNER

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

Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Prod

SESSION 1：

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

--建立測試表

[email protected](rac2)> create table t as select * from dba_objects;

Table created.

--檢視session ID

[email protected](rac2)> select sid from v$mystat where rownum=1;

SID

----------

125

[email protected](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

[email protected](rac2)> select sid from v$mystat where rownum=1;

SID

----------

130

[email protected](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) */

SELECT b.*, sq.sql_text

FROM v$session se,

v$sql sq,

(SELECTa.*, s.sql_text

FROM v$sql s,

(SELECTsid,

event,

wait_class,

p1,

p2raw,

TO_NUMBER(SUBSTR(p2raw,1,4),'xxxx')

sid_hold_mutex_x

FROM v$session_wait

WHERE event LIKE'cursor%')a

WHERE s.HASH_VALUE =a.p1) b

WHERE se.sid= b.sidAND se.sql_hash_value = sq.hash_value;

通過監控發現兩個session在執行相同的sql,他們在相同的cursor object上互動請求a shared mutex pin或者 an exclusive mutex pin 從而造成等待。

--監視sql reae區的cursor object reload情況

[email protected](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情況

[email protected](rac2)> col name format a40

[email protected](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 * from x$mutex_sleep;

select * from v$mutex_sleep;

相關推薦