awe question

We are going to turn on AWE on our production environment currently
its 4 processor box with 12GB of RAM and windows advanced server 2000
loaded on it. Now my question is do i need to use /PAE and /3GB
switches in our boot.ini in order to enable 6gigs to our sql server
or /PAE will okay?kulkarni.ninad@.gmail.com wrote:
> We are going to turn on AWE on our production environment currently
> its 4 processor box with 12GB of RAM and windows advanced server 2000
> loaded on it. Now my question is do i need to use /PAE and /3GB
> switches in our boot.ini in order to enable 6gigs to our sql server
> or /PAE will okay?
>
With 6Gb of RAM, I would use the /3GB switch as well. That would
effectively allow SQL to use as much as 5GB. Without the /3Gb switch
you are pretty well limited to 4Gb.|||That is not really true. /3GB allows SQL Server (or any properly enabled
application) to use up to 3GB of the 4GB of directly addressable memory but
limits the OS to 1GB of that same space. AWE and PAE are to allow the OS and
the App to see memory above 4GB and is totally independent of the /3GB
switch. The decision to use /3GB or not is dependent on how much of that
directly addressable memory you need to use. The only part of SQL Server
that can use memory above 2GB (or 3GB with the /3GB) is the data buffer
cache. I would question why he wants to use only 6GB when he has 12
available. I suspect he may be in a cluster and if that is true and it is
Active-Active then 6GB may be too much since AWE memory is fixed and can not
be dynamically adjusted.
--
Andrew J. Kelly SQL MVP
"Don Peterson" <sgtp.usmc@.gmail.com> wrote in message
news:uEmOq6LbHHA.5044@.TK2MSFTNGP05.phx.gbl...
> kulkarni.ninad@.gmail.com wrote:
>> We are going to turn on AWE on our production environment currently
>> its 4 processor box with 12GB of RAM and windows advanced server 2000
>> loaded on it. Now my question is do i need to use /PAE and /3GB
>> switches in our boot.ini in order to enable 6gigs to our sql server
>> or /PAE will okay?
> With 6Gb of RAM, I would use the /3GB switch as well. That would
> effectively allow SQL to use as much as 5GB. Without the /3Gb switch you
> are pretty well limited to 4Gb.|||Andrew J. Kelly wrote:
> That is not really true. /3GB allows SQL Server (or any properly enabled
> application) to use up to 3GB of the 4GB of directly addressable memory but
> limits the OS to 1GB of that same space. AWE and PAE are to allow the OS and
> the App to see memory above 4GB and is totally independent of the /3GB
> switch. The decision to use /3GB or not is dependent on how much of that
> directly addressable memory you need to use. The only part of SQL Server
> that can use memory above 2GB (or 3GB with the /3GB) is the data buffer
> cache. I would question why he wants to use only 6GB when he has 12
> available. I suspect he may be in a cluster and if that is true and it is
> Active-Active then 6GB may be too much since AWE memory is fixed and can not
> be dynamically adjusted.
>
My thinking was that there was only 6Gb and if you didn't use the /3Gb
switch, then the OS would effectively take the full 2Gb available to it,
leaving 4Gb for applications such as SQL. While using the /3Gb switch
would limit the OS to 1Gb, thereby allowing SQL to use a full 5Gb.
However, now I see that there is actually 12Gb...
With 12Gb you don't need the /3Gb switch in order to allow SQL to see
6Gb (actually it could use 10Gb), however, I have to wonder why you want
to limit SQL to 6Gb when you have 12?
I think my recommendation still stands though, because if I recall, it's
not until you have over 16Gb of RAM that the OS has to use that extra Gb
of space to maintain the Address Extensions.
So, using the /3Gb switch would allow SQL to use up to 11Gb instead of
10Gb without it. Although I'd keep a close eye on things to make sure
that the OS is not having to do a bunch of swapping. In certain
circumstances the OS might be able to make better use of that Gb than SQL.|||> I think my recommendation still stands though, because if I recall, it's
> not until you have over 16Gb of RAM that the OS has to use that extra Gb
> of space to maintain the Address Extensions.
I believe that Unisys has recommendations to not use /3GB if you have > 12GB in the machine.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Don Peterson" <sgtp.usmc@.gmail.com> wrote in message news:uhqohQYbHHA.588@.TK2MSFTNGP06.phx.gbl...
> Andrew J. Kelly wrote:
>> That is not really true. /3GB allows SQL Server (or any properly enabled
>> application) to use up to 3GB of the 4GB of directly addressable memory but
>> limits the OS to 1GB of that same space. AWE and PAE are to allow the OS and
>> the App to see memory above 4GB and is totally independent of the /3GB
>> switch. The decision to use /3GB or not is dependent on how much of that
>> directly addressable memory you need to use. The only part of SQL Server
>> that can use memory above 2GB (or 3GB with the /3GB) is the data buffer
>> cache. I would question why he wants to use only 6GB when he has 12
>> available. I suspect he may be in a cluster and if that is true and it is
>> Active-Active then 6GB may be too much since AWE memory is fixed and can not
>> be dynamically adjusted.
> My thinking was that there was only 6Gb and if you didn't use the /3Gb
> switch, then the OS would effectively take the full 2Gb available to it,
> leaving 4Gb for applications such as SQL. While using the /3Gb switch
> would limit the OS to 1Gb, thereby allowing SQL to use a full 5Gb.
> However, now I see that there is actually 12Gb...
> With 12Gb you don't need the /3Gb switch in order to allow SQL to see
> 6Gb (actually it could use 10Gb), however, I have to wonder why you want
> to limit SQL to 6Gb when you have 12?
> I think my recommendation still stands though, because if I recall, it's
> not until you have over 16Gb of RAM that the OS has to use that extra Gb
> of space to maintain the Address Extensions.
> So, using the /3Gb switch would allow SQL to use up to 11Gb instead of
> 10Gb without it. Although I'd keep a close eye on things to make sure
> that the OS is not having to do a bunch of swapping. In certain
> circumstances the OS might be able to make better use of that Gb than SQL.