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: Memory Limit Imposed on Oracle by Windows?

Re: Memory Limit Imposed on Oracle by Windows?

From: BD <robert.drea_at_gmail.com>
Date: 18 Apr 2007 19:59:25 -0700
Message-ID: <1176951565.304410.137820@q75g2000hsh.googlegroups.com>


On Apr 18, 7:13 pm, "Dereck L. Dietz" <diet..._at_ameritech.net> wrote:
> "BD" <robert.d..._at_gmail.com> wrote in message
>
> news:1176947912.694445.148860_at_y5g2000hsa.googlegroups.com...
>
>
>
> > > could be 4GB or so. Is that true or is Oracle able to use as much of
> the
> > > available memory on the server as it is set up to use?
>
> > The following applies to 32-bit Windows only.
>
> > By default (without specific OS switches enabled), Windows is only
> > able to directly 'see' (ie allow programs to access) 4GB. Anything
> > above that is accessed via smoke and mirrors, similar to EMS/XMS in
> > the DOS days. Virtual address spaces, yada yada yada.
>
> > In fact, it is less - because the OS kernel must exist in the same
> > 'base' region of memory. By default, Windows only allows programs
> > direct access to *2* GB of RAM.
>
> > This means that *all* Oracle instances must share that 2GB.
>
> > There are two ways to address this - both involve OS switches, and one
> > involves specific Oracle config changes.
>
> > 1) The '/3GB' switch. Adding this switch to your boot.ini will cause
> > the OS kernel to live in less memory (1GB), and allow programs direct
> > access to 3GB of memory. This can obviously help, but may impose
> > limitations on the OS side.
>
> > 2) The '/PAE' switch. Adding this switch to your boot.ini will steal a
> > small amount of base memory, which will then be converted into a
> > 'mapping area' to the vast regions of memory above 4GB. It basically
> > creates an extended address space (the acronym stands for Physical
> > Address Extensions), and it lets Oracle use memory above the 4GB cap.
>
> > ***however - you are limited to what can go into this upper region of
> > memory - buffer cache only. The PGA, Shared Pool, all other memory
> > areas must still exist in the base region of memory (be it 2 or 3GB).
>
> > As well, you need to enable a parameter in Oracle:
> > 'Use_indirect_data_buffers=TRUE'. This will allow the Oracle process
> > to put the buffer cache up in higher memory. You must also assign a
> > size for the 'mapping area' This parameter is 'AWE_WINDOW_SIZE', I
> > believe.
>
> > You must also change the terminology used in your pfile for the buffer
> > cache size. Not the value, just the name. I forget the specific one
> > there. But it's in the docs.
>
> > One more thing: if you use *both* /3GB and /PAE on the same Windows
> > box, you will *not* be able to see more than 16GB. Ever.
>
> > Many hoops to jump through. I gather that these constraints are not
> > present when using 64-bit Windows, but I don't know for sure.
>
> > I also hear talk of performance issues when using /PAE in some cases.
> > You must also be very aware that when using /3GB, you're forcing the
> > OS kernel into a smaller region of memory.
>
> > BD.
>
> I'm probably restating the obvious but I just want to confirm what you're
> saying: if our system is 64-bit then we shouldn't have the limitations you
> mentioned above?

That's my take. The limitations to 4gb are all based on the 32-bit architecture. 2 to the 32nd power = 4 billion = 4GB. That's the math side of it; the direct memory addressing limitation of a 64-bit architecture is... well, a lot more than 4GB.

Definitely do your own digging into the specs of 32-bit versus 64-bit Windows, *and* 32-bit versus 64-bit Oracle. But I think you'll find that the resourcing under 64-bit is a lot more sizeable, and all the hokey config jazz you have to do under 32-bit Windows won't be needed. Received on Wed Apr 18 2007 - 21:59:25 CDT

Original text of this message

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