July 4, 2008 at 11:25 pm
I've got a couple of SQL Server 2005 databases on a 32-bit OS, which I want to move to a 64-bit OS. Can I just copy the .mdf and .ldf files to the 64-bit machine, attach and I'm good to go, or do I need to do something else?
Rod
July 5, 2008 at 10:44 am
Doctor Who 2 (7/4/2008)
I've got a couple of SQL Server 2005 databases on a 32-bit OS, which I want to move to a 64-bit OS. Can I just copy the .mdf and .ldf files to the 64-bit machine, attach and I'm good to go, or do I need to do something else?
Yup. That should be all you need. The data and log file structures are the same for 32 bit and 64 bit.
If you're using any linked servers, test carefully. When I moved a large system 32 bit to IA-64, all the problems that I had were related to linked servers.
Also note if you're still using any DTS packages (not SSIS) that there is no 64-bit version of DTSRun.
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
July 5, 2008 at 7:46 pm
Really, Gail? I would have thought there would have been some difference. Is it all within the SQL Server executable, then? I guess it must be.
Thank you.
Rod
July 6, 2008 at 1:16 pm
there's rarely any issues moving databases x32 to x64 - most people have issues with the config of the o/s and sql server. Maike sure you're at sp2 + cu6 at minimum.
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
July 6, 2008 at 2:24 pm
Service pack 2 and "cu6". What's cu6?
Rod
July 6, 2008 at 3:06 pm
CU = Cumulative update. This is a rollup of all of the post SP2 hot fixes that are available. There is also CU7 that is available.
Unless there is a specific reason that your application will not support the later updates, you should always look at applying the latest updates.
You can find CU7 here: http://support.microsoft.com/kb/949095/
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
July 6, 2008 at 7:42 pm
"Can I just copy the .mdf and .ldf files to the 64-bit machine, attach and I'm good to go, or do I need to do something else?"
Be sure to detach the database! If you just stop SQL Server and then copy the files, you have about a 10% chance that the attach will fail. This is documented by MS.
SQL = Scarcely Qualifies as a Language
July 7, 2008 at 12:24 am
Doctor Who 2 (7/5/2008)
Really, Gail? I would have thought there would have been some difference. Is it all within the SQL Server executable, then? I guess it must be.
It's all in the binaries. The data and log files, as well as the backup files, are independent of the processor architectures.
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
July 7, 2008 at 7:03 am
As everyone stated moving from 32bit SQL to 64 bit is fairly easy. We ran into more issues with the OS moving to 64 bit. The biggest being ODBC drivers / data sources & 64 bit OS. You need to run some of the 32 bit ODBC utilities to get it to work. Nothing too difficult but you just need to be aware of them if you utilize ODBC.
John
July 7, 2008 at 8:58 am
Assemblies can be flaky if they're 32bit, SQLMail doesn't work, etc. There are potential issues, but if you have a simple db setup, then you should be OK.
July 7, 2008 at 9:14 am
1 more saying: detach, move, attach - or dump, load.
I'm talking about databases and engines, not the rest of the Ginzu Knives that come with SQL Server.
Doing the OS install and the SQL Server installs, however, is just weird and flaky. SQL Server itself is rock solid and fast as anything.
And that assumes the DB doesn't have junk like vendor written extended stored procedures. We actually run one 32-bit instance on our x64 servers to support such a scheme.
x64 is flaky in a lot of ways, depending on your hardware and your support software. We've had trouble with several system backup apps (Veritas does not support x64, Acronis does but is tripping over our high falutin' disk array drivers).
Roger L Reid
July 7, 2008 at 12:57 pm
Jeffrey - Interesting post. I've taken MS's "don't install a CU without a specific reason" seriously (even though I modify registries and list systems files, ha!)
And I've also had the feeling that for x64, it might be better to install them.
Many true x64 binaries seem to be less robust than their x86 sibs.
If you've got anything to add about how you came to feel that way, I'd be interested. It's something I've been considering, and there's not much experience being shared on that.
roger
Roger L Reid
July 7, 2008 at 1:16 pm
R L Reid (7/7/2008)
Jeffrey - Interesting post. I've taken MS's "don't install a CU without a specific reason" seriously (even though I modify registries and list systems files, ha!)And I've also had the feeling that for x64, it might be better to install them.
Many true x64 binaries seem to be less robust than their x86 sibs.
If you've got anything to add about how you came to feel that way, I'd be interested. It's something I've been considering, and there's not much experience being shared on that.
roger
For me - it's mostly an issue of getting the memory fixes available in the later updates. On the other hand, I usually push for the later updates only to have most of the vendors I work with stick with a lower requirement. One example is a system we just upgraded where the vendor has only certified on SQL Server 2005 RTM and has no current plans for certifying on even SP2.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
July 8, 2008 at 6:32 pm
Steve Jones - Editor (7/7/2008)
Assemblies can be flaky if they're 32bit, SQLMail doesn't work, etc. There are potential issues, but if you have a simple db setup, then you should be OK.
I do have a simple database setup, so I think I'll be OK. I'll stay away from things like SQLMail, though. Thanks for the tip.
Rod
July 13, 2008 at 3:17 pm
there are a number of memory issues which can cause quite severe performance problems - I know because I had a couple of long running incidents with ms, these were not fixed until SP2 CU6. Along with all the issues with sp1 and sp2 to run on rtm would be seriously risky - you're also not supported by Microsoft for as far as I know you must be at sp1 or above.
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
Viewing 15 posts - 1 through 15 (of 15 total)
You must be logged in to reply to this topic. Login to reply