cursor:pin S wait on X
什麼是cursor:pin S wait on X 等待事件?
當一個會話嘗試得到一個mutex pin的時候,但是其他會話正在以exclusive模式持有相同cursor object的mutex,此時申請mutex pin的會話等待事件即為cursor:pin S wait on X 。
造成該等待事件的原因:
1.shared pool設定太小,或者由于自動記憶體管理導緻的。
2.頻繁的硬解析
3.子遊标太多
4.BUG
5.解析錯誤
關于解析錯誤,可以通過設定10035事件開啟記錄解析錯誤的sql到alert.log中。
ALTER SYSTEM SET EVENTS '10035 trace name context forever, level 1';
如何定位問題會話和sql呢?
首先通過v$event_name檢視p1 p2 p3含義:
[email protected](CDB$ROOT)> set line 100
[email protected](CDB$ROOT)> select PARAMETER1,PARAMETER2,PARAMETER3 from v$event_name where name='cursor: pin S wait on X';
PARAMETER1 PARAMETER2 PARAMETER3
------------------------------ ------------------------------ ------------------------------
idn value where
p1值是Mutex identifier,與sql的hash value比對可以得到具體的sql,可以用下面的sql查詢,注意不要填成了p1raw值。
SELECT sql_id, sql_text, version_count
FROM V$SQLAREA where HASH_VALUE='000000001A27969A';
p2值是Mutex value。高8位包含了持有mutex的會話的sid資訊,也就是holder的sid;低8位是reference count值,如果都是0的話,那麼證明該持有者以X模式持有。比如p2raw:0000005200000000
SELECT decode(trunc(0000005200000000/4294967296),
0,trunc(0000005200000000/65536),
trunc(0000005200000000/4294967296)) SID_HOLDING_MUTEX
FROM dual;
352187318272
21474836480
p3值是被請求的mutex的位址,可以用下面的sql查詢
SELECT MUTEX_TYPE, LOCATION
FROM x$mutex_sleep
WHERE mutex_type like 'Cursor Pin%'
and location_id in (
SELECT decode(trunc(&&P3/4294967296),
0,trunc(&&P3/65536),
trunc(&&P3/4294967296)) LOCATION_ID
FROM dual);
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31480688/viewspace-2648470/,如需轉載,請注明出處,否則将追究法律責任。
轉載于:http://blog.itpub.net/31480688/viewspace-2648470/