My SQL Server 2000 installation is running on a very old server and I am planning on upgrading the server. Our databases/files themselves are stored on a SAN. I'd like to simply replace the head end server running the SQL Server engine and re-attach the SAN to the upgraded server. Assuming we have SQL Server installed on the new server, and I've physically attached the SAN to the new server what do I need to do to get the new server (and new instance) to recognize the databases on the existing disks? Do I just need to attach the databases?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Replacing Server...Keeping Disks and Databases
- Thread starter gharabed
- Start date
First, if this is still an option, I would backup each and every database, including all the system DBs. That way, if you can't get SQL Server running, at least you can re-install it and then restore all the DBs. BTW, the only one you don't have to backup is TempDB because it'll be recreated anyway.
If the old server is already gone and the databases are in a detached state, then yes, you can just attach them. However, if the previous server crashed, the databases were likely still attached and you can't just re-attach them. If you try, chances are they'll all be marked suspect and the server will think they are corrupt. At that point, your only choice is to restore from the most recent backups you have.
Catadmin - MCDBA, MCSA
"No, no. Yes. No, I tried that. Yes, both ways. No, I don't know. No again. Are there any more questions?"
-- Xena, "Been There, Done That"
If the old server is already gone and the databases are in a detached state, then yes, you can just attach them. However, if the previous server crashed, the databases were likely still attached and you can't just re-attach them. If you try, chances are they'll all be marked suspect and the server will think they are corrupt. At that point, your only choice is to restore from the most recent backups you have.
Catadmin - MCDBA, MCSA
"No, no. Yes. No, I tried that. Yes, both ways. No, I don't know. No again. Are there any more questions?"
-- Xena, "Been There, Done That"
mrdenny
Programmer
- May 27, 2002
- 11,595
Doing a migration like this is easy (I've done 5 this year so far). I'll assume that C: and D: are local disks, and that your databases are on E:, F:, and G:. You can switch your actual drive letters in for these later. I'll also assume that your master.mdf and master.ldf are in E:\MSSQL\MSSQL\Data\*.*. You can switch this out as well later. I'll also assume that the production machine is called SQL1 and the new machine will be having the same name.
Install windows on the new machine. Call it SQL1_NEW. Setup a LUN for it on the SAN and attach it as the E drive.
Install SQL 2000 with all the current service packs and hot fixes that the SQL1 machine has installed. Make sure that the system databases are installed in the same location as on the SQL1 machine.
During the outage window, change the stop SQL on both machines. Change the drive letter of the E drive on SQL1_NEW to the Y drive. Move the LUNs from SQL1 to SQL1_NEW. Rename SQL1 to SQL1_OLD and reboot. After the reboot in complete, rename SQL1_NEW to SQL1. After it's restart is finished it is now SQL1. If you need to keep the IP address the same, at this point you can power down SQL1_OLD and change the IP address on SQL1 to the IP from SQL1_OLD.
No one will ever know that anything has changed (except that the machine will be much faster). Using this method also gives you a great rollback plan. You simple move the LUNs back to the old machine and start SQL on it.
Denny
MCSA (2003) / MCDBA (SQL 2000) / MCTS (SQL 2005) / MCITP Database Administrator (SQL 2005)
--Anything is possible. All it takes is a little research. (Me)
![[noevil]](/data/assets/smilies/noevil.gif "[noevil] [noevil]")
Install windows on the new machine. Call it SQL1_NEW. Setup a LUN for it on the SAN and attach it as the E drive.
Install SQL 2000 with all the current service packs and hot fixes that the SQL1 machine has installed. Make sure that the system databases are installed in the same location as on the SQL1 machine.
During the outage window, change the stop SQL on both machines. Change the drive letter of the E drive on SQL1_NEW to the Y drive. Move the LUNs from SQL1 to SQL1_NEW. Rename SQL1 to SQL1_OLD and reboot. After the reboot in complete, rename SQL1_NEW to SQL1. After it's restart is finished it is now SQL1. If you need to keep the IP address the same, at this point you can power down SQL1_OLD and change the IP address on SQL1 to the IP from SQL1_OLD.
No one will ever know that anything has changed (except that the machine will be much faster). Using this method also gives you a great rollback plan. You simple move the LUNs back to the old machine and start SQL on it.
Denny
MCSA (2003) / MCDBA (SQL 2000) / MCTS (SQL 2005) / MCITP Database Administrator (SQL 2005)
--Anything is possible. All it takes is a little research. (Me)
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question
