32bit SQL 2005 on Windows 2003R2 64bit

Is it possible to run sql 2005 on windows 2003 64? I would like to take
advantage of more than 4gb of memory in a windows 2003r2 server that will be
running sql 2005. As I understand it SQL2005 Standard 32 can be installed
and is supported on a 64bit windows2003 server.
Is this correct?
Although we want to scale to upwards of 8gb of memory in this particular box
down the road, this server will not be taking on enough load to warrant sql
64bit architecture.
You can run 32-bit SQL2005 on Win2003 x64.
Linchi
"Corey_in_Canada" wrote:

> Is it possible to run sql 2005 on windows 2003 64? I would like to take
> advantage of more than 4gb of memory in a windows 2003r2 server that will be
> running sql 2005. As I understand it SQL2005 Standard 32 can be installed
> and is supported on a 64bit windows2003 server.
> Is this correct?
> Although we want to scale to upwards of 8gb of memory in this particular box
> down the road, this server will not be taking on enough load to warrant sql
> 64bit architecture.
>
>
|||No offense, but why in the name of all that is holy are you not running
a 64-bit SQL Server on a 64-bit OS? Your assertion that "this server
will not be taking on enough load..." is nonsense.
If you want to use the 32-bit SQL Server product, install it on a 32-bit
Windows box and use PAE and AWE. While your installation *may* be
supported, I doubt it is a common scenario.
-D
Corey_in_Canada wrote:
> Is it possible to run sql 2005 on windows 2003 64? I would like to take
> advantage of more than 4gb of memory in a windows 2003r2 server that will be
> running sql 2005. As I understand it SQL2005 Standard 32 can be installed
> and is supported on a 64bit windows2003 server.
> Is this correct?
> Although we want to scale to upwards of 8gb of memory in this particular box
> down the road, this server will not be taking on enough load to warrant sql
> 64bit architecture.
>
>
-Dave Markle
http://www.markleconsulting.com/blog
|||I would not dismiss running 32-bit SQL2005 on Win2003 x64 out of hand. There
are cases where this combo may have a performance advantage. See
http://sqlblog.com/blogs/linchi_shea/archive/2007/01/02/32-bit-vs-x64.aspx
for an example.
However, I'd agree that performance is not the only factor in choosing a
platform. SQL2005 x64 on Win2003 x64 has many other advantages such as future
growth potential.
Linchi
"Dave Markle" <"dma[remove_ZZ]ZZrkle" wrote:

> No offense, but why in the name of all that is holy are you not running
> a 64-bit SQL Server on a 64-bit OS? Your assertion that "this server
> will not be taking on enough load..." is nonsense.
> If you want to use the 32-bit SQL Server product, install it on a 32-bit
> Windows box and use PAE and AWE. While your installation *may* be
> supported, I doubt it is a common scenario.
> -D
> Corey_in_Canada wrote:
>
> --
> -Dave Markle
> http://www.markleconsulting.com/blog
>
|||I agree that x64/x64 isn't always the best-performing option. But in
your tests the x86/x64 combination never bests both the x86/x86 and
x64/x64 workloads except for in Table 2, where you get only a 2%
performance increase over x86/x86. That, to me, isn't significant,
especially when you consider that different CPUs (AMD/Core/Xeon P4) and
memory architectures are probably going to be far more significant.
For me, the overriding factor here is to garner the benefits of running
a common configuration that lots and lots of other people use. For
almost everyone, that's going to be either x86/x86, or x64/x64. The
very fact that not a lot of folks run x86/x64 would make it less
attractive from my perspective -- has there been a large community
running this configuration in production scenarios? Is it truly proven?
For me, things as basic as memory allocation shouldn't be configured in
an exotic fashion. Maybe I'm growing too conservative in my old age,
but recent issues such as 899761 don't give me too much confidence about
such things... (http://support.microsoft.com/kb/899761).
-Dave
Linchi Shea wrote:[vbcol=seagreen]
> I would not dismiss running 32-bit SQL2005 on Win2003 x64 out of hand. There
> are cases where this combo may have a performance advantage. See
> http://sqlblog.com/blogs/linchi_shea/archive/2007/01/02/32-bit-vs-x64.aspx
> for an example.
> However, I'd agree that performance is not the only factor in choosing a
> platform. SQL2005 x64 on Win2003 x64 has many other advantages such as future
> growth potential.
> Linchi
> "Dave Markle" <"dma[remove_ZZ]ZZrkle" wrote:
-Dave Markle
http://www.markleconsulting.com/blog
|||Dave;
I don't disagree with you on SQL2005x86/Win2003x86 vs.
SQL2005x86/Win2003x64. And excellent point on preferring a platform that is
widely used. I was strictly commenting on SQL2005x86/Win2003x64 vs.
SQL2005x64/Win2003x64.
Linchi
"Dave Markle" <"dma[remove_ZZ]ZZrkle" wrote:

> I agree that x64/x64 isn't always the best-performing option. But in
> your tests the x86/x64 combination never bests both the x86/x86 and
> x64/x64 workloads except for in Table 2, where you get only a 2%
> performance increase over x86/x86. That, to me, isn't significant,
> especially when you consider that different CPUs (AMD/Core/Xeon P4) and
> memory architectures are probably going to be far more significant.
> For me, the overriding factor here is to garner the benefits of running
> a common configuration that lots and lots of other people use. For
> almost everyone, that's going to be either x86/x86, or x64/x64. The
> very fact that not a lot of folks run x86/x64 would make it less
> attractive from my perspective -- has there been a large community
> running this configuration in production scenarios? Is it truly proven?
> For me, things as basic as memory allocation shouldn't be configured in
> an exotic fashion. Maybe I'm growing too conservative in my old age,
> but recent issues such as 899761 don't give me too much confidence about
> such things... (http://support.microsoft.com/kb/899761).
> -Dave
>
> Linchi Shea wrote:
>
> --
> -Dave Markle
> http://www.markleconsulting.com/blog
>
|||You almost take on a defensive approach from your first response. Firstly,
it should not really be of great concern to you what we choose to do. My
question was simply one that asked whether this scenario was supported.
There *are* reasons and limiting factors as to why one may need to take such
an approach.
Anyways, thanks for the feedback.
"Dave Markle" <"dma[remove_ZZ]ZZrkle"@.gmail.dot.com> wrote in message
news:ecZQCA1RHHA.2256@.TK2MSFTNGP02.phx.gbl...
>I agree that x64/x64 isn't always the best-performing option. But in your
>tests the x86/x64 combination never bests both the x86/x86 and x64/x64
>workloads except for in Table 2, where you get only a 2% performance
>increase over x86/x86. That, to me, isn't significant, especially when you
>consider that different CPUs (AMD/Core/Xeon P4) and memory architectures
>are probably going to be far more significant.
> For me, the overriding factor here is to garner the benefits of running a
> common configuration that lots and lots of other people use. For almost
> everyone, that's going to be either x86/x86, or x64/x64. The very fact
> that not a lot of folks run x86/x64 would make it less attractive from my
> perspective -- has there been a large community running this configuration
> in production scenarios? Is it truly proven?
> For me, things as basic as memory allocation shouldn't be configured in an
> exotic fashion. Maybe I'm growing too conservative in my old age, but
> recent issues such as 899761 don't give me too much confidence about such
> things... (http://support.microsoft.com/kb/899761).
> -Dave
>
> Linchi Shea wrote:
>
> --
> -Dave Markle
> http://www.markleconsulting.com/blog
|||Sorry if you felt like I was jumping down your throat. I had just
finished a day at work "discussing" with a "senior" DBA why it *might*
not be a "best practice" to reboot each of our mission-critical
(non-clustered, mind you) SQL Servers on a nightly schedule. I was sort
of in "kill mode". That and I'd just seen the pictures of the "new"
Tyra, and am still taking it hard. I promise I'm a big teddy bear.
Why shouldn't it concern me, though? That's one of the big reasons why
I am on this board in the first place. I don't want to just answer
people's questions -- I want to point people toward the best solutions
whenever possible.
I also want to talk about issues of preference in a forum with people
who know more than I do. Linchi Shea is one of those people, and I'm
totally stoked that we get to even talk about this stuff. The fact is,
most people really couldn't give a squirt about how databases work, and
this forum is one of the few places we all get to go to read and learn
from one another.
-Dave
Corey_in_Canada wrote:
> You almost take on a defensive approach from your first response. Firstly,
> it should not really be of great concern to you what we choose to do. My
> question was simply one that asked whether this scenario was supported.
> There *are* reasons and limiting factors as to why one may need to take such
> an approach.
> Anyways, thanks for the feedback.
>
> "Dave Markle" <"dma[remove_ZZ]ZZrkle"@.gmail.dot.com> wrote in message
> news:ecZQCA1RHHA.2256@.TK2MSFTNGP02.phx.gbl...
>
-Dave Markle
http://www.markleconsulting.com/blog
|||On Fri, 2 Feb 2007 18:17:01 -0800, Linchi Shea
<LinchiShea@.discussions.microsoft.com> wrote:

>I would not dismiss running 32-bit SQL2005 on Win2003 x64 out of hand. There
>are cases where this combo may have a performance advantage. See
>http://sqlblog.com/blogs/linchi_shea/archive/2007/01/02/32-bit-vs-x64.aspx
>for an example.
>However, I'd agree that performance is not the only factor in choosing a
>platform. SQL2005 x64 on Win2003 x64 has many other advantages such as future
>growth potential.
Outstanding stuff.
Do you have something else that gives the same benchmarks on 32bit
hardware running AWE?
For extra special bonus, if it shows what happens when non-memory
stressed loads run on AWE vs native memory!
Josh
|||yes, It's Posible
ElTriKi
ElTriKi's Profile: http://unixadmintalk.com/1019
View this thread: http://unixadmintalk.com/showthread.php?t=261801