Thursday, February 9, 2012

3GB RAM in a server

Hello
We've got a Windows 2003 server with 3GB RAM in it and SQL 2000 Standard
Edition installed. Am I right in saying that this gives 2GB for SQL to use
and then the other 1GB for the OS etc. ?
Thanks.SQL Server 2000 Std Ed can use up to 2GB. It doesn't have to, though.
Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinpub.com
.
"Kate Smith" <ksmith2000@.yahoo.com> wrote in message
news:OaGP$D5ZFHA.612@.TK2MSFTNGP12.phx.gbl...
Hello
We've got a Windows 2003 server with 3GB RAM in it and SQL 2000 Standard
Edition installed. Am I right in saying that this gives 2GB for SQL to use
and then the other 1GB for the OS etc. ?
Thanks.|||You can use over 2GB if you upgrade to SQL 2000 Enterprise.|||Yes and no. Each application, PID, maps memory into a 4 GB Virtual Address
Space. By default, this is split 2 GB/2 GB between Kernel Mode (Private)
and User Mode (Public) addresses.
Now, all of your applications currently running plus the OS must map
execution contexts within the Virtual Space between physically backed
memory, RAM, and the swap file(s), PAGEFILE.SYS.
Here's the problem: SQL Server is more efficient, as would any other
application, if all of its Virtual Space were backed by physical memory,
which is what it likes to do and is reluctant to give it up once required.
This, among other reasons, is why it is a good idea to dedicate a SERVER,
not a workstation, and DEDICATED, exclusively for SQL Server's usage.
Now, let's say that SQL Server has acquired its max default of 1.7 GBI can
follow up on why if you wish, but let's delay that for now. This leaves
only 1.3 GB to the OS and other application processes. However, the OS will
usually load low in physical memory...because it is the first thing to
start, and SS will load up the remaindertalking physical memory here,
rememeber each process has up to a 4 GB Virtual Space.
This means that most of that 1.3 GB of free physical memory is high-order,
in the second 2 GB chunk. The lower 0.3 GB is most likely used by the OS;
so, all other applications and processes must make use of the "extra" 1 GB
but addressed higher than 2 GB, that is, the last in the physical address
space. Some applicaitons have trouble with this: MSXML2, for example, is
one of these. Now, either SQL Server will have to page out to free up
memory in the lower 2 GB region, which is unlikely, or other applications
and processes can begin to fail.
Here's a solution, if you are on Win2K3, the you can use the /3GB boot.ini
startup parameter regardless of edition. If you are running Win2K, then
only AS and DS are supported for this parameter.
What this does is change the default Private/Public Virtual Address scheme
to 1 GB/3 GB instead of the 2/2 default. Since SQL Server has been coded to
use much more memory than this, it has no problem using the higher memory
area. So, with a little foresight, you can get SQL Server's Buffer Pool to
allocate 2 GB but in the LAST physical memory segment. This will leave the
lower 1 GB for the OS, other processes and applicaitons, and other external
to the BPool memory SQL Server allocations.
Hope this helps.
Sincerely,
Anthony Thomas
"Kate Smith" <ksmith2000@.yahoo.com> wrote in message
news:OaGP$D5ZFHA.612@.TK2MSFTNGP12.phx.gbl...
Hello
We've got a Windows 2003 server with 3GB RAM in it and SQL 2000 Standard
Edition installed. Am I right in saying that this gives 2GB for SQL to use
and then the other 1GB for the OS etc. ?
Thanks.|||The SQL server will only used the maximum amount of memory it needs,and no
more and this may be equal to or less than 2 GB|||Hi,
Since it is SQL Server standard you can leave the memory dynamic. So as
memory will be dynamically allocated and the allocation will
not go more than 2 GB RAM, beng standard edition can support a max of 2 GB
RAM only. Incase if you face any any memory bottle neck probably you
could increase the RAM and change it to Enterprise edition of SQL server and
enable AWE. AWE will allow SQL server to utilize more than 4 GB of RAM.
Thanks
Hari
SQL Server MVP
"Kate Smith" <ksmith2000@.yahoo.com> wrote in message
news:OaGP$D5ZFHA.612@.TK2MSFTNGP12.phx.gbl...
> Hello
> We've got a Windows 2003 server with 3GB RAM in it and SQL 2000 Standard
> Edition installed. Am I right in saying that this gives 2GB for SQL to use
> and then the other 1GB for the OS etc. ?
> Thanks.
>|||I think this info can help you:
http://support.microsoft.com/defaul...kb;en-us;274750
Lionel Chacon
"Kate Smith" wrote:

> Hello
> We've got a Windows 2003 server with 3GB RAM in it and SQL 2000 Standard
> Edition installed. Am I right in saying that this gives 2GB for SQL to use
> and then the other 1GB for the OS etc. ?
> Thanks.
>
>|||Contrary to my colleagues resplies, it is only the BPool that is limited to
2 GB; however, this is NOT the only memory allocation SQL Server will
acquire. By using the /3GB switch, you can make better use of the higher
memory area (> 2 GB physical) as well as allow SS to allocate up to 3 GB for
the USER Mode space and 1 GB for KERNEL mode space.
But don't take my word for it. Configure it and then monitor it and see
what you get. DBCC MEMORYSTATUS is a great command to let you in on how SS
is partitioning its memory resources.
Sincerely,
Anthony Thomas
"Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
news:OaADtk5ZFHA.796@.TK2MSFTNGP10.phx.gbl...
Yes and no. Each application, PID, maps memory into a 4 GB Virtual Address
Space. By default, this is split 2 GB/2 GB between Kernel Mode (Private)
and User Mode (Public) addresses.
Now, all of your applications currently running plus the OS must map
execution contexts within the Virtual Space between physically backed
memory, RAM, and the swap file(s), PAGEFILE.SYS.
Here's the problem: SQL Server is more efficient, as would any other
application, if all of its Virtual Space were backed by physical memory,
which is what it likes to do and is reluctant to give it up once required.
This, among other reasons, is why it is a good idea to dedicate a SERVER,
not a workstation, and DEDICATED, exclusively for SQL Server's usage.
Now, let's say that SQL Server has acquired its max default of 1.7 GBI can
follow up on why if you wish, but let's delay that for now. This leaves
only 1.3 GB to the OS and other application processes. However, the OS will
usually load low in physical memory...because it is the first thing to
start, and SS will load up the remaindertalking physical memory here,
rememeber each process has up to a 4 GB Virtual Space.
This means that most of that 1.3 GB of free physical memory is high-order,
in the second 2 GB chunk. The lower 0.3 GB is most likely used by the OS;
so, all other applications and processes must make use of the "extra" 1 GB
but addressed higher than 2 GB, that is, the last in the physical address
space. Some applicaitons have trouble with this: MSXML2, for example, is
one of these. Now, either SQL Server will have to page out to free up
memory in the lower 2 GB region, which is unlikely, or other applications
and processes can begin to fail.
Here's a solution, if you are on Win2K3, the you can use the /3GB boot.ini
startup parameter regardless of edition. If you are running Win2K, then
only AS and DS are supported for this parameter.
What this does is change the default Private/Public Virtual Address scheme
to 1 GB/3 GB instead of the 2/2 default. Since SQL Server has been coded to
use much more memory than this, it has no problem using the higher memory
area. So, with a little foresight, you can get SQL Server's Buffer Pool to
allocate 2 GB but in the LAST physical memory segment. This will leave the
lower 1 GB for the OS, other processes and applicaitons, and other external
to the BPool memory SQL Server allocations.
Hope this helps.
Sincerely,
Anthony Thomas
"Kate Smith" <ksmith2000@.yahoo.com> wrote in message
news:OaGP$D5ZFHA.612@.TK2MSFTNGP12.phx.gbl...
Hello
We've got a Windows 2003 server with 3GB RAM in it and SQL 2000 Standard
Edition installed. Am I right in saying that this gives 2GB for SQL to use
and then the other 1GB for the OS etc. ?
Thanks.|||I know Anthony knows this and I am sure he just mistyped but the buffer pool
is the only part of memory that can use ABOVE 2GB. It can use the space
below it as well but all the other parts are limited to 2GB or 3GB with the
/3GB.
Andrew J. Kelly SQL MVP
"Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
news:u$nv9s7ZFHA.3168@.TK2MSFTNGP10.phx.gbl...
> Contrary to my colleagues resplies, it is only the BPool that is limited
> to
> 2 GB; however, this is NOT the only memory allocation SQL Server will
> acquire. By using the /3GB switch, you can make better use of the higher
> memory area (> 2 GB physical) as well as allow SS to allocate up to 3 GB
> for
> the USER Mode space and 1 GB for KERNEL mode space.
> But don't take my word for it. Configure it and then monitor it and see
> what you get. DBCC MEMORYSTATUS is a great command to let you in on how
> SS
> is partitioning its memory resources.
> Sincerely,
>
> Anthony Thomas
>
> --
> "Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
> news:OaADtk5ZFHA.796@.TK2MSFTNGP10.phx.gbl...
> Yes and no. Each application, PID, maps memory into a 4 GB Virtual
> Address
> Space. By default, this is split 2 GB/2 GB between Kernel Mode (Private)
> and User Mode (Public) addresses.
> Now, all of your applications currently running plus the OS must map
> execution contexts within the Virtual Space between physically backed
> memory, RAM, and the swap file(s), PAGEFILE.SYS.
> Here's the problem: SQL Server is more efficient, as would any other
> application, if all of its Virtual Space were backed by physical memory,
> which is what it likes to do and is reluctant to give it up once required.
> This, among other reasons, is why it is a good idea to dedicate a SERVER,
> not a workstation, and DEDICATED, exclusively for SQL Server's usage.
> Now, let's say that SQL Server has acquired its max default of 1.7 GBI
> can
> follow up on why if you wish, but let's delay that for now. This leaves
> only 1.3 GB to the OS and other application processes. However, the OS
> will
> usually load low in physical memory...because it is the first thing to
> start, and SS will load up the remaindertalking physical memory here,
> rememeber each process has up to a 4 GB Virtual Space.
> This means that most of that 1.3 GB of free physical memory is high-order,
> in the second 2 GB chunk. The lower 0.3 GB is most likely used by the OS;
> so, all other applications and processes must make use of the "extra" 1 GB
> but addressed higher than 2 GB, that is, the last in the physical address
> space. Some applicaitons have trouble with this: MSXML2, for example, is
> one of these. Now, either SQL Server will have to page out to free up
> memory in the lower 2 GB region, which is unlikely, or other applications
> and processes can begin to fail.
> Here's a solution, if you are on Win2K3, the you can use the /3GB boot.ini
> startup parameter regardless of edition. If you are running Win2K, then
> only AS and DS are supported for this parameter.
> What this does is change the default Private/Public Virtual Address scheme
> to 1 GB/3 GB instead of the 2/2 default. Since SQL Server has been coded
> to
> use much more memory than this, it has no problem using the higher memory
> area. So, with a little foresight, you can get SQL Server's Buffer Pool
> to
> allocate 2 GB but in the LAST physical memory segment. This will leave
> the
> lower 1 GB for the OS, other processes and applicaitons, and other
> external
> to the BPool memory SQL Server allocations.
> Hope this helps.
> Sincerely,
>
> Anthony Thomas
>
> --
> "Kate Smith" <ksmith2000@.yahoo.com> wrote in message
> news:OaGP$D5ZFHA.612@.TK2MSFTNGP12.phx.gbl...
> Hello
> We've got a Windows 2003 server with 3GB RAM in it and SQL 2000 Standard
> Edition installed. Am I right in saying that this gives 2GB for SQL to use
> and then the other 1GB for the OS etc. ?
> Thanks.
>|||I think I probably was just unclear, but it was implicit. Other allocations
sometimes require the lower 2 GB space. By setting the /3GB switch, you can
move the BPool to the UPPER 2 GB segment, or at least some of it, and allow
the other items access to the memory it can use in the lower regions.
Since even in SS2K SE, the BPool can be up to 2 GB, you need to be able to
allow free lower memory allocations. Another way to control part of this is
by the use of the -g MEMTOLEAVE startup parameter.
Not to mention that it all gets even more complex with Enterprise Edition,
more than 4 GB of RAM, and the use of /PAE and possibly AWE.
If anyone is considering extending their 32-bit platforms in this manner,
take care. I would highly recommend considering the purchase of 64-bit,
IA64, and consider using SQL Server EE 64-bit. A lot of memory
configuration and usage issue disappear once you make the switch. And the
nice thing is, to migrate, cost you NOTHING in SQL Server licenses, only the
upgrade from Standard Edition to Enterprise Edition, but you would have that
regardless if you remained on 32-bit or migrated to 64-bit.
Sincerely,
Anthony Thomas
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:urXcfw8ZFHA.3840@.tk2msftngp13.phx.gbl...
I know Anthony knows this and I am sure he just mistyped but the buffer pool
is the only part of memory that can use ABOVE 2GB. It can use the space
below it as well but all the other parts are limited to 2GB or 3GB with the
/3GB.
Andrew J. Kelly SQL MVP
"Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
news:u$nv9s7ZFHA.3168@.TK2MSFTNGP10.phx.gbl...
> Contrary to my colleagues resplies, it is only the BPool that is limited
> to
> 2 GB; however, this is NOT the only memory allocation SQL Server will
> acquire. By using the /3GB switch, you can make better use of the higher
> memory area (> 2 GB physical) as well as allow SS to allocate up to 3 GB
> for
> the USER Mode space and 1 GB for KERNEL mode space.
> But don't take my word for it. Configure it and then monitor it and see
> what you get. DBCC MEMORYSTATUS is a great command to let you in on how
> SS
> is partitioning its memory resources.
> Sincerely,
>
> Anthony Thomas
>
> --
> "Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
> news:OaADtk5ZFHA.796@.TK2MSFTNGP10.phx.gbl...
> Yes and no. Each application, PID, maps memory into a 4 GB Virtual
> Address
> Space. By default, this is split 2 GB/2 GB between Kernel Mode (Private)
> and User Mode (Public) addresses.
> Now, all of your applications currently running plus the OS must map
> execution contexts within the Virtual Space between physically backed
> memory, RAM, and the swap file(s), PAGEFILE.SYS.
> Here's the problem: SQL Server is more efficient, as would any other
> application, if all of its Virtual Space were backed by physical memory,
> which is what it likes to do and is reluctant to give it up once required.
> This, among other reasons, is why it is a good idea to dedicate a SERVER,
> not a workstation, and DEDICATED, exclusively for SQL Server's usage.
> Now, let's say that SQL Server has acquired its max default of 1.7 GBI
> can
> follow up on why if you wish, but let's delay that for now. This leaves
> only 1.3 GB to the OS and other application processes. However, the OS
> will
> usually load low in physical memory...because it is the first thing to
> start, and SS will load up the remaindertalking physical memory here,
> rememeber each process has up to a 4 GB Virtual Space.
> This means that most of that 1.3 GB of free physical memory is high-order,
> in the second 2 GB chunk. The lower 0.3 GB is most likely used by the OS;
> so, all other applications and processes must make use of the "extra" 1 GB
> but addressed higher than 2 GB, that is, the last in the physical address
> space. Some applicaitons have trouble with this: MSXML2, for example, is
> one of these. Now, either SQL Server will have to page out to free up
> memory in the lower 2 GB region, which is unlikely, or other applications
> and processes can begin to fail.
> Here's a solution, if you are on Win2K3, the you can use the /3GB boot.ini
> startup parameter regardless of edition. If you are running Win2K, then
> only AS and DS are supported for this parameter.
> What this does is change the default Private/Public Virtual Address scheme
> to 1 GB/3 GB instead of the 2/2 default. Since SQL Server has been coded
> to
> use much more memory than this, it has no problem using the higher memory
> area. So, with a little foresight, you can get SQL Server's Buffer Pool
> to
> allocate 2 GB but in the LAST physical memory segment. This will leave
> the
> lower 1 GB for the OS, other processes and applicaitons, and other
> external
> to the BPool memory SQL Server allocations.
> Hope this helps.
> Sincerely,
>
> Anthony Thomas
>
> --
> "Kate Smith" <ksmith2000@.yahoo.com> wrote in message
> news:OaGP$D5ZFHA.612@.TK2MSFTNGP12.phx.gbl...
> Hello
> We've got a Windows 2003 server with 3GB RAM in it and SQL 2000 Standard
> Edition installed. Am I right in saying that this gives 2GB for SQL to use
> and then the other 1GB for the OS etc. ?
> Thanks.
>

No comments:

Post a Comment