Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: O 8.0.5 SGA size HPUX 11

Re: O 8.0.5 SGA size HPUX 11

From: Dave Grantier <dave_at_foobar.com>
Date: Sat, 23 Jun 2001 13:27:53 GMT
Message-ID: <3b3497e9.43916628@news.atl.bellsouth.net>

There shouldn't be swapping to disk, because we have 8 gigs of RAM. My question is: if two separate oracle instances are running, wouldn't each one be able to get 1.5 gig SGA? I can understand that a single 32 bit process could be constrained to operate in under 2.1 gig virtual address space.

(btw, "virtual" in this sense means that there is an OS / kernel table which maps virtual memory addresses to physical RAM addresses. It doesn't necessarily imply swapping to disk.)

The part that confuses me is that I have told that you can't have greater than 1.5 gigs of SGA for two SEPARATE oracle instances under HPUX. (They did tell me it would work fine under Solaris, tho).

On Sat, 23 Jun 2001 07:20:45 +0200, "Sybrand Bakker" <postbus_at_sybrandb.demon.nl> wrote:

>
> "Dave Grantier" <dave_at_foobar.com> wrote in message
> news:3b33efb5.856141_at_news.mindspring.com...
> > Greetings.
> > I have been receiving some conflicting information and was hoping
> > someone could shed some light on the issue.
 snip]
>
> Such move would just *force* paging on the O/S side, the operating word here
> being *virtual* memory.
> There's a maximum as to what you can use before the O/S start paging out
> your precious SGA to disk (for all O/Ses the SGA is in *virtual* memory, so
> subject to paging). In the past Oracle advised not to use more than one
> third for SGA memory.
>
> Hth,
>
> Sybrand Bakker, Oracle DBA
>
>
>
>

Dave

+---------------------+---------------+

|nojunkmail_at_nospam.com| bellsouth.net |
|nospam_at_nojunkmail.com| davegrantier@ |
+---------------------+---------------+
Received on Sat Jun 23 2001 - 08:27:53 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US