March 10, 2009 at 5:58 am
I am trying to locate some sort of information to present to my managers regarding whether there is any differences, between 32Bit and 64Bit, in the way SQL Server 2005 presents itself to the outside world.
My understanding is that if you have a SQL 2005, whether it's 32Bit or 64Bit, the databases on the server, are the same. ie. you read and write to them the same.
Our problem is that we have third party software that is installed on a separate application server, that interrogates the databases on the cluster. It shouldn't make any difference, should it?
Any info will help.
Thanks
March 10, 2009 at 8:41 am
If you are running 64bits SQL Server and your third party application is 32bits then it may not be able to use most of the resources that 64bits RDBMS provides. This is caused by what I call the dependent dll issue components in an application work together so it is better to use 32bits SQL Server with 32bits application and 64bits with 64bits application. Now if the third party planned before developing then there is the option for the application to use 64bits SQL Server while the application is 32bits if the AnyCPU build option is used. I have used that option with both SQL Server and Oracle 64bits while my application was developed in 32bits box. The reason VS2005/8 is still a 32bits application that can be used to develop 64bits application. Check below for more about 64bits .NET application. Post again if you still need more help, I can resolve most platform related problems.
http://msdn.microsoft.com/en-us/library/ms241064.aspx
Kind regards,
Gift Peddie
March 11, 2009 at 4:17 pm
Dave (3/10/2009)
I am trying to locate some sort of information to present to my managers regarding whether there is any differences, between 32Bit and 64Bit, in the way SQL Server 2005 presents itself to the outside world.My understanding is that if you have a SQL 2005, whether it's 32Bit or 64Bit, the databases on the server, are the same. ie. you read and write to them the same.
Our problem is that we have third party software that is installed on a separate application server, that interrogates the databases on the cluster. It shouldn't make any difference, should it?
Any info will help.
Thanks
T-SQL is the same whether you use 32 or 64 bit. Even the action of detaching a database on a 32 bit server and copying the files to a 64 bit server then re attaching is perfectly valid. The underlying difference is how the engine handles its memory
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
March 11, 2009 at 4:38 pm
Hi
I would like to affirm Perry. If you do not components of the third party application on the same server as the SQL Server it doesn't matter if the application server (and its applications) is 32bit and the database server is 64bit.
Greets
Flo
March 11, 2009 at 4:46 pm
I can answer that if the third party did not plan when developing the application in some cases your database will run in 32bits mode, so you can only benefit from 64bits if your application is 64bits or AnyCPU build without dependent dll issues.
Kind regards,
Gift Peddie
March 11, 2009 at 5:03 pm
the application will generally just issue statements to the database. What can cause problems is 32 bit versions of sql server interracting with 64 bit versions, replication in particular is one area where the 2 platforms have issues
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
March 11, 2009 at 5:07 pm
Hi
I really didn't want to discredit your reply! How should this happen? SQL and data will be send over networkt and in my oppinion any information about the bit-rate of the client will be lost.
Please correct me if I'm wrong.
Greets
Flo
March 11, 2009 at 5:16 pm
the application will generally just issue statements to the database. What can cause problems is 32 bit versions of sql server interracting with 64 bit versions, replication in particular is one area where the 2 platforms have issues.
That is not correct many things could be the problems in 64bits Vista WPF will not build with 32bits SQL Server as AnyCPU your application must build 32bits also, Windows 2008 64bits application will only build 32bits with Oracle 64bits because there is no 64bits provider for Windows 2008 and Visual Studio is 32bits. The current way to do it plan before you write code or you may not get the benefits of 64bits.
Kind regards,
Gift Peddie
March 11, 2009 at 5:38 pm
Yet another arguement for keeping the database and application on separate servers.
I know it's not a definitive proof, but we've migrated a significant number of application databases (~100) from SQL2k/32 or SQL2k5/32 to SQL2k5/x64. All the database servers involved are/were dedicated. The only issues we've experienced that can be attributed to the 32-bit/x64 differences are where we've had "non-database components" running on the old database server, the most common example being DTS packages incorporating compiled code. In those situations we've moved those from the database server to a dedicated 32-bit DTS/SSIS server, which is our standard architecture anyway.
We've had no experience of SQL Server on "true" 64-bit (ie. Itanium) servers. The theory is still that the different "bitness" of the SQL Server engine is invisible to anything that is not running on the same server but we've never had an Itanium machine to play with.
March 11, 2009 at 5:50 pm
Separate server is not relevant the Oracles in most cases runs on 64 bits Unix HP/IBM/Solaris and the code will not compile as 64bits with a Windows 2008 64bits server because there is no driver and Visual Studio is 32bits but same Oracle will run as 64bits with Windows 2003 64 bits because there is no driver issue.
There are still issues with IIS6 because it can run in only one mode if you still have old application your SSRS must run in 32bits mode because IIS 6 runs in only one mode.
Kind regards,
Gift Peddie
March 12, 2009 at 2:20 am
Glenn Dorling (3/11/2009)
We've had no experience of SQL Server on "true" 64-bit (ie. Itanium) servers. The theory is still that the different "bitness" of the SQL Server engine is invisible to anything that is not running on the same server but we've never had an Itanium machine to play with.
I have had the 'pleasure' of working with Itanium. Itaniums don't run 32 bit code, so anything on the server (drivers, 3rd party backup solutions, etc) must be IA64. It's often a problem with ODBC drivers as there are few stable IA64 ODBC drivers
Apps that are running on other machines and only connecting to SQL across the network can be anything (usually based on what the machine they're running on is) as they have no knowledge of the internals of SQL server.
Even on the same machine, apps don't have to be the same bit size as SQL. I have on my desktop 2 instances of 64 bit SQL Server (2005 and 2008). I write 32 bit apps in visual studio and they connect to SQL without concern. The apps don't know and don't care what SQL does internally, they communicate only using TDS (Tabular data stream) and don't interact with the internals of the database server. Again, the main issue is often drivers. 32 bit ODBC drivers will not work with a 64 bit SQL Server, because the drivers interact with the internals of SQL (especially if they are in-process drivers)
The main advantage of 64 bit SQL (X64 or IA64) is the improved memory addressing.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply