You are on page 1of 3

select event, sql_hash_value,state, count(*) from v$session w where event='latch free' and status='ACTIVE' group by sql_hash_value, state , event

select addr, latch#, child#, level#, gets from v$latch_children where addr='00000004A0A51780'

select hladdr, file#, dbablk, decode(state,1,'cur ',3,'CR',state) ST, tch from x$bh where hladdr in (select addr from (select addr from v$latch_children where addr='00000004A0A 51780' order by sleeps, misses,immediate_misses desc )where rownum <2)

accept h_file_id prompt ' Enter file_id ==>' accept h_block_id prompt ' Enter block_id==>' set verify off column owner format A10 column segment_name format A20 column segment_type format A10 column hdrfile format 9999 column curfile format 9999 column curblk format 99999999 column hdrblock format 99999999 select owner, segment_name,partition_name, segment_type, file_id,block_id from dba_extents where file_id = &&h_file_id and block_id &&h_block_id; set verify on

alter system dump datafile 15 block min 16215 block max 16215; alter system dump datafile 9 block min 52872 block max 52872; alter system dump datafile 8 block min 45128 block max 45128; Reading trace files, we see three different segments and one line per block is p rinted below from the trace file. seg/obj: 0xd756 csc: 000.17b5fe4f itc: 2 flg: E typ: 1 DATA seg/obj: 0x1801a csc: 000.1cb9f0ab itc: 2 flg: E typ: 1 DATA seg/obj: 0x181c5 csc: 000.1bef7a59 itc: 169 flg: E typ: 2 INDEX seg/obj field is the object_id printed in hex. Converting these hex numbers d756 , 1801a and 181c5 to decimal equivalents results in 55126, 98330,98757. Now,we could query, dba_objects to find object_names. select owner, object_id, object_name, data_object_id from dba_objects where object_id in (55126, 98330,98757) or data_object_id in (55126, 98330,98757)

Troubleshooting: Tuning the Shared Pool and Tuning Library Cache Latch Contentio n [ID 62143.1] ================================================================================ ============== * All object names must resolve to the same actual objects * The optimizer goal of the sessions issuing the statement should be the sam e * The types and lengths of any bind variables should be "similar". (We dont discuss the details of this here but different types or lengths of bind variable s can cause statements to be classed as different versions) * The NLS (National Language Support) environment which applies to the state ment must be the same. Hard Parse Soft Parse Identical Statements ? Sharable SQL Versions of a statement if two statements are textually identical but cannot be shared then these are ca lled 'versions' of the same statement If Oracle matches to a statement with many versions it has to check each version in turn to see if it is truely identical to the statement currently being parse d. Hence high version counts are best avoided by: * Standardising the maximum bind lengths specified by the client * Avoid using identical SQL from lots of different schemas which use private objects. Eg: SELECT xx FROM MYTABLE; where each user has their own MYTABLE * Setting _SQLEXEC_PROGRESSION_COST to '0' in Oracle 8.1 Finding statement/s which use lots of shared pool memory: SELECT substr(sql_text,1,40) "Stmt", count(*), sum(sharable_mem) "Mem", sum(users_opening) "Open", sum(executions) "Exec" FROM v$sql GROUP BY substr(sql_text,1,40) HAVING sum(sharable_mem) > <MEMSIZE>; where MEMSIZE is about 10% of the shared pool size in bytes. This should show if there are similar literal statements, or multiple versions of a statements which account for a large portion of the memory in the shared pool.

Allocations causing shared pool memory to be 'aged' out:

SELECT * FROM x$ksmlru WHERE ksmlrnum>0;

SELECT name, 'Child ' child#, gets, misses, sleeps FROM v$latch_children WHERE addr='&P1RAW' UNION SELECT name, null, gets, misses, sleeps FROM v$latch WHERE addr='&P1RAW' ;

You might also like