I missed out on T-SQL Tuesday #25 (Tips ‘n Tricks) on the first go around, so I’m glad that with #26 I get another crack at it. Mine is pretty simple, but has saved me a lot of time when doing database restores. Whether I’m getting a database back online or (more likely) moving a database to another instance, I don’t want to be bothered for digging around to get my restore going.
As a DBA, I am two things:
- I hate using the GUI. Clicking through countless windows is for the birds and I would much rather type three commands than click ‘Next’ three times.
- I’m lazy. So those three commands? I write them once and save ‘em to a file so I can run them over and over and over….etc. Automation FTW!
So, restores. We all do them and they can get irritating. I know one of the most annoying things is relocating the files with MOVE when you’re bringing the database up on a different server. This is why a lot of folks use the GUI, because SQL Server can handle that behind the scenes and, if you really want, you can script it out. Well I’ve got another way.
You know you can RESTORE WITH FILELIST to get the database files within a backup. Why not take that a step further and capture it in a table? Then, once it’s in a table, we can use a little bit of SQL coding to give us a template to generate our restore command. Take a look:
--Turn off annoying rowcount SET NOCOUNT ON --Some variables declare @v_restore varchar(1000) declare @v_backup varchar(1000) declare @v_sql varchar(max) declare @datadir varchar(1000) declare @logdir varchar(1000) --Set backup file location, database name set @v_backup = 'C:\demo\test.bak' set @v_restore='Test_demo' set @datadir = 'C:\Restore\Data' set @logdir = 'C:\Restore\Log' --Storage table declare @restorelist table (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(100)) –-Be careful, this last field (TDEThumbprint) isn’t in 2k5 --Capture the file list insert into @restorelist exec('RESTORE FILELISTONLY FROM DISK='''+@v_backup+'''') --Build your restore command select @v_sql = 'RESTORE DATABASE '+@v_restore+' '+char(10)+'FROM DISK=''' +@v_backup+ ''''+ CHAR(10)+'WITH ' select @v_sql = coalesce(@v_sql,'')+'MOVE '''+logicalname + ''' TO '''+CASE when type='L' then @logdir else @datadir end +'\'+ right(physicalname,charindex('\',reverse(physicalname))-1)+''',' + char(10) from @restorelist --display the restore command, trim trailing comma and char(10) print substring(@v_sql,1,LEN(@v_sql)-2)
So that’s a lot of stuff! Well, not really. If you look at it, most of the script is taken up defining the file list table. Change your variables at the top, run the script, and copy the output into another window…BAM! There’s your restore command. And if it’s not perfect, you only need to make one or two changes to the output to clean it up.
This is not the only sproc output you can capture. The biggest lesson from this trick is you should think about other system stored procedures and look for opportunities where you can grab outputs to make your life easier. Help yourself look like a hero and get more sleep by taking advantage of what’s in SQL.