Troubleshooting or analyzing waits on mutex events, i.e. ones that start with "cursor:", are very similar to each other and below are some guidelines.
There are many bugs related to problems using mutexes in Oracle 10g, the first version where mutexes were introduced. If you are seeing excessive waits on mutexes, a quick fix may be to go back to the library cache latching mechanism. To do this, you can set the parameter _kks_use_mutex_pin=false.
Note: For mutex related waits, v$session.blocking_session is not populated in 10.2. However, v$session.blocking_session is populated in 11g R1.
To do further analysis, the P2RAW column in v$session gives the blocking session, i.e. the holder SID of the mutex in the upper 8 bytes. It is in hex so it needs to be converted in decimal. The following query provides the blockers with the most sessions blocked behind it as well as converts the P2RAW to an usable SID:
select p2raw, to_number(substr(to_char(rawtohex(p2raw)), 1, 8), 'XXXXXXXX') sid, count(1) sessions_waiting
from v$session
where event = 'cursor: pin S wait on X'
group by p2raw, to_number(substr(to_char(rawtohex(p2raw)), 1, 8), 'XXXXXXXX');
P2RAW SID SESSIONS_WAITING
---------------- --- ----------------
0000001F00000000 31 79
On 64 bit platforms 8 bytes are used, so the top 4 bytes are the holding session Id (if the mutex is held X), and the bottom 4 bytes are the ref count (if the mutex is held S). On 32 bit platforms 4 bytes are used, so the top 2 bytes are the holding session Id (if the mutex is held X) and the bottom 2 bytes are the ref count (if the mutex is held S).
p1 = The mutex Id
This has the same definition as v$mutex_sleep_history.mutex_identifier
p2raw = Holding Session Id | Ref Count
The most significant bytes always store the Holding Session Id (Holding SID). The least significant bytes always store the Ref Count.