Re: Advice on running Oracle with SGA > 20 GB

From: joel garry <joel-garry_at_home.com>
Date: Mon, 1 Feb 2010 17:59:06 -0800 (PST)
Message-ID: <ce024ad5-540f-49b9-9fa3-cbb44bcf0e99_at_o28g2000yqh.googlegroups.com>

On Feb 1, 5:19 pm, vsevolod afanassiev <vsevolod.afanass..._at_gmail.com> wrote:
> Thanks for responding.

You're welcome. Just noticed this:
http://hoopercharles.wordpress.com/2010/01/31/faulty-quotes-5-block-sizes/

>
> Let's say there is no RAC, only standalone instances.
>
> Of course "start from something and then iterate" is the best approach
> available.
> However it is not very practical as:
> 1. Changing SGA_MAX_SIZE requires outage.
> 2. We found that on heavily loaded system dynamic changes of
> DB_CACHE_SIZE don't work very well.
> For example when we tried to resize DB_CACHE_SIZE from 20 GB to 30 GB
> it took almost an hour.
> During this time database experienced heavy waits on 'log file sync' -
> but there were no log switches
> and few transactions. When we tried to reisize back to 20 GB the
> instance crashed. This was 9.2.0.8.
> 3. We would rather avoid significant changes (e.g. increasing
> DB_CACHE_SIZE from 20 GB to 40 GB),
> this means that we need to go in small steps (20, 24, 28, 32, etc).
> But this is time-consuming.
> Many systems are on weekly/monthly cycle (i.e. certain batch job run
> once per month),
> so we'll have to wait one month to see the results. By that time the
> data may change.

Thanks for the real data points. Practicality usually wins.

jg

--
_at_home.com is bogus.
http://www.cleveland.com/living/index.ssf/2010/02/bill_watterson_creator_of_belo.html

Received on Mon Feb 01 2010 - 19:59:06 CST