837 patch and MS03-031

Hello
We're about to apply the MS03-031 security rollup patch to upgrade our 90
SQL Servers from SP3a (760) to (818).
Problem is we have applied a hotfix already to a couple of boxes which
ugraded SQL to version (837).
What will happen when we apply MS03-031 to these boxes with the hotfix? Will
it fail and if so whats the solution?
thank you
-- cranfield, DBAHi
It will run, but is clever enough not to run older scripts against the newer
build. It does binary file version checking so it won't overwrite newer
binaries.
Have you considered hotfix 878?
When I tried to run 818 against a 952 server, I got the following:
=== Version check on sqlservr.exe 8.0.952 shows different major build of
sqlservr.exe than hotfix build number 8.00.818
=== NOT RUNNING SCRIPTS
The build number of SQLSERVR.EXE and HotFix package did not match. This
happens
when SQLSERVR.EXE was not replaced because the version was higher than the
Hotfix build.
In these cases Hotfix will not run any scripts and return error code
ERROR_BAD_ENVIRONMENT
Error message: Error running SQL script. Please view the log file for detail
s.
INSTALL FAILURE: Hotfix failed to apply the patches on instance MSSQLSERVER,
the error code returned was: 10
<EndFunc Name='DoSQLHotFix' Return='10' GetLastError='0'>
Regards
Mike
"cranfield" wrote:

> Hello
> We're about to apply the MS03-031 security rollup patch to upgrade our 90
> SQL Servers from SP3a (760) to (818).
> Problem is we have applied a hotfix already to a couple of boxes which
> ugraded SQL to version (837).
> What will happen when we apply MS03-031 to these boxes with the hotfix? Wi
ll
> it fail and if so whats the solution?
> thank you
> -- cranfield, DBA|||Hi Mike
Why do you ask if I have considered hotfix 878? We applied the 837 hotfix i
an attempt to sort out some Exception errors we were having on our 4-node
cluster.
We're just looking at bringing up our servers to an accepted level and our
testers have only tested up to 818, MS02-031.
regards
Alan Cranfield
DBA Support
"Mike Epprecht (SQL MVP)" wrote:
[vbcol=seagreen]
> Hi
> It will run, but is clever enough not to run older scripts against the new
er
> build. It does binary file version checking so it won't overwrite newer
> binaries.
> Have you considered hotfix 878?
> When I tried to run 818 against a 952 server, I got the following:
> === Version check on sqlservr.exe 8.0.952 shows different major build of
> sqlservr.exe than hotfix build number 8.00.818
>
> === NOT RUNNING SCRIPTS
> The build number of SQLSERVR.EXE and HotFix package did not match. This
> happens
> when SQLSERVR.EXE was not replaced because the version was higher than the
> Hotfix build.
> In these cases Hotfix will not run any scripts and return error code
> ERROR_BAD_ENVIRONMENT
> Error message: Error running SQL script. Please view the log file for deta
ils.
> INSTALL FAILURE: Hotfix failed to apply the patches on instance MSSQLSERVE
R,
> the error code returned was: 10
> <EndFunc Name='DoSQLHotFix' Return='10' GetLastError='0'>
> Regards
> Mike
> "cranfield" wrote:
>|||Hi
878 is the highest publicly available hotfix, that is fully supported by PSS
.
We encountered quite a few problems with hotfixes in the 820 to 850 range,
and those issues were fixed after 850.
(regression bugs etc)
Regards
Mike
"Cranfield" wrote:
[vbcol=seagreen]
> Hi Mike
> Why do you ask if I have considered hotfix 878? We applied the 837 hotfix
i
> an attempt to sort out some Exception errors we were having on our 4-node
> cluster.
> We're just looking at bringing up our servers to an accepted level and our
> testers have only tested up to 818, MS02-031.
> regards
> Alan Cranfield
> DBA Support
> "Mike Epprecht (SQL MVP)" wrote:
>|||I suspect applying MS03-031 to the servers that are already at
8.00.837 will do nothing - it shouldn't overwrite files with
earlier versions, and you can compare the file information in the KB
article http://support.microsoft.com/kb/821277 with what's on your
servers.
Is there a reason you think MS03-31 contains something that is
not already installed as part of the 837 hotfix on the hotfixed boxes?
Usually these things are cumulative, and especially since 818 was a
security issue, I'd be surprised if MSFT gave out something numbered
8.00.837 that didn't fix prior security issues.
Steve Kass
Drew University
cranfield wrote:

>Hello
>We're about to apply the MS03-031 security rollup patch to upgrade our 90
>SQL Servers from SP3a (760) to (818).
>Problem is we have applied a hotfix already to a couple of boxes which
>ugraded SQL to version (837).
>What will happen when we apply MS03-031 to these boxes with the hotfix? Wil
l
>it fail and if so whats the solution?
>thank you
>-- cranfield, DBA
>|||This is exactly what i want to know. Can I safely assume that I don't have t
o
patch the 837 servers as they will already be up to 818 level?
thanks
alan
"Steve Kass" wrote:

> I suspect applying MS03-031 to the servers that are already at
> 8.00.837 will do nothing - it shouldn't overwrite files with
> earlier versions, and you can compare the file information in the KB
> article http://support.microsoft.com/kb/821277 with what's on your
> servers.
> Is there a reason you think MS03-31 contains something that is
> not already installed as part of the 837 hotfix on the hotfixed boxes?
> Usually these things are cumulative, and especially since 818 was a
> security issue, I'd be surprised if MSFT gave out something numbered
> 8.00.837 that didn't fix prior security issues.
> Steve Kass
> Drew University
> cranfield wrote:
>
>

8.00.0276 still showing within SQL Server 2005

Hello:
We upgraded SQL Server 2000 to SQL Server 2005, last week. No issues arose.
But, when we opened the SQL Server 2005 Management Studio, the phrase
"8.00.0276" appeared next to the name of the SQL Server on the left (above
databases and so forth). That appears to the be the SQL 2000 version number.
Does that mean that the upgrade did not actually happen? I have
documentation on how to upgrade SQL 2000, and we followed it. Isn't it just
a matter of putting in the 2005 CD, telling it what instance to upgrade, and
"doing it"?
Thanks!
childofthe1980s
Seems you are looking at the wrong instance or you didn't do the upgrade of the database engine. You
can connect and execute below, just to be certain:
select @.@.version
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"childofthe1980s" <childofthe1980s@.discussions.microsoft.com> wrote in message
news:234CC08B-B0DA-4653-9D07-4EC2D5E5137A@.microsoft.com...
> Hello:
> We upgraded SQL Server 2000 to SQL Server 2005, last week. No issues arose.
> But, when we opened the SQL Server 2005 Management Studio, the phrase
> "8.00.0276" appeared next to the name of the SQL Server on the left (above
> databases and so forth). That appears to the be the SQL 2000 version number.
> Does that mean that the upgrade did not actually happen? I have
> documentation on how to upgrade SQL 2000, and we followed it. Isn't it just
> a matter of putting in the 2005 CD, telling it what instance to upgrade, and
> "doing it"?
> Thanks!
> childofthe1980s

8.00.0276 still showing within SQL Server 2005

Hello:
We upgraded SQL Server 2000 to SQL Server 2005, last week. No issues arose.
But, when we opened the SQL Server 2005 Management Studio, the phrase
"8.00.0276" appeared next to the name of the SQL Server on the left (above
databases and so forth). That appears to the be the SQL 2000 version number
.
Does that mean that the upgrade did not actually happen? I have
documentation on how to upgrade SQL 2000, and we followed it. Isn't it just
a matter of putting in the 2005 CD, telling it what instance to upgrade, and
"doing it"?
Thanks!
childofthe1980sSeems you are looking at the wrong instance or you didn't do the upgrade of
the database engine. You
can connect and execute below, just to be certain:
select @.@.version
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"childofthe1980s" <childofthe1980s@.discussions.microsoft.com> wrote in messa
ge
news:234CC08B-B0DA-4653-9D07-4EC2D5E5137A@.microsoft.com...
> Hello:
> We upgraded SQL Server 2000 to SQL Server 2005, last week. No issues aros
e.
> But, when we opened the SQL Server 2005 Management Studio, the phrase
> "8.00.0276" appeared next to the name of the SQL Server on the left (above
> databases and so forth). That appears to the be the SQL 2000 version numb
er.
> Does that mean that the upgrade did not actually happen? I have
> documentation on how to upgrade SQL 2000, and we followed it. Isn't it ju
st
> a matter of putting in the 2005 CD, telling it what instance to upgrade, a
nd
> "doing it"?
> Thanks!
> childofthe1980s

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