8000 char Row limit

is the 8000 char row limit only an issue in standard
edition? If I upgrade to enterprise edition will I not
have this problem? Thanks.
It has nothing to do with the edition; it is a storage / engine limitation.
What exactly are you trying to do? Are you aware of the reasons for the
limit?
Aaron Bertrand
SQL Server MVP
http://www.aspfaq.com/
"Billy Dodson" <billy@.pmicromart.com> wrote in message
news:1b64b01c420a7$4331a210$a301280a@.phx.gbl...
> is the 8000 char row limit only an issue in standard
> edition? If I upgrade to enterprise edition will I not
> have this problem? Thanks.
|||The actual row limit is 8060, and the max char/varchar column size is 8000
bytes.
"Billy Dodson" <billy@.pmicromart.com> wrote in message
news:1b64b01c420a7$4331a210$a301280a@.phx.gbl...
> is the 8000 char row limit only an issue in standard
> edition? If I upgrade to enterprise edition will I not
> have this problem? Thanks.
|||This sql server is running our Microsoft CRM database. I
am trying to create some custom attributes. When I try to
create one it says that I am at the 8000 char row limit.
I can not delete any attributes. Is there not a way
around this? Thanks for your replys.

>--Original Message--
>It has nothing to do with the edition; it is a storage /
engine limitation.
>What exactly are you trying to do? Are you aware of the
reasons for the
>limit?
>--
>Aaron Bertrand
>SQL Server MVP
>http://www.aspfaq.com/
>
>
>"Billy Dodson" <billy@.pmicromart.com> wrote in message
>news:1b64b01c420a7$4331a210$a301280a@.phx.gbl...
>
>.
>
|||Is there any way around the 8000 byte limit?

>--Original Message--
>The actual row limit is 8060, and the max char/varchar
column size is 8000
>bytes.
>"Billy Dodson" <billy@.pmicromart.com> wrote in message
>news:1b64b01c420a7$4331a210$a301280a@.phx.gbl...
>
>.
>
|||The error message is just a warning. You can go ahead and create a table
that is wider, just don't expect to use it all. For example:
CREATE TABLE dbo.blat
(
bar1 VARCHAR(5000),
bar2 VARCHAR(5000)
)
GO
Warning: The table 'blat' has been created but its maximum row size (10025)
exceeds the maximum number of bytes per row (8060). INSERT or UPDATE of a
row in this table will fail if the resulting row length exceeds 8060 bytes.
As the message states, the table was still created. However, populating it
with data will be more challenging. These work fine:
INSERT blat SELECT 'a', 'b'
INSERT blat SELECT REPLICATE('a', 5000), 'b'
INSERT blat SELECT 'a', REPLICATE('b', 5000)
But when you try and send more than 8060 bytes, you will have problems, e.g.
INSERT blat SELECT
REPLICATE('a', 5000), REPLICATE('b', 5000)
You get:
Server: Msg 511, Level 16, State 1, Line 1
Cannot create a row of size 10013 which is greater than the allowable
maximum of 8060.
The statement has been terminated.
What I recommend is storing any larger attributes in a separate table and
use relationships for data integrity.
Maybe you can show the code that represents "when I try to create one" and
the ACTUAL error message you receive, not your casual interpretation...
Aaron Bertrand
SQL Server MVP
http://www.aspfaq.com/
"billy dodson" <billy@.pmicromart.com> wrote in message
news:189ae01c420b2$c7d24410$a601280a@.phx.gbl...
> This sql server is running our Microsoft CRM database. I
> am trying to create some custom attributes. When I try to
> create one it says that I am at the 8000 char row limit.
> I can not delete any attributes. Is there not a way
> around this? Thanks for your replys.
|||I am not trying to manually create this table. The table
is created upon the installation of CRM and I am trying to
add an attribute to it within microsoft CRM. In CRM i get
the following error:
An error occurred during the addition of the new field.
The addition failed. For more information, see the event
log.
Event log error:
1.
dmLog: Failed to add new Picklist attribute (CFPcatagory)
to Account entity.
2.
dmLog: New size of the attribute ({53B8A5DA-324C-4926-9F57-
B21C02C1E8C7}) exceeds the SQL Server row limit of 8000
bytes.
I dont know if you are familiar with CRM deployment
manager, there is a section to create mappings, which
might be the same as the relationships as your talking
about. It will not let me modify any existing attribute,
even the ones that I have created. I cant delete an
attribute either.
Thanks again for your help.

>--Original Message--
>The error message is just a warning. You can go ahead
and create a table
>that is wider, just don't expect to use it all. For
example:
>CREATE TABLE dbo.blat
>(
> bar1 VARCHAR(5000),
> bar2 VARCHAR(5000)
>)
>GO
>Warning: The table 'blat' has been created but its
maximum row size (10025)
>exceeds the maximum number of bytes per row (8060).
INSERT or UPDATE of a
>row in this table will fail if the resulting row length
exceeds 8060 bytes.
>As the message states, the table was still created.
However, populating it
>with data will be more challenging. These work fine:
>INSERT blat SELECT 'a', 'b'
>INSERT blat SELECT REPLICATE('a', 5000), 'b'
>INSERT blat SELECT 'a', REPLICATE('b', 5000)
>But when you try and send more than 8060 bytes, you will
have problems, e.g.
>INSERT blat SELECT
> REPLICATE('a', 5000), REPLICATE('b', 5000)
>You get:
>Server: Msg 511, Level 16, State 1, Line 1
>Cannot create a row of size 10013 which is greater than
the allowable
>maximum of 8060.
>The statement has been terminated.
>What I recommend is storing any larger attributes in a
separate table and
>use relationships for data integrity.
>Maybe you can show the code that represents "when I try
to create one" and
>the ACTUAL error message you receive, not your casual
interpretation...
>--
>Aaron Bertrand
>SQL Server MVP
>http://www.aspfaq.com/
>
>
>"billy dodson" <billy@.pmicromart.com> wrote in message
>news:189ae01c420b2$c7d24410$a601280a@.phx.gbl...
I
to
>
>.
>
|||This limitation will be removed in Yukon. You will be able to do the
following (for example):
create table t1 (c1 varchar (5000), c2 varchar (5000))
go
insert into t1 values (replicate ('a', 5000), replicate ('b', 5000))
go
with no problems.
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"billy dodson" <billy@.pmicromart.com> wrote in message
news:189af01c420b2$e74a99f0$a601280a@.phx.gbl...
> Is there any way around the 8000 byte limit?
> column size is 8000
|||Billy,
As stated, it is only a warning. How much of the 8060 char limit is being
used by the unmodified table?
If you have 16 bytes left, you can assign the new attribute to a text or
ntext column, and that will fit. Of course, you then have to deal with the
issues that arise from using text columns.
You can create an attribute table of nothing more than an identity or guid
column and the attribute and then just store the identity (4 bytes) or
rowguid (16 bytes) in your table.
You might also run statistics on the actual size of data being stored vs the
field size for all fields in the table. Knowing this will give you an idea
of how much space you can "safely" assign to the new attribute. The caveat
here is that you will have to check the length of everything on inserts and
updates.
Regards,
John
"billy dodson" <billy@.pmicromart.com> wrote in message
news:189af01c420b2$e74a99f0$a601280a@.phx.gbl...[color=darkblue]
> Is there any way around the 8000 byte limit?
> column size is 8000
|||sounds like one for the CRM group if there is one - being unable to remove
user-defined attributes sounds like a design flaw
Niall Litchfield
Oracle DBA
Audit Commission UK
http://www.niall.litchfield.dial.pipex.com/
<anonymous@.discussions.microsoft.com> wrote in message
news:1bad601c420b8$297548c0$a101280a@.phx.gbl...[vbcol=seagreen]
> I am not trying to manually create this table. The table
> is created upon the installation of CRM and I am trying to
> add an attribute to it within microsoft CRM. In CRM i get
> the following error:
> An error occurred during the addition of the new field.
> The addition failed. For more information, see the event
> log.
> Event log error:
> 1.
> dmLog: Failed to add new Picklist attribute (CFPcatagory)
> to Account entity.
> 2.
> dmLog: New size of the attribute ({53B8A5DA-324C-4926-9F57-
> B21C02C1E8C7}) exceeds the SQL Server row limit of 8000
> bytes.
>
> I dont know if you are familiar with CRM deployment
> manager, there is a section to create mappings, which
> might be the same as the relationships as your talking
> about. It will not let me modify any existing attribute,
> even the ones that I have created. I cant delete an
> attribute either.
> Thanks again for your help.
>
> and create a table
> example:
> maximum row size (10025)
> INSERT or UPDATE of a
> exceeds 8060 bytes.
> However, populating it
> have problems, e.g.
> the allowable
> separate table and
> to create one" and
> interpretation...
> I
> to

8000 char Row limit

is the 8000 char row limit only an issue in standard
edition? If I upgrade to enterprise edition will I not
have this problem? Thanks.It has nothing to do with the edition; it is a storage / engine limitation.
What exactly are you trying to do? Are you aware of the reasons for the
limit?
Aaron Bertrand
SQL Server MVP
http://www.aspfaq.com/
"Billy Dodson" <billy@.pmicromart.com> wrote in message
news:1b64b01c420a7$4331a210$a301280a@.phx
.gbl...
> is the 8000 char row limit only an issue in standard
> edition? If I upgrade to enterprise edition will I not
> have this problem? Thanks.|||The actual row limit is 8060, and the max char/varchar column size is 8000
bytes.
"Billy Dodson" <billy@.pmicromart.com> wrote in message
news:1b64b01c420a7$4331a210$a301280a@.phx
.gbl...
> is the 8000 char row limit only an issue in standard
> edition? If I upgrade to enterprise edition will I not
> have this problem? Thanks.|||This sql server is running our Microsoft CRM database. I
am trying to create some custom attributes. When I try to
create one it says that I am at the 8000 char row limit.
I can not delete any attributes. Is there not a way
around this? Thanks for your replys.

>--Original Message--
>It has nothing to do with the edition; it is a storage /
engine limitation.
>What exactly are you trying to do? Are you aware of the
reasons for the
>limit?
>--
>Aaron Bertrand
>SQL Server MVP
>http://www.aspfaq.com/
>
>
>"Billy Dodson" <billy@.pmicromart.com> wrote in message
> news:1b64b01c420a7$4331a210$a301280a@.phx
.gbl...
>
>.
>|||Is there any way around the 8000 byte limit?

>--Original Message--
>The actual row limit is 8060, and the max char/varchar
column size is 8000
>bytes.
>"Billy Dodson" <billy@.pmicromart.com> wrote in message
> news:1b64b01c420a7$4331a210$a301280a@.phx
.gbl...
>
>.
>|||The error message is just a warning. You can go ahead and create a table
that is wider, just don't expect to use it all. For example:
CREATE TABLE dbo.blat
(
bar1 VARCHAR(5000),
bar2 VARCHAR(5000)
)
GO
Warning: The table 'blat' has been created but its maximum row size (10025)
exceeds the maximum number of bytes per row (8060). INSERT or UPDATE of a
row in this table will fail if the resulting row length exceeds 8060 bytes.
As the message states, the table was still created. However, populating it
with data will be more challenging. These work fine:
INSERT blat SELECT 'a', 'b'
INSERT blat SELECT REPLICATE('a', 5000), 'b'
INSERT blat SELECT 'a', REPLICATE('b', 5000)
But when you try and send more than 8060 bytes, you will have problems, e.g.
INSERT blat SELECT
REPLICATE('a', 5000), REPLICATE('b', 5000)
You get:
Server: Msg 511, Level 16, State 1, Line 1
Cannot create a row of size 10013 which is greater than the allowable
maximum of 8060.
The statement has been terminated.
What I recommend is storing any larger attributes in a separate table and
use relationships for data integrity.
Maybe you can show the code that represents "when I try to create one" and
the ACTUAL error message you receive, not your casual interpretation...
Aaron Bertrand
SQL Server MVP
http://www.aspfaq.com/
"billy dodson" <billy@.pmicromart.com> wrote in message
news:189ae01c420b2$c7d24410$a601280a@.phx
.gbl...
> This sql server is running our Microsoft CRM database. I
> am trying to create some custom attributes. When I try to
> create one it says that I am at the 8000 char row limit.
> I can not delete any attributes. Is there not a way
> around this? Thanks for your replys.|||I am not trying to manually create this table. The table
is created upon the installation of CRM and I am trying to
add an attribute to it within microsoft CRM. In CRM i get
the following error:
An error occurred during the addition of the new field.
The addition failed. For more information, see the event
log.
Event log error:
1.
dmLog: Failed to add new Picklist attribute (CFPcatagory)
to Account entity.
2.
dmLog: New size of the attribute ({53B8A5DA-324C-4926-9F57-
B21C02C1E8C7}) exceeds the SQL Server row limit of 8000
bytes.
I dont know if you are familiar with CRM deployment
manager, there is a section to create mappings, which
might be the same as the relationships as your talking
about. It will not let me modify any existing attribute,
even the ones that I have created. I cant delete an
attribute either.
Thanks again for your help.

>--Original Message--
>The error message is just a warning. You can go ahead
and create a table
>that is wider, just don't expect to use it all. For
example:
>CREATE TABLE dbo.blat
>(
> bar1 VARCHAR(5000),
> bar2 VARCHAR(5000)
> )
>GO
>Warning: The table 'blat' has been created but its
maximum row size (10025)
>exceeds the maximum number of bytes per row (8060).
INSERT or UPDATE of a
>row in this table will fail if the resulting row length
exceeds 8060 bytes.
>As the message states, the table was still created.
However, populating it
>with data will be more challenging. These work fine:
>INSERT blat SELECT 'a', 'b'
>INSERT blat SELECT REPLICATE('a', 5000), 'b'
>INSERT blat SELECT 'a', REPLICATE('b', 5000)
>But when you try and send more than 8060 bytes, you will
have problems, e.g.
>INSERT blat SELECT
> REPLICATE('a', 5000), REPLICATE('b', 5000)
>You get:
>Server: Msg 511, Level 16, State 1, Line 1
>Cannot create a row of size 10013 which is greater than
the allowable
>maximum of 8060.
>The statement has been terminated.
>What I recommend is storing any larger attributes in a
separate table and
>use relationships for data integrity.
>Maybe you can show the code that represents "when I try
to create one" and
>the ACTUAL error message you receive, not your casual
interpretation...
>--
>Aaron Bertrand
>SQL Server MVP
>http://www.aspfaq.com/
>
>
>"billy dodson" <billy@.pmicromart.com> wrote in message
> news:189ae01c420b2$c7d24410$a601280a@.phx
.gbl...
I
to
>
>.
>|||This limitation will be removed in Yukon. You will be able to do the
following (for example):
create table t1 (c1 varchar (5000), c2 varchar (5000))
go
insert into t1 values (replicate ('a', 5000), replicate ('b', 5000))
go
with no problems.
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"billy dodson" <billy@.pmicromart.com> wrote in message
news:189af01c420b2$e74a99f0$a601280a@.phx
.gbl...
> Is there any way around the 8000 byte limit?
>
> column size is 8000|||Billy,
As stated, it is only a warning. How much of the 8060 char limit is being
used by the unmodified table?
If you have 16 bytes left, you can assign the new attribute to a text or
ntext column, and that will fit. Of course, you then have to deal with the
issues that arise from using text columns.
You can create an attribute table of nothing more than an identity or guid
column and the attribute and then just store the identity (4 bytes) or
rowguid (16 bytes) in your table.
You might also run statistics on the actual size of data being stored vs the
field size for all fields in the table. Knowing this will give you an idea
of how much space you can "safely" assign to the new attribute. The caveat
here is that you will have to check the length of everything on inserts and
updates.
Regards,
John
"billy dodson" <billy@.pmicromart.com> wrote in message
news:189af01c420b2$e74a99f0$a601280a@.phx
.gbl...
> Is there any way around the 8000 byte limit?
>
> column size is 8000|||sounds like one for the CRM group if there is one - being unable to remove
user-defined attributes sounds like a design flaw
Niall Litchfield
Oracle DBA
Audit Commission UK
http://www.niall.litchfield.dial.pipex.com/
<anonymous@.discussions.microsoft.com> wrote in message
news:1bad601c420b8$297548c0$a101280a@.phx
.gbl...
> I am not trying to manually create this table. The table
> is created upon the installation of CRM and I am trying to
> add an attribute to it within microsoft CRM. In CRM i get
> the following error:
> An error occurred during the addition of the new field.
> The addition failed. For more information, see the event
> log.
> Event log error:
> 1.
> dmLog: Failed to add new Picklist attribute (CFPcatagory)
> to Account entity.
> 2.
> dmLog: New size of the attribute ({53B8A5DA-324C-4926-9F57-
> B21C02C1E8C7}) exceeds the SQL Server row limit of 8000
> bytes.
>
> I dont know if you are familiar with CRM deployment
> manager, there is a section to create mappings, which
> might be the same as the relationships as your talking
> about. It will not let me modify any existing attribute,
> even the ones that I have created. I cant delete an
> attribute either.
> Thanks again for your help.
>
> and create a table
> example:
> maximum row size (10025)
> INSERT or UPDATE of a
> exceeds 8060 bytes.
> However, populating it
> have problems, e.g.
> the allowable
> separate table and
> to create one" and
> interpretation...
> I
> to

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/default...b;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.
>

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.
>