SELECT n.name, SUM(w.p3) Sleeps
FROM V$SESSION_WAIT w, V$LATCHNAME n
WHERE w.event = 'latch free'
AND w.p2 = n.latch#
GROUP BY n.name;

With the consideration of the above, the only meaningful piece of information provided, other than the specific latch name, is the number of sleeps while waiting for the latch to become available (p3 (tries) is the number of times the process has slept waiting for the latch).

There are a number of causes for shared pool latch contention and library cache latch contention. A couple of resources:
http://jonathanlewis.wordpress.com/2007/01/21/shared-sql/
http://jonathanlewis.wordpress.com/2008/12/23/library-cache/
http://jonathanlewis.wordpress.com/2007/01/05/bind-variables/

Also see discussion by Mark Bobak and Jonathan Lewis:
http://forums.oracle.com/forums/thread.jspa?messageID=9432629&tstart=0

—-
I am sure that you are aware, but I thought that it would good to mention for anyone else reading this article, that access to V$ACTIVE_SESSION_HISTORY and/or access to ASH and/or access to AWR and/or access to ADDM requires an Enterprise Edition license plus a Diagnostic Pack license.

OK, all those rules like decreasing parsing, using proper binds etc. it’s common investigation.
We can dig in it any time on running database, shooting SQLs using literals, or searching through v$sql_shared_cursors to find SQLs with non-shareable binds (due to changes in session’s nls settings etc)…
But the question, I’ve tried to understand is Why ASH reports shows us “latch: library cache” with P1, P2, P3. What use of those ones?
We are talking about events occurred in past time. How P1 could be useful for investigation? The only way I found to use it is query like:

select distinct sql_id from V$ACTIVE_SESSION_HISTORY
where sample_time between
to_timestamp(…..) and to_timestamp(…..) and
event = ‘latch: shared pool’ and
p1 = &P1 and
sql_id is not null;

But, again, what all those queries (we’ve found with above query) waiting for? Are they waiting just for allocating memory piece by P1 address? Why for this address? Short of shared memory?…

Best regards.

You might try a quick SQL statement:

SELECT
  ADDR,
  LATCH#,
  NAME
FROM
  V$LATCH
WHERE
  NAME = 'library cache';

My output looks like this:

ADDR                 LATCH# NAME
---------------- ---------- -------------
00000000047A5FF0        214 library cache

I believe that you will find that if you convert the number 1398554576 found in the wait event to a hex number, it will be the same number as is what is displayed in the ADDR column of the above SQL statement. So, that probably did not help much. The wait time on that latch seems to be a little long at 0.008566 seconds – is it possible that the CPU utilization was atypically high on the server?

You might take a look at the following presentation that was created by Kyle Hailey – there are notes attached to some of the slides: http://www.perfvision.com/papers/10_libc.ppt

My notes on library cache and shared pool latches follow. The notes are mostly paraphrases from the Oracle documentation, for instance from the following page:
http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/instance_tune.htm#sthref787
p1 (address) is the address of the latch, p2 (number) is the latch number, p3 (tries) is the number of times the process has slept waiting for the latch
A main cause of shared pool or library cache latch contention is parsing. For shared pool and library cache latches, possible causes include not using bind variables, insufficient size of application cursor cache, cursors closed explicitly after each execution, frequent log on/off, shared pool too small.

Examine the resource usage for related resources. For example, if the library cache latch is heavily contended for, then examine the hard and soft parse rates.
Examine the SQL statements for the sessions experiencing latch contention to see if there is any commonality.

For Shared pool,library cache
** Lack of statement reuse, Statements not using bind variables, Insufficient size of application cursor cache,
** Cursors closed explicitly after each execution, Frequent logon / logoffs,
** Underlying object structure being modified (for example truncate), Shared pool too small
* Look for:
** Sessions (in V$SESSTAT) with high:
** parse time CPU
** parse time elapsed
** Ratio of parse count (hard) / Execute Count
** Ratio of parse count (total) / Execute Count
* Cursors (in V$SQLAREA/V$SQLSTATS) with:
** High ratio of PARSE_CALLS / EXECUTIONS
** EXECUTIONS = 1 differing only in literals in the WHERE clause (that is, no bind variables used)
** High RELOADS
** High INVALIDATIONS
** Large (> 1mb) SHARABLE_MEM

You might be able to break the numbers down a little more by examining V$LATCH_CHILDREN:

SQL> DESC V$LATCH_CHILDREN
 Name
 -------------------------

 ADDR
 LATCH#
 CHILD#
 LEVEL#
 NAME
 HASH
 GETS
 MISSES
 SLEEPS
 IMMEDIATE_GETS
 IMMEDIATE_MISSES
 WAITERS_WOKEN
 WAITS_HOLDING_LATCH
 SPIN_GETS
 SLEEP1
 SLEEP2
 SLEEP3
 SLEEP4
 SLEEP5
 SLEEP6
 SLEEP7
 SLEEP8
 SLEEP9
 SLEEP10
 SLEEP11
 WAIT_TIME

Regards

It has been a couple of years, but it appears that I performed the following steps:

SQL> ALTER SESSION SET EVENTS '10046 TRACE NAME CONTEXT FOREVER, LEVEL 8';
 
Session altered.
 
SQL> select distinct owner from v$access
  2  /
 
SQL> ALTER SESSION SET EVENTS '10046 TRACE NAME CONTEXT OFF';

Then I looked inside the 10046 trace file and found my SQL statement:

=====================
PARSING IN CURSOR #1 len=35 dep=0 uid=31 oct=3 lid=31 tim=3112364669 hv=3250939240 ad='8135a590'
select distinct owner from v$access
END OF STMT
PARSE #1:c=15625,e=10795,p=0,cr=4,cu=0,mis=1,r=0,dep=0,og=1,tim=3112364664
EXEC #1:c=0,e=138,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=3112365290
WAIT #1: nam='SQL*Net message to client' ela= 5 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=3112365434
FETCH #1:c=1078125,e=1078741,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=1,tim=3113444285
WAIT #1: nam='SQL*Net message from client' ela= 400 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=3113445654
WAIT #1: nam='SQL*Net message to client' ela= 2 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=3113445934
FETCH #1:c=0,e=113,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=1,tim=3113446026
WAIT #1: nam='SQL*Net message from client' ela= 1938 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=3113448064
WAIT #1: nam='SQL*Net message to client' ela= 1 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=3113448214
FETCH #1:c=0,e=105,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=1,tim=3113448309
WAIT #1: nam='SQL*Net message from client' ela= 2643 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=3113451047
WAIT #1: nam='SQL*Net message to client' ela= 1 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=3113451191
FETCH #1:c=15625,e=132,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=1,tim=3113451316
WAIT #1: nam='SQL*Net message from client' ela= 2987 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=3113454763
FETCH #1:c=0,e=26,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=3113454938
WAIT #1: nam='SQL*Net message to client' ela= 2 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=3113455065
WAIT #1: nam='SQL*Net message from client' ela= 1777 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=3113456919
STAT #1 id=1 cnt=46 pid=0 pos=1 obj=0 op='SORT UNIQUE (cr=0 pr=0 pw=0 time=1078756 us)'
STAT #1 id=2 cnt=42462 pid=1 pos=1 obj=0 op='HASH JOIN  (cr=0 pr=0 pw=0 time=1142988 us)'
STAT #1 id=3 cnt=335 pid=2 pos=1 obj=0 op='FIXED TABLE FULL X$KSUSE (cr=0 pr=0 pw=0 time=362 us)'
STAT #1 id=4 cnt=42462 pid=2 pos=2 obj=0 op='NESTED LOOPS  (cr=0 pr=0 pw=0 time=1056455 us)'
STAT #1 id=5 cnt=42462 pid=4 pos=1 obj=0 op='HASH JOIN  (cr=0 pr=0 pw=0 time=334562 us)'
STAT #1 id=6 cnt=21082 pid=5 pos=1 obj=0 op='FIXED TABLE FULL X$KGLLK (cr=0 pr=0 pw=0 time=21506 us)'
STAT #1 id=7 cnt=100382 pid=5 pos=2 obj=0 op='FIXED TABLE FULL X$KGLDP (cr=0 pr=0 pw=0 time=200900 us)'
STAT #1 id=8 cnt=42462 pid=4 pos=2 obj=0 op='FIXED TABLE FIXED INDEX X$KGLOB (ind:1) (cr=0 pr=0 pw=0 time=637605 us)'
WAIT #0: nam='SQL*Net message to client' ela= 2 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=3113457700
*** 2011-05-04 07:52:59.140
WAIT #0: nam='SQL*Net message from client' ela= 11023640 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=3124481452
=====================

The first line shows: PARSING IN CURSOR #1 … hv=3250939240 ad=’8135a590′. The value that follows hv= is the hash value for the SQL statement. I just noticed that the blog article implies that the hash value is found on the WAIT lines, but that was not the intention of this comment (I worded this poorly) “On the waits, P1 is 13985, P2 is 214, P3 is 0, Buf is 99, SQL Hash is 3250939240″.

A multi-part series on 10046 trace files may be found here:
http://hoopercharles.wordpress.com/2009/12/01/10046-extended-sql-trace-interpretation/

Could you explain please how you found hv=3250939240 ?
Thanks.