Blog Post

Are You Running the x86 Version of SQL Server 2005/2008?

,

If so why?  Honestly, I am curious why people may still be running 32-bit versions of SQL Server 2005, 2008, or 2008 R2 in a production environment.  I have been advocating that people use 64-bit versions of SQL Server 2005 and above for some time now. NewsGator’s production SQL Server environment has been 100% 64-bit since April 2006, but I am lucky in that I don’t have to worry about any 3rd party databases, and all of the applications that use my databases use the ADO.NET Provider (since we are a 100% Microsoft shop).

The main advantage of running x64 instead of x86 is that you can more fully and easily take advantage of all of your installed memory beyond 4GB. In the x86 world, you have to add the /PAE switch to boot.ini, set “awe enabled” to 1 with sp_configure, and enable “Lock Pages in Memory” for the SQL Server Service account in order to use AWE. You also have to decide whether to add the /3GB switch in boot.ini to let applications use 3GB of RAM instead of 2GB of RAM (which you would not want to do if you had more than 16GB of RAM, since the OS needs more memory to manage AWE). Depending on the Build of SQL Server that you are on, you may need to have Enterprise Edition in order to use “Locked Pages in Memory”. Its all pretty complicated.

After you do all of this, only the buffer pool can use the AWE memory. Things are much simpler and better with x64. With x64 or IA64, SQL Server 2005 and above can use all of the installed RAM for pretty much any purpose, with none of the 32-bit limits. Nearly any Intel or AMD server CPU sold in the last 5-6 years should be x64 capable (its easy to check with a tool like CPU-Z). Server RAM is pretty inexpensive, and you can never have too much RAM for SQL Server. The more RAM the better!

You may have heard that Windows Server 2008 R2 is 64-bit only, and there is a small possibility that SQL11 will be 64-bit only (not that I have any inside information). What do you think?

When I asked this question on Twitter a couple of days ago, the main answers I got were:

3rd party, ISV databases that require x86

3rd party, ISV databases had not been “certified” on x64

3rd party applications using older data access technology that is x86 only

I would love to hear any other reasons that may be blocking people from moving to 64-bit versions of SQL Server.

Rate

You rated this post out of 5. Change rating

Share

Share

Rate

You rated this post out of 5. Change rating