Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
Author |
Topic |
jstormoen
Starting Member
30 Posts |
Posted - 2006-03-13 : 16:02:25
|
Here is my scenario - we have a Shark storage unit that we are in process of retiring - I have a DB machine with a local C: drive and a Shark connected drive where all of my DB's reside including Master, Model and ..... . We are going to try and create a SAN connected Lun (3 drives - data, logs & backups) for that machine that will replace out the Shark connected drive.Here is the question How can I be sure that the SQL install resides on the local C: drive which is not going away ? Secondly I have looked into moving the System DB's (Master ....) and looks like that is all doable but I have never had to do this - is there any things I need to be careful of or watch out for in this process ? Any insight is good insightThanks |
|
eyechart
Master Smack Fu Yak Hacker
3575 Posts |
Posted - 2006-03-13 : 19:45:09
|
this shouldn't be much of a problem.questions:1. is this part of a cluster?2. are you replacing 1 LUN from the Shark w/3 from the new SAN?-ec |
 |
|
jstormoen
Starting Member
30 Posts |
Posted - 2006-03-14 : 08:42:38
|
No it is not part of a cluster and yes we are replacing 1 drive from the shark with 3 from the SAN - Machine was built originally before I got here with only 1 drive to handle data, logs and backups. Is there any hidden DB's or are the only system dbs I'm worried about master, model, msdb and tempdb ? |
 |
|
eyechart
Master Smack Fu Yak Hacker
3575 Posts |
Posted - 2006-03-14 : 10:35:08
|
I would do your changes in two steps. The first thing is to migrate off of the Shark. So, let's say that your shark drive is your F: drive. And now you have 3 new LUNs presented to your server and you format them as G, H, I drives.take down your SQL Server. Then copy all the contents of your F: drive (shark drive) to your new G: drive. Afte the copy is complete, do some drive letter changing and make that G: drive your F: drive. You will first have to move the original F: drive to a different letter (M: for example) that will then free up F: for you to assign to G:. Hopefully that wasn't too confusing.Now that you have everything from your original Shark drive copied to the new SAN drive, bring SQL server online again and ensure that there are no errors.The 2nd step is to now move your databases to their new locations. there is a great KB article on moving your system and user databases http://support.microsoft.com/kb/224071. I suggest you follow the steps for moving the system databases before attempting to move the user databases. Moving user databases is far more straightforward than moving the system databases.So, after moving your system databases and testing your environment you can now move your user databases. I use the following script to script out the attach statements for all my user databases. This makes attaching a bunch of databases relatively painless. Make sure to save the output of this code.SET NOCOUNT ONDECLARE @dbname SYSNAMEDECLARE @filelist varchar(8000)DECLARE @filecmd varchar(8000)DECLARE @filecount INTDECLARE @filenbr INTDECLARE @fileid SMALLINTDECLARE @filename NVARCHAR(260)SELECT nameINTO #databasesFROM master.dbo.sysdatabasesWHERE name not in ('master', 'tempdb', 'model', 'msdb')ORDER BY nameCREATE TABLE ##files( fileid SMALLINT NOT NULL, [filename] NVARCHAR(260) NOT NULL)WHILE (SELECT COUNT(*) FROM #databases) <> 0BEGIN SELECT TOP 1 @dbname = [name] FROM #databases ORDER BY [name] SELECT @filecmd = 'INSERT INTO ##files SELECT fileid, rtrim([filename]) FROM ' + @dbname + '.dbo.sysfiles' EXEC (@filecmd) SELECT @filecount = COUNT(*) FROM ##files SET @filenbr = 1 SELECT @filelist = '' WHILE @filenbr <= @filecount BEGIN SELECT @fileid = fileid, @filename = [filename] FROM ##files ORDER BY fileid DESC SELECT @filelist = @filelist + '@filename' + CAST(@filenbr AS VARCHAR(3)) + ' = N''' + @filename + '''' IF @filenbr = @filecount --last file, no comma BEGIN SELECT @filelist = @filelist + CHAR(13) + CHAR(10) END ELSE BEGIN SELECT @filelist = @filelist + ',' + CHAR(13) + CHAR(10) END SELECT @filenbr = @filenbr + 1 DELETE FROM ##files WHERE fileid = @fileid END --print attach statment for current db PRINT 'sp_attach_db @dbName = N''' + @dbname + ''',' + CHAR(13) + CHAR(10) + @filelist + 'GO' + CHAR(13) + CHAR(10) + CHAR(13) + CHAR(10) DELETE FROM #databases WHERE name = @dbnameENDDROP TABLE ##filesDROP TABLE #databases I think this code was written by tara, anyway she posted it in this thread originally http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=16349After running the script to generate the attach statements it is time to actually detach and move your databases. You can either detach your databases using EM or use the generate sp_detach statement script from this article http://www.sqlteam.com/item.asp?ItemID=9465 to make that job easier. After detaching, you need to move your databases of course. Once that is done it is a simple step to edit the output from the attach script above with your new path information. Run each individual attach statement and check to make sure you don't get any errors.Good luck.-ec |
 |
|
jstormoen
Starting Member
30 Posts |
Posted - 2006-03-14 : 11:16:01
|
Thanks a ton - I had this posted on two different sites and had no real feedback. I was going to do this in a very similar way to what you suggested but without the script - Thanks for that addition - this is what makes these boards great affirming ideas and adding things in I would have never thought about. |
 |
|
|
|
|
|
|