It would help us to interpret the significance of these figures if you told us the Oracle version, the number of CPUs and the length of the snapshot. (It also helps if you use the code tags to put the output into fixed font - check the FAQ link at top right, I can never remember the details).
Given that you are running RAC, and this looks like 10g, and the CPU usage is a significant fraction of the reported time, and you have a lot of scattered reads (with associated gc cr multiblock requests) going on I'd take a guess that you have a problem with excessive CPU usage causing a library cache problem as a side effect.
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
