Since you are using the Backup/Restore method, you don't need to copy the database (mdf) and log file (ldf) to the new server, just the backup files. You do not need to recreate the database either. The database, database files and log file will all be created during the restore process. The upgrade process is done by SQL Server when restoring your database backup.
Here is the method I use:
On SQL Server 2000
- Perform a full backup of the database
- Perform a log backup of the database
"captures records on the transaction log that were written since the last transaction log backup". Consider using the WITH NORECOVERY option, if you don't want people accessing the database after you're done.
- Copy the full database and log backup files to the server that has SQL Server 2005
On SQL Server 2005
- Restore the full backup with NORECOVERY
Make sure you change the directories as mentionned in your post.
- Restore the log backup with RECOVERY
Once the database is restored on the new server. I run the following commands in a new query window
USE [mydb]sp_updatestats -- updates statistics
This is because statistics are not automatically updated during the upgrade process.DBCC CHECKDB WITH DATA_PURITY
Causes DBCC CHECKDB to check the database for column values that are not valid or out-of-range. This is important when upgrading from SQL Server 2000 to 2005 or 2008.
Associating database users with Logins
Now that your database has been restored, you need to associate its orphaned users with an actual login.
Method A: Fixing orphaned users
EXEC sp_change_users_login 'Report' -- find orphaned users- if the login exists already, you can asssociate the orphaned user with the login. Otherwise, you can create the login
-- Login exists
EXEC sp_change_users_login 'Auto_Fix', 'user'
-- Login doesn't exist
EXEC sp_change_users_login 'Auto_Fix', 'user', 'login', 'password'
Method B: sp_help_revlogin
You also have an alternative called sp_help_revlogin which can help you to restore not only the login but the original password that went with it.
http://support.microsoft.com/kb/246133/en-us
It essentially entails creating a stored procedure on your old server to generate a script that will output all of your existing logins. You then copy the output of that stored procedure to your new server and restore the logins that are associated with the database you restored.
For speed (eg less downtime) backup/restore. Backup/restore is quicker because of Instant File Initialisation (only for MDF). The actual backup file is a lot smaller then the MDF/LDF sizes so copies quicker.
It's arguably slighty less risky because there is no downtime on the SQL 2000 instance.
However, detach removes access to the old database. You'll have to take this offline with a backup/restore. If there is a risk of end users connecting, use this (or take offline as soon as backup is complete)
Basically, it's whatever suits you best. I've used both methods for a recent server migration.
Best Answer
Personally, I would avoid the detach/attach mechanisms. Especially in SQL Server 2000, I just don't trust that you will always bring the server back up and be able to attach those files. I've heard plenty of stories where this didn't happen cleanly - just because you have a Plan B doesn't automatically make Plan A sensible.
With backup / restore, you don't risk having to go to Plan B. If the backup fails, your database is still up. If restore fails, your old database is still up. In both cases you can restore the operation of the original database and revisit the plan later. In addition to the extra security here over stopping SQL Server and/or detaching, this also means you can test the hoo-has out of the backup/restore methodology (assuming you currently have the space to perform the backups and another instance to test the restore). You can't really test the detach approach without detaching the databases or stopping SQL Server, and that's tough to do outside of a proper maintenance window. And finally, with the other approaches you can't even start copying the files until you've detached or brought SQL Server down. With backup/restore you can have the .bak file waiting on the new storage long before you take the last log backup and start your maintenance window.
One other benefit over the pull-the-drive-out-from-under-SQL-Server method: with backup/restore you can move various files to different drive letters than they were before. For example when we migrated to a new SAN, we were able to have more volumes, so we could move tempdb to T:\ (which didn't exist before), some of the data and log files to new drive letters, etc. to better utilize all the new I/O capacity we had. If you simply shut down SQL Server and then swap out the disks, you need to have the same drive letters and the same number of volumes.