COMPONENT                        INITIAL_SIZE TARGET_SIZE FINAL_SIZE
-------------------------------- ------------ ----------- ----------
shared pool                         503316480    16777216  109051904

As far as I am aware, it’s the previous final_size that becomes the current initial_size – and yes, there are no doubt cases where columns like current_size, or initial_size, or final_size are misleading because they don’t allow for the amount of memory which hasn’t yet been released from one function to the other.

To your question (2) – the only valid answer I can give is: I don’t know, I didn’t write the code or the specification. It might be possible to engineer a few tests to check, but that could be a little difficult. We might hope that if there was a partially converted granule on its way to becoming a buffer cache granule, and you asked Oracle to increase the shared pool then it would be that granule that was used to grow the shared pool – but there may be circumstances where such behaviour is not possible.

So you are effectively saying is that the ‘TARGET’ and ‘FINAL’ column are what oracle is aimimg SHARED_POOL to be shrinked in case of SHARED_POOL SHRINKING with DEFFERED operation mode , but not the actual value SHARED_POOL could ultimately be set to .

1) Then why this pseudo ‘TARGET’ value is again used as the ‘INITIAL’ value next time SHARED_POOL is asked to GROW or SHRINK again .

Does not this make ‘TARGET’ column of v$sga_resize_ops and ‘CURRENT SIZE’ column v$sga_dynamic_components bit misleading , since they don’t take account of KGH NO ACCESS

2) Now suppose SHARED_POOL GROWS IMMEDIATE by 1 granule after a DEFFERED SHRINK of SHARED_POOL by 1 granule .
Does this ensure reclaiming the KGH NO ACCESS part by SHARED_POOL that was given away to DB BUFFER CACHE by earlier DEFFERED SHRINK and therfore making KGH NO ACCESS in v$sgasta showing 0.

Thanks for that explanation. The example also has a deferred shrink of the db cache which, by symmetry, suggests that we are releasing space in a db cache granule as buffers get written or become unpinned.

Do you know if Oracle has a different labelling mechanism when going the other way, or does it immediately label these granules as sga heap granules with some KGH: NO ACCESS space ?

BTW, do you know what ‘DEFERRED’ in OPER_MODE really means ?

Hemant K Chitale

I still have a fairly strong bias against using the automatic SGA management – especially with RAC; but if you had a clear need for varying amounts of memory over a long time span (a day/night cycle, say) I would be prepared to use it but set some lower limits for the key areas to avoid thrashing near the boundary values.

In your case, I’d start by checking v$sga_resize_ops to see if there were anything strange around the time the slowdown occurred; and I’d check the history (AWR or statspack depending which you use) for the SGA memory allocation to see if there were regular significant changes in size between the start and end of snapshots. The other thing I’d look out for in the SGA memory usage report is a large amount of memory marked “KGH NO ACCESS” – which is shared pool memory being used as buffer cache.

If you see any clues that the buffer cache or shared pool can put extreme demands on each other, I’d be more inclined to fix the memory size.

Our highly active 3 node RAC OLTP system experienced a severe 3 minute slowdown recently and we’re using ASMM. Oracle is suggesting to just set minimums for shared pool and buffer cache, but I’m wondering if we should just disable ASMM.