Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Sun Solaris 2.6/5.6, Oracle 8.0.6 and SHMMAX
I don't have a copy of the 8.0.6 installation guide, but that page in the
8.1.5 one shows an _example_ of setting /etc/system. These are not the
actual values to use! There is a table a couple of pages before that which
has formulas for setting them.
The SHMMAX parameter is the maximum size of a shared memory segment and needs to be large enough to hold the whole SGA. The whole point of an SGA is to cache data in memory. If parts of it are being paged out, then you're caching data on disk (in the swap space). This is worse than having no cache at all, because you have the overhead of paging it back in when you need it.
Regards
David Lord
Senior DBA, Axis Resources, Cardiff.
> -----Original Message-----
> From: S. Anthony Sequeira [mailto:Sequeira_at_lineone.net]
> Sent: 05 July 2000 13:04
> To: Multiple recipients of list ORACLE-L
> Subject: Re: Sun Solaris 2.6/5.6, Oracle 8.0.6 and SHMMAX
>
>
> ----- Original Message -----
> To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com>
> Sent: 05 July 2000 10:25
>
>
> > Where are you getting your 'value recommended by Oracle' from?
> According to
> > the installation guide (for 8.1.5, but I'm sure that it is
> similar on
> 8.0),
> > SHMMAX should be set to 0.5 * (physical memory present in machine) -
> in your
> > case, 512Mb. I suspect that if you try to run an SGA bigger than
> physical
> > memory, you are in for a whole world of pain with paging
> and swapping.
> >
> > Regards
> > David Lord
> > Senior DBA, Axis Resources, Cardiff.
>
> From the Oracle8 Release 8.0.6 Installation Guide for Sun SPARC
> Solaris 2.x, Part #: A70109-1
>
> Pp: 2-5 - 2-6
>
> Regards.
>
> Tony
> --
> S. Anthony Sequeira
>
> Wait for the ricochet
>
> Opinions expressed herein are my own and do
> not necessarily represent those of my employer
>
>
> --
> Author: S. Anthony Sequeira
> INET: Sequeira_at_lineone.net
>
This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com Received on Wed Jul 05 2000 - 10:56:45 CDT