0

I've been looking at an upgrade to my SQL Server 2005 Enterprise edition. I'm specifically looking to upgrade as I'm hitting the limit of my 2 CPUs at the moment. It looks like I could move to 64 bit Standard at my hosting provider for about the same I'm paying now. I was going to try adding another 2 CPUs to the set up but figured I could at least try out the 64bit Standard edition first and then add the additional CPUs if it wasn't already improved enough.

Is there anything I need to look out for with moving to a 64 bit platform? ie are there any gotchas with this migration? Looking at the feature comparison listed here I don't think I'll miss anything from the Enterprise edition. I'm not sure what Parallel Index Operations are but a little google for that string seemed to suggest it was just something to do with rebuilding indexes whilst the db is running, something I don't need to do. Is there anything not listed at that link I should be aware of?

3 Answers 3

1

There are no problems moving from the 32bit edition of SQL to the 64bit edition of SQL Server. You will get a small performance improvement as you will have more room in your procedure cache to stored execution plans.

Some of the things which you won't have access to anymore.

Online index rebuilds. Parallel index operations (this is where SQL uses multiple threads to rebuild an index instead of a single thread) SQL Mail doesn't work (use database mail instead) DTS doesn't work (use SSIS instead) There's a few other items, but those are the big ones.

You said

I'm not sure what Parallel Index Operations are but a little google for that string seemed to suggest it was just something to do with rebuilding indexes whilst the db is running, something I don't need to do.

Rebuilding your indexes is something that you need to do. Especially if you are seeing performance problems. You should also be updating your stats on a regular basis. If you do these things on a regular basis you'll probably find that the performance of your existing system improves.

You should probably also make sure that your database has the required indexes, and check the execution plans on your queries to make sure that the indexes you have are being used correctly.

1
  • I'm rebuilding the indexes, but I do it nightly when no one is using the system so assume I don't need to be concerned with Parallel Index Operations.
    – Robin
    Aug 25, 2009 at 16:28
2

No problems for us.

However, you can hit memory issues oddly. Stuff like execution plans and xml parsers are constrained by the user mode address space in 32 bit, your AWE/PAE etc can be used as buffer pool. Suddenly, you're no longer constrained. You could in theory have a huge plan cache and a tiny data cache.

Configuring Windows 2003 ( x64 ) for SQL Server

x64 Memory Problems

However, high CPU can be a sign of not enough memory/too much paging. If you're CPU bound with 2, I reckon that x64 or another 2 CPUs won't help. I'd also say that CPU usage can also be caused by poor code...

Consider tuning rather than hardware as a first step.

1
  • Thanks, I'll take a look at the memory usage although we've historically been CPU bound mainly as a result of as you suggest bad coding. I'm looking at changing some pretty major chunks of how our database operates alongside the upgrade, if I don't strike gold with coding changes I want to have plan B (better Hardware) ready to roll
    – Robin
    Aug 26, 2009 at 8:40
0

I've moved an SQL 2005 Server from a 32-bit to 64-bit environment, and I didn't have any trouble, so you should be completely fine.

The biggest thing to look out for on the 64-bit platform is to make sure you install the 64-bit version of SQL 2005 server, since the 32-bit version will still work on a 64-bit OS. If you install the 32-bit version, you'll still be limiting your SQL server to 32-bit restraints, on top of running it emulated through WoW.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .