August 5, 2004 at 8:53 am
I am working on testing business recovery. This requires me to restore master and other system databases on the replacement hardware at the hot site. The original system is a cluster the replacement system is a single server. I would like to change the path for master, model, msdb to the D:\MSSQL\DATA from M:\MSQL\DATA for the .mdf and L:\MSQL\DATA for .ldf. I did the following:
Installed SQL Server 2000 and SP 3a
Started SQL Server in single user mode
Restored master from backup (.BAK) file to D:\MSSQL\DATA in Enterprise Manager.
SQL server would not restart in single user mode or with -f
I think I need an M and L drive on the replacement server, since that is the paths for the system databases and that moving them to the D is a problem.
So the question is can master, msdb and model's path be changed?
Any thoughts or suggestions will be appreciated.
thanks, Steve
August 5, 2004 at 10:02 am
http://www.sqlservercentral.com/columnists/sjones/movingmsdb.asp
http://www.sqlservercentral.com/columnists/sjones/moveyourmaster.asp
http://www.sqlservercentral.com/columnists/sjones/atemporarymove.asp
I'm not sure about moving the master to a completely separate box.
I can understand moving MSDB because of all the jobs etc, but I understood that master was intrinsic to the server on which it resides.
Personally I would generate a job to transfer all logins, move the user databases then script all the jobs.
August 5, 2004 at 9:16 pm
You will need to edit the registry. HKEY_Local_Machine\SOFTWARE\Microsoft\MSSQLServer\Parameters
Change the SQLArg0 to reflect the new path and file name of the master data file.
Change the SQLArg1 to reflect the new path for your error logs
Change the SQLArg2 to reflect the new path for the master log file
SQL Server should start although it probably would have been better to follow the instructions found here:
http://support.microsoft.com/default.aspx?scid=kb;en-us;224071&Product=sql2k
/*****************
If most people are not willing to see the difficulty, this is mainly because, consciously or unconsciously, they assume that it will be they who will settle these questions for the others, and because they are convinced of their own capacity to do this. -Friedrich August von Hayek
*****************/
August 6, 2004 at 7:15 am
Thanks for the help. Perhaps I wasn't clear...
I have restored the master from the cluster at home to the recovery server replacing master. So the paths for master and error log are the same as they were before the restore. Now, the cluster at home has one name the recover server has another name. Is this a problem? For example Server B is created through the normal install process. Server A's master file is resotred over Server B's master file. Will server B start?
August 6, 2004 at 7:34 am
I sincerely doubt it!
I believe that the MASTER database is specific to the server on which it originates.
I could be wrong, but I don't think I am.
August 6, 2004 at 9:17 am
You should be able to get SQL started.
However, I would start to build this environment incrementally. Start with a unclustered server at your primary and secondary, and debug all the issues with that. Then use your clustered machine as the primary and see what goes wrong. Depending on what is in Master, you may have problems starting a unclustered machine using a Master from a clustered machine.
I think you should be able to get SQL started because we do something vaguely similar to you and it works reliably.
We use Double-Take to replicate all our databases from our primary to secondary sites. SQL is up on the primary, down on the secondary. When we fail over, we stop SQL on the primary and start it on the secondary. We have to reset @@servername, but otherwise have no problems. Some of our pairs are on SQL7, the rest on SQL2K.
All SQL instances were originally installed independantly of each other, then when D-T replication was first turned on everything on the target was overwritten. We use D-T for replication as our apps have a lot of flat file data as well as databases and we need to keep all the replication in step.
This scenario seems close enough to your Master db restore to show that you should be able to get SQL running with what you are trying to do.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply