RE: Combined SGA size and Total Memory

From: Graeme Farmer <graeme.farmer_at_mincom.com>
Date: Thu, 24 Jun 2004 09:52:16 +1000
Message-ID: <DA5B390A2CBAA64AB2367C2EDA3210F60CA656E0@tqxbneclu03.root.tequinox.com>

I would have thought that the SGA should be as big as it needs to be and no bigger!!

Needlessly allocating extra memory to the SGA just because you have can make Oracle work harder as it has more memory to manage. Buffer chain lengths will increase and scanning and cache chains latch contention has the potential to increase on active systems.

The size of the SGA should also depend on other processes on the system and their usage (including Oracle processes that perhaps require a large sort buffer).

Cheers,
Graeme.

-----Original Message-----
From: tboss_at_bossconsulting.com [mailto:tboss_at_bossconsulting.com] Sent: Thursday, 24 June 2004 8:33 AM
To: oracle-l_at_freelists.org
Subject: Re: Combined SGA size and Total Memory

Ugh, 30% of memory would be such a waste of expensive physical Ram.

70-75% of your physical ram for Oracle is fine, assuming you've got ample swap space and no other applications on the machine.

If you let 9i dbca default all its values, it assumes 70% as a target. This is as good of a "rule of thumb" as any.

Todd

>
> Hello,
>
> A fellow DBA tells me that the total SGA size of all instances on the
serve=
> r (HP, Sun) should not exceed 30% of the server's total memory. I
> could not find any documentation supporting this argument in Metalink? Is
t=
> here is any such guideline? My impression was to monitor the
> paging/swap on the server before adding more memory rather than going by
th=
> e rule of thumb....=20
>
> Thanks in advance for your input.
>
> Biju Thomas
>
>
>

___________________________________________________________________________=


> __________________________________

>
> This electronic transmission and any attached files are intended solely
for=
> the person or entity to which they are addressed and may contain
informati=
> on that is privileged, confidential or otherwise protected from
disclosure.=
> Any review, retransmission, dissemination or other use, including taking
a=
> ny action concerning this information by anyone other than the named
recipi=
> ent, is strictly prohibited. If you are not the intended recipient or have
=
> received this communication in error, please immediately notify the sender
=
> and destroy this communication.
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request_at_freelists.org
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
>

---

Please see the official ORACLE-L FAQ: http://www.orafaq.com

---

To unsubscribe send email to: oracle-l-request_at_freelists.org put 'unsubscribe' in the subject line.

--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------


-- 
This transmission is for the intended addressee only and is confidential information. If you have received this transmission in error, please notify the sender and delete the transmission. The contents of this e-mail are the opinion of the writer only and are not endorsed by the Mincom Limited unless expressly stated otherwise.

----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request_at_freelists.org
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Received on Wed Jun 23 2004 - 18:49:39 CDT