Hi Michael:
Why don't you use this Steve Adams' script to check the fragmentation
of your shared pool, it may be badly
fragmented and this problem could generate a lot of pressure at the shared
pool latch.
And this situation can also generate contention at a lower level latch (like
the library cache latch).
Make sure the session has been up and running for some time before running
it and don't execute any
shared pool flush before running it, or your data would be misleading.
Here's the script, or you can dowload it from IXORA site.
www.ixora.com.au
----------------------------------------------------------------------------
----------------------
----------------------------------------------------------------------------
---
--
-- Script: shared_pool_free_lists.sql
-- Purpose: to check the length of the shared pool free lists
-- For: 8.0 and higher
--
-- Copyright: (c) 2000 Ixora Pty Ltd
-- Author: Steve Adams
--
-- Warning: This script queries x$ksmsp which causes it to take the
-- shared pool latch for a fairly long time.
-- Think twice before running this script on a large system
-- with potential shared pool problems -- you may make it worse.
--
----------------------------------------------------------------------------
---
@save_sqlplus_settings
select
decode(sign(ksmchsiz - 80), -1, 0, trunc(1/log(ksmchsiz - 15, 2)) - 5)
bucket,
sum(ksmchsiz) free_space,
count(*) free_chunks,
trunc(avg(ksmchsiz)) average_size,
max(ksmchsiz) biggest
from
sys.x_$ksmsp
where
inst_id = userenv('Instance') and
ksmchcls = 'free'
group by
decode(sign(ksmchsiz - 80), -1, 0, trunc(1/log(ksmchsiz - 15, 2)) - 5)
/
@restore_sqlplus_settings
----------------------------------------------------------------------------
---------------------
HTH
Diego Cutrone
----- Original Message -----
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
Sent: Wednesday, January 16, 2002 7:10 PM
> All,
> In trying to solve some Library Cache latch contention issues, I've been
> stumped on the following issues:
>
> 1) Do freeable chunks get coalesced during an ALTER SYSTEM FLUSH
> SHARED_POOL.
> 2) If freeable chunks are freed when a session disconnects, is there a
way
> to determine chunks per session? The idea here is better memory management
> through better session management.
>
> I've aleviated the majority of latch contention by altering the
> _kgl_latch_count parameter, but haven't addressed what I think is the root
> cause: an oversized shared pool. I've found scripts that show the amount
of
> memory occupied by the sql area and library cache, and most if the memory
is
> in freeable chunks. Before downsizing the shared pool, I'd like to have a
> better understanding of how these chunks are managed.
>
> Regards,
> Mike G
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Michael Ghelli
> INET: [EMAIL PROTECTED]
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Diego Cutrone
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
