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.

 All Forums
 SQL Server 2000 Forums
 SQL Server Administration (2000)
 Replacing Data Drive with a SAN drive

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 insight

Thanks

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
Go to Top of Page

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 ?
Go to Top of Page

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 ON

DECLARE @dbname SYSNAME
DECLARE @filelist varchar(8000)
DECLARE @filecmd varchar(8000)
DECLARE @filecount INT
DECLARE @filenbr INT
DECLARE @fileid SMALLINT
DECLARE @filename NVARCHAR(260)

SELECT name
INTO #databases
FROM master.dbo.sysdatabases
WHERE name not in ('master', 'tempdb', 'model', 'msdb')
ORDER BY name

CREATE TABLE ##files
(
fileid SMALLINT NOT NULL,
[filename] NVARCHAR(260) NOT NULL
)

WHILE (SELECT COUNT(*) FROM #databases) <> 0
BEGIN

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 = @dbname
END

DROP TABLE ##files
DROP 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=16349

After 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
Go to Top of Page

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.

Go to Top of Page
   

- Advertisement -