Cursor Pin競合と関連して必ず見るべきのMetalinkノート

Oracle10gからcursor: pin ... のような名前の待機イベントがよく見つかります。Mutexが同期化客体で使用されながら現れた現状なのに、このMutexの問題はHolderを観察するのがむずかしいと言うことです。残念ながらMaxgaugeのようなモニタリングツールもMutexのHolderは提供しません。

しかし、下のMetalinkノートを呼んでみますと以外に易しくMutexのHolderを見付けられるということが分かります。

ノートID: 786507.1
題目: HOW TO FIND BLOCKING SESSION FOR MUTEX WAIT EVENT cursor: pin S wait on X

Metalink使用権限がない方たちのために簡略にスクリプトだけ紹介すれば次のようです（ノートの内容全体をCopy&Pasteするのは不法です）。

-- 64ビットシステムでは8の位、32ビットシステムでは4の位を取る
SELECT p2raw
,to_number(substr(to_char(rawtohex(p2raw)), 1, 8), 'XXXXXXXX') sid
FROM v$session
WHERE event = 'cursor: pin S wait on X';

P2RAW               SID
----------------    ---
0000001F00000000     31 

31は始めの８位0000001F値の10進数の値です。すなわち現在のHolderが31番のセッションという意味です。Maxgaugeのようにアクティブセッションのリストと待機イベントのリストを貯蔵しているモニタリングツールではHolderセッションを上のように手軽に見付けることができますね。

もちろんAWRでも同一に使用できます。

11gからはV$SESSION.BLOCKING_SESSIONにHolder情報が記録されます。ずいぶんよくなりました。

でも、本当の問題はHolderセッションを見付けた後からですよ。：)