| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: SHMMAX setting with multiple instances? Solaris 2.8,Oracle 8.1.7.4
ISM can't be used for those segments which can't be locked into memory,
because ISM segments can never be paged out. But it'd be stupid to create a
SGA larger than RAM anyway, thus this isn't really an issue...
Tanel.
> Er, regarding ISM, what I meant to say was:
> The rumor states that unless your SGA is in one contiguous shared memory =
> segment, Solaris won't use ISM. That is false. ISM will be used =
> regardless of whether the SGA is broken into multiple shared memory =
> segments.
>
> -Mark
>
> -----Original Message-----
> From: Bobak, Mark=20
> Sent: Friday, February 13, 2004 10:53 AM
> To: oracle-l_at_freelists.org
> Subject: RE: SHMMAX setting with multiple instances? Solaris 2.8,Oracle
> 8.1.7.4
>
>
> Carmen,
>
> SHMMAX determines the largest size a single shared memory segment can =
> =3D
> be. It does NOT govern the total amount of shared memory that can be =
> =3D
> allocated, just the max allowable size of a single chunk.
>
> The value you show, 4,294,967,295 (shown w/ commas to demonstrate it's =
> =3D
> 4GB-1, not 400MB) is fine. In a 32 bit
> environment, 4GB is the largest amount of memory that a program can =3D
> address, since 2^32=3D3D4GB.
>
> So, if your Oracle installation is 32-bit code, that value is more than =
> =3D
> enough. Even if it was 64-bit code, and you specified an SGA larger =3D
> than 4GB, having SHMMAX set to 4,294,967,295 would not harm you. You =
> =3D
> would just see that your SGA was made up of multiple shared memory =3D
> segments. (Do 'ipcs -m' on Solaris to see all the shared memory =3D
> segments.) Note that there has been a vicious rumor that Solaris must =
> =3D
> have your entire SGA in a single shared memory segment, if ISM (Intimate =
> =3D
> Shared Memory) would be disabled. This is NOT TRUE. There is no harm =
> =3D
> in having your SGA in multiple shared memory segments.
>
> Bottom line, you should go ahead with:
> set shmsys:shminfo_shmmax=3D3D4294967295
>
> and forget about it. You'll be fine, and it won't cause you any =3D
> problems.
>
> -Mark
>
> -----Original Message-----
> From: Carmen Rusu [mailto:carmen.rusu_at_rrc.state.tx.us]
> Sent: Friday, February 13, 2004 9:57 AM
> To: mgogala_at_adelphia.net; oracle-l_at_freelists.org
> Subject: Re: SHMMAX setting with multiple instances? Solaris 2.8,Oracle
> 8.1.7.4
>
>
> Here's from Sun Tech support. Does it make any sense to you? To me, it
> doesnt :-(
>
>
> > customer. I wouldset=3D20
> > shmmax=3D3DTHE_HIGHEST_NUMBER_OF_BYTES_TO_BE_USED_BY_THE_SGA+ some =
> extra
>
> > head room.
> >=3D20
>
> Carmen Rusu
>
> >>> mgogala_at_adelphia.net 2/13/2004 7:31:05 AM >>>
>
> On 02/13/2004 08:17:14 AM, Carmen Rusu wrote:
> > Oracle install guide recommends the minimum value
> >=3D20
> > set shmsys:shminfo_shmmax=3D3D4294967295
> >=3D20
> > How does this number depend on the the available physical RAM on the
> > box?
> >=3D20
> > Does this number depend on the number of instances on the box ?
> >=3D20
> > Did you experiment with this setting? Horror stories?
> >=3D20
> > Thanks,
> >=3D20
> > Carmen Rusu
> >
>
> Carmen, the number in question is 400MB and it is the maximum
> size of a shared memory segment on Slowaris. It also represents
> the largest SGA that oracle can construct in a single piece.
> It doesn't have any direct impact on your RAM unless you really =3D20
> allocate the SGA.
>
> --=3D20
> Mladen Gogala
> Oracle DBA
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request_at_freelists.org=3D20
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/=3D20
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html=3D20
> -----------------------------------------------------------------
> ----------------------------------------------------------------
> 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
> -----------------------------------------------------------------
> ----------------------------------------------------------------
> 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
> -----------------------------------------------------------------
-- 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 Tue Feb 17 2004 - 03:08:14 CST
 |
 |