Script sp_configure Output To Migrate Settings Between SQL Servers

Tim — Sat, 27 Feb 2010 23:22:30 +0000

Sometimes when setting up a new server, all you want is for it to work and be configured exactly like the old server. In some cases, the new server is almost identical in every way already. If you've worked much with SQL Server, you know very well that there are a billion switches and knobs and every time you do this, you forget at least one. I had a similar situation recently and figured I'd be lazy about it and just turned the output of sp_configure in to a script I could execute on the new server:

scriptSpConfigure.sql - run this on the old/source server

EXEC SP_CONFIGURE 'show advanced options' , 1;
GO
RECONFIGURE;
GO
DECLARE @spConfigureOutput TABLE
	([name] VARCHAR(255)
	,[minimum] INT
	,[maximum] INT
	,[config_value] INT
	,[run_value] INT)
 
INSERT INTO @spConfigureOutput
EXEC SP_CONFIGURE
 
SELECT	'EXEC sp_configure ''' + name + ''', ' + CAST(config_value AS VARCHAR)
FROM	@spConfigureOutput
GO
EXEC SP_CONFIGURE 'show advanced options' , 0;
GO
RECONFIGURE;
GO

Copy the selected rows and paste in to another SSMS window, add the show advanced options switch above and below - should end up with something like this after you remove all the settings you don't care about or don't want on the new server:

EXEC SP_CONFIGURE 'show advanced options' , 1;
GO
RECONFIGURE;
GO
 
EXEC SP_CONFIGURE 'Ad Hoc Distributed Queries', 1
EXEC SP_CONFIGURE 'Agent XPs', 1
EXEC SP_CONFIGURE 'clr enabled', 1
EXEC SP_CONFIGURE 'cost threshold for parallelism', 5
EXEC SP_CONFIGURE 'cursor threshold', -1
EXEC SP_CONFIGURE 'Database Mail XPs', 1
EXEC SP_CONFIGURE 'default full-text language', 1033
EXEC SP_CONFIGURE 'default trace enabled', 1
EXEC SP_CONFIGURE 'fill factor (%)', 80
EXEC SP_CONFIGURE 'ft crawl bandwidth (max)', 100
EXEC SP_CONFIGURE 'ft notify bandwidth (max)', 100
EXEC SP_CONFIGURE 'max full-text crawl range', 4
EXEC SP_CONFIGURE 'max server memory (MB)', 10000
EXEC SP_CONFIGURE 'max text repl size (B)', 65536
EXEC SP_CONFIGURE 'min memory per query (KB)', 1024
EXEC SP_CONFIGURE 'min server memory (MB)', 10000
EXEC SP_CONFIGURE 'nested triggers', 1
EXEC SP_CONFIGURE 'network packet size (B)', 4096
EXEC SP_CONFIGURE 'PH timeout (s)', 60
EXEC SP_CONFIGURE 'query wait (s)', -1
EXEC SP_CONFIGURE 'remote access', 1
EXEC SP_CONFIGURE 'remote login timeout (s)', 20
EXEC SP_CONFIGURE 'remote query timeout (s)', 900
EXEC SP_CONFIGURE 'scan for startup procs', 1
EXEC SP_CONFIGURE 'server trigger recursion', 1
EXEC SP_CONFIGURE 'SMO and DMO XPs', 1
 
EXEC SP_CONFIGURE 'show advanced options' , 0;
RECONFIGURE;
GO;

Script RESTORE DATABASE … WITH MOVE Stub

Tim — Sat, 27 Feb 2010 18:29:26 +0000

I think most people setup the drives on their Development servers to match their Production servers - this is so that restores go smoothly and files go where they're supposed to, things match up nicely, etc. Unfortunately, when you create a full backup all the backup file contains is the logical name of all the files - no physical paths. This means that if the database doesn't exist on the destination server yet, the engine has absolutely no idea where to put the files or what to name them.

The following script can be executed in the context of the source (original) database that was backed up to script out the MOVE statements if your plan is to put the files in the same place on the destination server.

scriptRestoreWithMove.sql - run this in the context of the source database

SET NOCOUNT ON
 
DECLARE @MoveOption AS TABLE
	([Id] INT IDENTITY(1,1)
	,[MoveOption] VARCHAR(MAX))
 
PRINT 'RESTORE DATABASE ' + DB_NAME(DB_ID())
-- Edit this to match where you're restoring from
PRINT 'FROM DISK = ''' + DB_NAME(DB_ID()) + '.bak'''  
PRINT 'WITH'
 
INSERT INTO @MoveOption ([MoveOption])
SELECT
    'MOVE ''' + a.name + ''' TO ''' + a.FILENAME + '''' AS [MOVE OPTION]
FROM
    dbo.sysfiles a
 
DECLARE 
	 @LastId INT = 0
	,@MoveOptionText VARCHAR(MAX)
 
WHILE EXISTS (SELECT TOP 1 1 FROM @MoveOption WHERE [Id] > @LastId)
BEGIN
	SELECT 		TOP 1
			 @MoveOptionText = [MoveOption] 
			,@LastId = [Id]
	FROM		@MoveOption
	WHERE		[Id] > @LastId
	ORDER BY	[Id] ASC
 
	PRINT CASE WHEN @LastId = 1 THEN '' ELSE ',' END + @MoveOptionText
END
 
PRINT 'GO'
 
PRINT 'ALTER DATABASE ' + DB_NAME(DB_ID()) + ' SET MULTI_USER'
PRINT 'GO'

And the output looks like this:

RESTORE DATABASE AdventureWorksDW
FROM DISK = 'AdventureWorksDW.bak'
WITH
MOVE 'AdventureWorksDW_Data' TO 'D:\AdventureWorksDW\AdventureWorksDW_Data.mdf'
,MOVE 'AdventureWorksDW_Log' TO 'T:\AdventureWorksDW\AdventureWorksDW_Log.LDF'
GO
ALTER DATABASE AdventureWorksDW SET MULTI_USER
GO

If you end up wanting to do something similar with existing databases, make sure to add a command before the RESTORE to set SINGLE_USER mode.

tim laqua dot com » sql server

Script sp_configure Output To Migrate Settings Between SQL Servers

Script RESTORE DATABASE … WITH MOVE Stub