Should 64-bit SQL 2005 be considered for most installations vs. 32-bit?
-
Inside Microsoft SQL Server 2005: The Storage Engine, by Kalen Delaney says in Chapter 2...
"Unless you are working only with very small databases and do not expect to need more than a couple of gigabytes of RAM, you should definitely consider running a 64-bit edition of SQL Server 2005"
Do you agree?
I ask because we only have a handlful of 2005 servers with one being 64-bit, but between 50 and 60 SQL 2000 servers on a 32-bit OS. After reading Kalen's advice I'm wondering if I should be converting our 2005 servers to 64-bit and plan on migrating our SQL 2000 32-bit servers to 64-bit 2005.
Also, the vast majority of our applications are vendor packages. Some packages access a shared database server while others have servers dedicated to the vendor's application. When it comes to 64-bit SQL Server, is it necessary to ask the vendor if they support 64-bit SQL Server or should this be irrelevant to an application, provided the database server is dedicated to running SQL Server 2005? The only concern I can think of is if the vendor has not tested how well their application performs on 64-bit SQL 2005, but wouldn't performance either be the same or better then 32-bit. I don't want to over-simplify things.
Thanks, Dave
-
I don't see a major reason to not install 64-bit on any new server at this point. As long as your applications work with it that is. Would I spend the time and money to upgrade a server already running 32 bit? Not unless I need to.
Read around on this board and find out that there are some gotchas with 64-bit though.
-
Thanks. I believe the primary benefit sited by Kalen was the difference in VAS between 32-bit and 64-bit. I'll read around to see what problems people have encountered.
Dave
-
'Consider' is not the same term as 'implement'. In short, unless you have a very small usage, you need to open the question of 32 vs 64.
When dealing with 3rd party software, be very careful. Before making a decision, you need to ask them in a variety of ways whether they recommend one or the other, and whether any of their other customers have reported any issues regarding 64 before you decide to switch to it. And, if there are user groups for the software, check directly with the groups, because they may be more forthcoming than the vendor.
-
I think 64-bit will soon be the norm, so for new installations, upgrades, new servers, etc., I'd look at 64-bit. There are so many limitations with 32-bit, not the least of which is the 4GB limit and with data sizes growing, 64 makes sense.
I wouldn't recommend converting existing servers if they're working. For most businesses, it's an expense with no benefit. IF there are performance issues or you can consolidate, save space, power, etc., then think about it.
However, 64-bit has issues. Drivers can be problematic, be sure development isn't hindered by thunking back to 32-bit or incompatibilities (think .NET and SSIS), etc. Be sure your vendors support it and try to stick with tested solutions from vendors, don't mix and match hardware if you can avoid it.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com -
I agree with Steve. Most of your current high-end servers are already 64bit but most often get installed with a 32bit OS and subsequent software.
When we upgraded we looked at every application (web, fat client,...) that hits the server or is used on the server (backup, data compare tools,...) and made sure they were able to be used in a 64bit environment and made sure it would be helpful. Most ran under WOW32 mode so we were good to convert--we only had one application that would run but we were able to find a replacement that worked even better.
Upon converting we had a few bumps (mostly with memory configuration and contention) but the performance boost has been incredible.
-
Thanks everyone. I'm not too concerned about the other applications that run on our database servers. We try to keep the database servers dedicated to SQL Server, with the exception of anti-virus, backup software, security software (CSA), etc... All of our standard server software works with a 64-bit OS. Im a bit unclear as to how database applications would be impacted, outside of performance issues related to memory management differences with a 64-bit OS. As with any upgrade, thorough testing would be a requirement.
Thanks, Dave
-
you have to test
we have an old version of weblogic and testing their XA driver for that version with 64 bit SQL. there is nothing major, but there could be a bug in the 64 bit that isn't there on the 32 bit that can cause problems.
otherwise if you are buying new hardware and you have windows 2003 licenses or you are going to buy new licenses then you might as well go 64 bit since there is no extra cost over 32 bit and a lot more benefits
-
Hate to throw this out but has anyone else taken into consideration the fact that SQL 2008 pretty much requires 64-bit?
As for reasons to choose 64-bit:
(1) Memory, memory, memory, no more AWE/3GB, etc.
(2) CPU performance.
Reasons not to choose 64-bit:
(1) Extended stored procedures = will require rewrite/compile, good luck with that as one of the common c++ libraries no longer works with SQL 2005.
(2) 32 bit drivers/context outside of the core database engine. SQL 2005 itself runs 64-bit, SSIS, etc. do/may not. Figuring out whether you're 64/32 bit at any given time (e.g. SSIS) can be a bear.
Joe
-
Joe,
Can you elaborate on your recompile comment? I have one 64-bit server running SQL 2005 and we didn't do anything special during the installation. That's not to say things won't start breaking as testing continues. Do you have a KB article for either point?
Thanks, Dave
-
Dave -
In our case we had a lot of issues with custom extended stored procedures (e.g. c++ applications) that had been written to interact with 32-bit SQL Server 2000 via ODS. In order to get all of these to work on X64 AMD machines we had to recompile all of them once we found the necessary libraries, etc.
Joe
-
It makes little point to stay with 32bit, it's old technology. However if you have vendor apps then you'll probably need to kick them hard to upgrade to 64bit - I find it tricky enought to get vendors to upgrade their apps to sql 2005.
For consolidation then 64 bit with dual ( or quad ) cores makes a lot of sense as you can get most of what data centre offerred for sql 2000. e.g. an 8 way quad core with 128gb of ram gives you a lot of options for allocating dedicated resource to a multi instance server - or you could use virtual server of course.
32 bit dll's should work, but it would be best to recompile to 64bit, we had to do this when we went from 16 to 32 bit all those years ago.
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/ -
I've seen mention that 64 bit SQL Server 2005 doesn't always work well with linked SQL Server 2000 machines.
Can anyone confirm that?
-
There is a small script that you would need to run on the SQL 2000 server to allow a remote call from SQL 2005. Calling SQL 2005 from SQL 2000 is no problem.
http://support.microsoft.com/default.aspx?scid=kb;en-us;906954
Regards,
Rubes
Accepting all invitesViewing 14 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply