January 26, 2011 at 8:11 am
reaching out to the community to get opinions on a sort of dilema that I am in..
wanted to know if anyone out there could offer their expert opinion about the drawbacks of running 32bit sql server on 64 bit machines.
a little background...
we have a mix of SQL Server 2000 and SQL Server 2005 instances on multiple servers across our network. most of these servers are older servers running windows2000.
We have purchased new 64bit Servers running WINDOWS 2008R2 and are in the midst of a migration project - moving all (or at least most) of the SQL Server Server databases to these new servers.
I have installed sql server 2005 64bit standard edition Instances on both of the new Servers and staged most of my databases.
I am running to a problem because some of our software vendors are coming back and saying that they are certified for (or compatible with) SQL Server 2005 32bit but are NOT certified for or compatible with SQL Server 2005 64bit. But yet they cannot give me any technical reasons why they could run against SQL Server 2005 32bit and NOT SQL Server 2005 64 bit..
I have a couple of options.. Stay with my 64bit SQL Server Instances on the new boxes and convince them that 32bit SQL Server vs 64 bit SQL Server won't make a difference to their application .. or ... rebuild my two new boxes as 32 bit SQL Server Instances. The only drawback to the second option is that I would not be able to take advantage of being able to configure the individual instances with additional memory as needed... not to mention all of the work involved in rebuilding and reconfiguring the instances..
any thoughts?????
January 26, 2011 at 10:05 am
There's only a few things that would make a difference, and those mostly go to drivers. Linked servers/OpenRowset/SSIS may have issues.
With less-and-less reason to NOT use 64-bit, those vendors need to be getting their products certified for it. Put pressure on them - and let it slip that their competitor is 64-bit certified (if they are), and you're not beyond switching if their product won't work on modern systems.
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
January 26, 2011 at 10:39 am
Along with what Wayne said vendors that use extended stored procedures can have problems, most do not do that. For applications that operate fully within a single database and don't reach into other systems and don't use SSIS the rationale against 64-bit is all but GONE. One final thought is SQLCLR, this tends to be 32/64 agnostic but NOT ALWAYS.
I would squeeze them as to WHY they aren't certified for 64-bit, just saying they aren't is no longer sufficient in 2011 where 64-bit servers are basically the standard and hardware that only runs 32-bit is falling out of use. What technology are they using that is preventing the move?
Before I installed a 32-bit instance I'd have to have a pretty good reason, vendor lazyness is not what I would call compelling..
CEWII
January 31, 2011 at 7:31 am
Any thoughts on mixing the instances? in other words, uninstall one of my named instances and reinstall it using the SQL Server 2005 32bit software and leaving the Default and other named Instances as 64bit SQL server installs???
The thought of having to reinstall ALL of these Instances because we have one Vendor who will not support us on SQL Server 2005 64bit is not very appealing to me!
January 31, 2011 at 12:14 pm
I have seen this in practice and it should be ok. Only do the ones you need though..
CEWII
February 1, 2011 at 7:13 am
I will add that you can use extra memory on 32 bit systems with /PAE and AWE in SQL Server 2005+
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
February 1, 2011 at 7:17 am
Thank you so much for your replies. my only real concern is mixing 32bit and 64bit instances on the same box. Sounds like it can be down without risk - i will jsut have to be mindfull of this when patching the instances. Thanks again
February 1, 2011 at 8:49 am
Actually I would be more interested in why you are mixing together so many instances rather than the 32/64 bit mix debate. I find that people use instances far to frequently and get little to no benefit and suffer downsides of poor memory utilization.
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
February 1, 2011 at 8:57 am
we are in the midst of retiring an older server (32bit) to a new Server (64bit)
We have one application (for our legal department) that has it's own instance because they require a custom server collation. in addition we have a default instance and 2 other named instances. The new server has been built and it ready to go.
Now the Vendor for the legal App is saying they will not support us on 64bit unless we upgrade their app - but the upgrade will not be available until around 3rd quarter this year. I cannot wait to get off the old server until 3rd quarter so I either have to revert all instances back to 32bit on the new server and have all the business units retest or leave all 64bit and just reinstall the one instance for legal as a 32bit instance.. then after 3rd quarter I can migrate them to a 64bit instance.
February 1, 2011 at 10:10 am
I completely understand the need for a 32bit special-collation instance. But why do you need three 64 bit instances?
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
February 1, 2011 at 10:23 am
we had fully intended on making it a true 64 bit installation. did all of the installs and scheduled application testing.. most of which is completed - except for this 'legal' app. Now I need to either reinstall everything and have 20 or so business units retest.. or just reinstall the one 'legal' instance.
February 1, 2011 at 10:41 am
I think his question is why 3 instances..
CEWII
February 1, 2011 at 10:44 am
Default instance for most applications, one infrastructure monitoring app that has it's own instance for permformance tuning reasons and two other instances for applications that need a certain or custom Server collation.
February 1, 2011 at 1:49 pm
max server memory and cpu affinity can get you "isolation for performance reasons" without giving up the memory another instance will chew up for nothing. And many times just a database collation is good enough for an application instead of having an entire instance of a single collation. Just a thought.
In any case I do agree with putting a 32 bit instance on this (or preferably another) server for that stuff.
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
February 2, 2011 at 9:48 am
TheSQLGuru (2/1/2011)
max server memory and cpu affinity can get you "isolation for performance reasons" without giving up the memory another instance will chew up for nothing. And many times just a database collation is good enough for an application instead of having an entire instance of a single collation. Just a thought.In any case I do agree with putting a 32 bit instance on this (or preferably another) server for that stuff.
Max Server Memory won't stop one DB/application from gobbling up all the buffer pool for that instance. Imagine an application which does very large infrequent queries. With a separate instance you can set max server memory and cpu affinity on the instance and sacrifice some performance on the single application to stop it from interfering with the performance and caching of other apps.
It sounds like that's what you're suggesting but I'm missing how you can set Max Server Memory on a DB.
Viewing 15 posts - 1 through 15 (of 16 total)
You must be logged in to reply to this topic. Login to reply