RE: High shared pool usage

From: D'Hooge Freek <Freek.DHooge_at_uptime.be>
Date: Wed, 28 Sep 2011 00:35:52 +0200
Message-ID: <4814386347E41145AAE79139EAA3989817A8BC074F_at_ws03-exch07.iconos.be>



Tanel,

Is the "KGH NO ACCESS" component, memory that is entirely used for buffer cache or is it the total of the mixed granules (partly containing buffer cache, partly containing shared pool stuff)?

Is it normal that the ASMM manager could not free up so many granules when the buffer cache had to grow?

Kind regards,

Freek D'Hooge
Uptime
Oracle Database Administrator
email: freek.dhooge_at_uptime.be
tel +32(0)3 451 23 82
http://www.uptime.be
disclaimer: www.uptime.be/disclaimer
---

From: tanel_at_poderc.com [mailto:tanel_at_poderc.com] On Behalf Of Tanel Poder Sent: woensdag 28 september 2011 0:23
To: D'Hooge Freek
Cc: veeeraman_at_gmail.com; mm_at_marcusmoennig.de; ORACLE-L Subject: Re: High shared pool usage

If you google for KGH NO ACCESS, you'll see that it's just how ASMM works :)

http://blog.tanelpoder.com/2009/09/09/kgh-no-access-allocations-in-vsgastat-buffer-cache-within-shared-pool/

It's the mixed granules where buffer cache is placed within shared pool (yes, I just did say that!).

So, that 5 GB is buffer cache. Your shared pool has been big as probably during some time there was more shared pool loading activity than physical IO activity and the ASMM manager decided to increase the shared pool. Once more buffer cache was needed, it could not de-allocate complete granules anymore and just made them "composite granules"
--

Tanel Poder
Expert Oracle Exadata book:
http://www.apress.com/9781430233923

--

http://www.freelists.org/webpage/oracle-l Received on Tue Sep 27 2011 - 17:35:52 CDT

Original text of this message