Cool! Was it 11g+? In 10g (at least up to 10.2.0.3 or .4 the mutex waiters didn’t populate blocking session)

The P1 is the hash value of the LIBRARY CACHE OBJECT accessed. Not just SQL cursors only, but any library cache object. V$SQL only show SQL child cursors, but no other library cache object. You’ll have to query X$KGLOB by KGLNAHSH to see all library cache objects.

Well, library cache issues is a wider topic – such as determining whether/why existing cursors aren’t reused (nonshared.sql etc).

The starting point of troubleshooting would be the same in 10g and 11g, regardless of latches or mutexes. You’d start from looking into P1 of the library cache related wait events – and in case of latches you can use latchprof, but with mutexes you can either use v$mutex_sleep_history (mutexprof.sql) or even easier, use the blocking session ID (in 11g, the mutex waiter resolves and populates blocking session ID in v$session/ASH) and see what that session was doing. So, the starting point – wait interface, p1,p2 – is more important and may be enough for diagnosing the issue… I use latchprof only in more advanced cases where wait interface and ASH doesn’t give enough detail…

Yep, in 10g, all the library cache latches are still there and used for protecting PL/SQL and other library cache objects, while only the cursor pinning is protected by mutexes (cursor lookup, loading etc is still protected by latches).

A question and an observation.

Question: Does this post imply that latchprof.sql can’t really be used to diagnose library cache issues in 11g because they’re protected by mutexes and not latches?

Observation: The Performance Page and Top Activity Page in OEM 10.2.0.5 still shows the old style latch wait events

I read your ppt oraclelatchandmutexcontentiontroubleshooting-110228084020-phpapp01.pdf and try to make use of p1/p2/p3 of wait event “library cache: mutex X”.

They’re something like 2185117608/0/85, 2185117608/0/106 ,2185117608/24859270709248/82. As i know how p3 works, Parameter1 (idn) and Parameter 2 (value) can’t help at all. There is no sql with hashvalue 2185117608(if it’s cursor: pin or cursor: mutex, yes this is hash value).

We’re seeing high library cache: mutex X and library cache lock after we finished exchanging partition of one partition table.

Is there any simple way to simulate the mutex on a test env? I can get library cache lock/pin easily by compiling package or add primary key to a table, however i found it hard to get mutex on my test env.