Restoring databases to a set drive and directory

Posted by okeofs on SQL Blogcasts See other posts from SQL Blogcasts or by okeofs
Published on Mon, 15 Apr 2013 22:18:00 GMT Indexed on 2013/06/24 16:30 UTC
Read the original article Hit count: 280

Filed under:

 

Restoring databases to a set drive and directory

 

Introduction

 

Often people say that necessity is the mother of invention. In this case I was faced with the dilemma of having to restore several databases, with multiple ‘ndf’ files, and having to restore them with different physical file names, drives and directories on servers other than the servers from which they originated.

 

As most of us would do, I went to Google to see if I could find some code to achieve this task and found some interesting snippets on Pinal Dave’s website.

 

Naturally, I had to take it further than the code snippet, HOWEVER it was a great place to start.

 

Creating a temp table to hold database file details

 

First off, I created a temp table which would hold the details of the individual data files within the database. Although there are a plethora of fields (within the temp table below), I utilize LogicalName only within this example. The temporary table structure may be seen below:

 

 

 

create table #tmp

 

(

 

LogicalName nvarchar(128)

 

,PhysicalName nvarchar(260)

 

,Type char(1)

 

,FileGroupName nvarchar(128)

 

,Size numeric(20,0)

 

,MaxSize numeric(20,0),

 

Fileid tinyint,

 

CreateLSN numeric(25,0),

 

DropLSN numeric(25, 0),

 

UniqueID uniqueidentifier,

 

ReadOnlyLSN numeric(25,0),

 

ReadWriteLSN numeric(25,0),

 

BackupSizeInBytes bigint,

 

SourceBlocSize int,

 

FileGroupId int,

 

LogGroupGUID uniqueidentifier,

 

DifferentialBaseLSN numeric(25,0),

 

DifferentialBaseGUID uniqueidentifier,

 

IsReadOnly bit,

 

IsPresent bit,

 

TDEThumbPrint varchar(50)

 

)

 


 

 

 

We now declare and populate a variable(@path), setting the variable to the path to our SOURCE database backup.

 

declare @path varchar(50)

 

set @path = 'P:\DATA\MYDATABASE.bak'

 

 

 

From this point, we insert the file details of our database into the temp table. Note that we do so by utilizing a restore statement HOWEVER doing so in ‘filelistonly’ mode.

 

 

 

insert #tmp

 

EXEC ('restore filelistonly from disk = ''' + @path + '''')

 

 

 

At this point, I depart from what I gleaned from Pinal Dave.

 

 

 

I now instantiate a few more local variables. The use of each variable will be evident within the cursor (which follows):

 

 

 

Declare @RestoreString as Varchar(max)

 

Declare @NRestoreString as NVarchar(max)

 

Declare @LogicalName  as varchar(75)

 

Declare @counter as int

 

Declare @rows as int

 

set @counter = 1

 

select @rows = COUNT(*) from #tmp  -- Count the number of records in the temp

 

                                   -- table

 

 

 

Declaring and populating the cursor

 

At this point I do realize that many people are cringing about the use of a cursor. Being an Oracle professional as well, I have learnt that there is a time and place for cursors.

 

I would remind the reader that the data that will be read into the cursor is from a local temp table and as such, any locking of the records (within the temp table) is not really an issue.

 

 

 

DECLARE MY_CURSOR Cursor

 

FOR

 

Select LogicalName

 

From #tmp

 

 

 

Parsing the logical names from within the cursor.

 

A small caveat that works in our favour,  is that the first logical name (of our database) is the logical name of the primary data file (.mdf). Other files, except for the very last logical name, belong to secondary data files. The last logical name is that of our database log file.

 

 

 

I now open my cursor and populate the variable @RestoreString

 

Open My_Cursor

 

set @RestoreString =

 

'RESTORE DATABASE [MYDATABASE] FROM DISK = N''P:\DATA\ MYDATABASE.bak''' + ' with  '

 

 

 

We now fetch the first record from the temp table.

 

 

 

Fetch NEXT FROM MY_Cursor INTO @LogicalName

 

 

 

While there are STILL records left within the cursor, we dynamically build our restore string. Note that we are using concatenation to create ‘one big restore executable string’.

 

 

 

Note also that the target physical file name is hardwired, as is the target directory.

 

 

 

While (@@FETCH_STATUS <> -1)

 

BEGIN

 

IF (@@FETCH_STATUS <> -2) -- As long as there are no rows missing

 

select @RestoreString =

 

case

 

when @counter = 1 then -- This is the mdf file

 

   @RestoreString + 'move  N''' + @LogicalName + '''' + ' TO N’’X:\DATA1\'+ @LogicalName + '.mdf' + '''' + ', '

 

 

 

-- OK, if it passes through here we are dealing with an .ndf file

 

-- Note that Counter must be greater than 1 and less than the number of rows.

 

 

 

when @counter > 1 and @counter < @rows then -- These are the ndf file(s)

 

   @RestoreString + 'move  N''' + @LogicalName + '''' + ' TO N’’X:\DATA1\'+ @LogicalName + '.ndf' + '''' + ', '

 

 

 

-- OK, if it passes through here we are dealing with the log file

 

When @LogicalName like '%log%' then

 

   @RestoreString + 'move  N''' + @LogicalName + '''' + ' TO N’’X:\DATA1\'+ @LogicalName + '.ldf' +''''

 

end

 

--Increment the counter

 

 

 

set @counter = @counter + 1

 

FETCH NEXT FROM MY_CURSOR INTO @LogicalName

 

END

 

 

 

At this point we have populated the varchar(max) variable @RestoreString with a concatenation of all the necessary file names. What we now need to do is to run the sp_executesql stored procedure, to effect the restore.

 

 

 

First, we must place our ‘concatenated string’ into an nvarchar based variable. Obviously this will only work as long as the length of @RestoreString is less than varchar(max) / 2.

 

 

 

set @NRestoreString = @RestoreString

 

EXEC sp_executesql @NRestoreString

 

 

 

Upon completion of this step, the database should be restored to the server.

 

I now close and deallocate the cursor, and to be clean, I would also drop my temp table.

 

 

 

CLOSE MY_CURSOR

 

DEALLOCATE MY_CURSOR

 

GO

 

 

 

Conclusion

 

Restoration of databases on different servers with different physical names and on different drives are a fact of life. Through the use of a few variables and a simple cursor, we may achieve an efficient and effective way to achieve this task.

© SQL Blogcasts or respective owner