Comments on: Resizing the SGA http://jonathanlewis.wordpress.com/2006/12/04/resizing-the-sga/ Just another Oracle weblog Sat, 18 May 2013 11:04:10 +0000 hourly 1 http://wordpress.com/ By: Jonathan Lewis http://jonathanlewis.wordpress.com/2006/12/04/resizing-the-sga/#comment-46597 Thu, 24 May 2012 10:31:58 +0000 http://jonathanlewis.wordpress.com/2006/12/04/resizing-the-sga/#comment-46597 Gilles,

I don’t like the expression “best practice” – a better term would probably be “commonly used defense mechanism”.

It’s been 6 years since I wrote the note, so things have moved on and the threat is diminished – but I would still be inclined to include some minimum figures for the shared_pool_size and db_cache_size if using the sga_target.

11gR2 has introduced the memory_target, of course – and my reluctance to use that matches my previous reluctance to use the sga_target.

]]> By: gilles http://jonathanlewis.wordpress.com/2006/12/04/resizing-the-sga/#comment-46379 Thu, 10 May 2012 13:09:22 +0000 http://jonathanlewis.wordpress.com/2006/12/04/resizing-the-sga/#comment-46379 Is it still the same in 11gR2 ?
Do you suggest as a “best practice” to set minimum values for the different pools ?

]]> By: Dave McKinney http://jonathanlewis.wordpress.com/2006/12/04/resizing-the-sga/#comment-20299 Thu, 06 Sep 2007 17:44:17 +0000 http://jonathanlewis.wordpress.com/2006/12/04/resizing-the-sga/#comment-20299 We suspect issues in our heavy OLTP application with AMM in regards to dynamic shared pool shrinks particularly. When AMM was turned on we had nearly constant adjustments and under heavy load we were getting lots of shared pool contention in the form of “Cursor: Pin S wait on X” waits. These waits would eventually render our DB unoperable due to excessive CPU utilization. We found flushing shared pool alleviated the issue temporarily. Worked a tickey with Oracle for a few months and started monitoring sql area, shared_pool free and dynamic shrinks. Turns out that our debilitating events were corresponding to successive shared pool shrinks. We’ve fixed the shared_pool and db_cache_size by setting sga_target = 0 and our issues seem to have disappeared.

]]> By: Remigiusz Sokolowski http://jonathanlewis.wordpress.com/2006/12/04/resizing-the-sga/#comment-14812 Tue, 10 Jul 2007 09:02:43 +0000 http://jonathanlewis.wordpress.com/2006/12/04/resizing-the-sga/#comment-14812 I have to confirm that in highly turbulent db environments (highly concurrent, many transactions, many sessions, so quite typical OLTP) ASMM is unstable.
We set it after moving to 10gR2, but had to return back to “static” memory settings. There were quite critical problems (few times some of databases crash – traces rather laconic, sometimes one or more ORA-04031 errors, actually there was nothing to send to Oracle Support) – after change of parameters we enjoy stable work (no mysterious crashes no more)

]]> By: Guy Lambregts http://jonathanlewis.wordpress.com/2006/12/04/resizing-the-sga/#comment-10447 Thu, 31 May 2007 18:50:53 +0000 http://jonathanlewis.wordpress.com/2006/12/04/resizing-the-sga/#comment-10447 Metalink Note:396940.1 mentions Bug 5045507 related to “KGH : NO ACCESS” increase in v$sgastat.
The only possible workaround is to disable ASMM, what I will do.
Personally I think there could be an interference between the likelyhood of occurence and a non zero value for session_cached_cursors combined with a huge amount of sessions. ASMM has never been my favourite 10G feature, this experience moves ASMM to my least appreciated features of 10G
Regards
Guy

]]> By: Guy Lambregts http://jonathanlewis.wordpress.com/2006/12/04/resizing-the-sga/#comment-10398 Thu, 31 May 2007 14:02:39 +0000 http://jonathanlewis.wordpress.com/2006/12/04/resizing-the-sga/#comment-10398 We are running 10.2.0.3 HP Itanium and will have to support a few thousands sessions in production. Since 2 years we are using automatic memory management. I did not have SGA issues with a limited amount of sessions and a limted SGA of let’ s say in the 500Mb – 800Mb range. We scaled up our development SGA to support thousands of connections by configuring shared server. Since we are running shared server mode I configured a SGA of 2Gb with threshold values for both shared pool, large pool and buffer cache. Today I faced an ORA 4031 at the shared pool level at that moment my shared pool was about 900Mb however trace files shows me the “KGH: NO ACCESS” component of the shared pool was about 600 Mb. If the above assumption “this is a case of shared pool granules partially freed for use by the db cache and waiting for the rest of the granule content to be unpinned so that the entire granule can become a cache granule” is true – what I would like to believe – I conclude there was a lack of free contiguous memory in my shared pool because of part of it was not -yet- available for it. More and more I ‘ve been thinking of turning the automatic SGA (re)sizing off and to move back to the old fashionned manual sizing of the various components. I wonder where I can get some info of the various shared and library cache components to get some in dept knowledge of it.
Regards
Guy

]]> By: Andy Catchpole http://jonathanlewis.wordpress.com/2006/12/04/resizing-the-sga/#comment-8599 Wed, 16 May 2007 13:06:13 +0000 http://jonathanlewis.wordpress.com/2006/12/04/resizing-the-sga/#comment-8599 Just found this post and thought I’d let you know that we are getting intermittent ORA-04031 errors using ASMM on 10.1.0.3 on Solaris. This always coincides with memory being moved from the buffer cache to the large pool (we’re using shared server too). I’m intending to turn off ASMM to resolve this.

]]> By: SGA Resizing « Oracle Scratchpad http://jonathanlewis.wordpress.com/2006/12/04/resizing-the-sga/#comment-5850 Mon, 16 Apr 2007 20:30:49 +0000 http://jonathanlewis.wordpress.com/2006/12/04/resizing-the-sga/#comment-5850 [...] Infrastructure — Jonathan Lewis @ 8:29 pm UTC Apr 16,2007 Some time ago, I wrote about resizing the SGA and the problems of automatic SGA management. In the follow-up, one of of the suggestions was to [...]

]]> By: Jonathan Lewis http://jonathanlewis.wordpress.com/2006/12/04/resizing-the-sga/#comment-3890 Fri, 09 Mar 2007 13:28:08 +0000 http://jonathanlewis.wordpress.com/2006/12/04/resizing-the-sga/#comment-3890 Albert-Frank, I would raise an SR with Oracle about this and give them a few days to diagnose the problem – especially since you seem to have avoided the critical issue. But if you get any clue that this constant fluctuation is causing a performance problem, I would turn the feature off to see if it made any noticeable difference.

]]> By: Albert-Frank Drenth http://jonathanlewis.wordpress.com/2006/12/04/resizing-the-sga/#comment-3884 Fri, 09 Mar 2007 12:26:04 +0000 http://jonathanlewis.wordpress.com/2006/12/04/resizing-the-sga/#comment-3884 We have ha d problems with ASMM. We had over 900 grows and shrinks per day, leaving effectively the pools the same. But there were many ora-4031. We have set the shared_pool manually. Increase of 20% The ora-4031 seem to have disappeared.
The grows and shrinks are persistent (600) per day. I can’t see the benefit of constantly exchanging 16M of memory. In other databases I see similar behouviour. Should you advice to turn ASMM off?

]]>