The library cache pin is simply a session marking a library object (e.g. cursor) for use – either shared (because it wants to use an existing cursor, say) or exclusive (because it needs to invalidate and recompile a cursor).
This should be a very rapid action but in your case it isn’t – your average wait is more than 2 seconds. It isn’t possible to say why this is happening, but if you are doing cross-instance invalidations (e.g. truncating tables regularly) AND you have a very busy system (lots of CPU in use) that can be enough to cause these symptoms.
On a long shot – the scattered reads (possible tablescans) may be causing some remastering (gc remaster or similar), and this can cause a freeze (gcs drm freeze or similar): this shouldn’t cause problems to the library cache – which operates under the ‘global enqueue’ processes rather than ‘global cache’ processes – but maybe there is some connection.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
Answering to http://forums.oracle.com/forums/thread.jspa?threadID=547850&tstart=60
[...] or waiting, all of which were concurrency waits. Investigating further, these were all “library cache pin” waits. We killed the rebuild session from its terminal, and about two-thirds of the sessions [...]
Pingback by Recompiling Busy Package Bodies in a RAC Environment « Learning Oracle — January 24, 2008 @ 4:54 pm |