Random Musings of Jeremy Jameson : SQL Server

Bug Deploying SQL Server Database Using VSDBCMD.EXE

Jeremy Jameson — Wed, 09 Dec 2009 14:32:00 GMT

Yesterday we encountered a bug while trying to deploy a new SQL Server database from a Visual Studio database project using the VSDBCMD.EXE utility, following the prescriptive guidance on MSDN:

How to: Prepare a Database for Deployment From a Command Prompt by Using VSDBCMD

http://msdn.microsoft.com/en-us/library/dd193258.aspx

According to this MSDN article, all you need to do is copy some files to the server running Microsoft SQL Server, and then run the VSDBCMD.EXE utility (specifying your .dbschema or .deploymanifest file).

Unfortunately, when we attempted to deploy our database to our Test environment, we encountered a NullReferenceException:

Object reference not set to an instance of an object.

Fortunately, it didn't take long to find Gert's recommendation to add the following registry key:

reg add HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0

The error occurred since Visual Studio has never been installed on the SQL Server in TEST (unlike our local development VMs).

It certainly would be nice if the above MSDN article were updated to note the bug and associated workaround.

Note

As pointed out in a comment by Ramkumar Perumal, Microsoft.SqlServer.BatchParser.dll does not exist in any of the specified folders. This should also be reflected in the MSDN article.

You will also find instructions to add the registry key -- as well as an explanation for why you more than likely already have Microsoft.SqlServer.BatchParser.dll installed on your SQL Server -- in the following blog post:

Deploying your Database Project without VSTSDB installed. 2009-02-21

http://blogs.msdn.com/bahill/archive/2009/02/21/deploying-your-database-project-without-vstsdb-installed.aspx

Error Installing KB 970892 When Reporting Services Configured with Domain Account

Jeremy Jameson — Tue, 08 Dec 2009 05:11:00 GMT

For a little over a month, Windows Update was failing on one of the servers in the "Jameson Datacenter" (a.k.a. my home lab). Specifically, KB 970892 simply would not install on JUBILEE -- my Systems Center Operations Manager (SCOM) 2007 VM, that I use to monitor a number of physical and virtual machines.

Here's the first event I found regarding this error:

Log Name: Application Source: MsiInstaller Date: 10/27/2009 3:03:49 AM Event ID: 10005 Task Category: None Level: Error Keywords: Classic User: SYSTEM Computer: jubilee.corp.technologytoolbox.com Description: Product: Microsoft SQL Server 2005 Reporting Services (64-bit) -- Error 29528. The setup has encountered an unexpected error while Setting reporting service and share point exclusion path. The error is: Fatal error during installation.

This was quickly followed by another error in the event log:

Log Name: Application Source: MsiInstaller Date: 10/27/2009 3:04:55 AM Event ID: 1023 Task Category: None Level: Error Keywords: Classic User: SYSTEM Computer: jubilee.corp.technologytoolbox.com Description: Product: Microsoft SQL Server 2005 Reporting Services (64-bit) - Update 'GDR 4053 for SQL Server Reporting Services 2005 (64-bit) ENU (KB970892)' could not be installed. Error code 1603. Additional information is available in the log file C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\Hotfix\RS9_Hotfix_KB970892_sqlrun_rs.msp.log.

Shortly thereafter, I started seeing the following error once every minute:

Log Name: Application Source: Report Server (MSSQLSERVER) Date: 10/27/2009 3:06:52 AM Event ID: 107 Task Category: Management Level: Error Keywords: Classic User: N/A Computer: jubilee.corp.technologytoolbox.com Description: Report Server (MSSQLSERVER) cannot connect to the report server database.

Since I have Windows Update configured to automatically download and install updates every morning, the patch attempted to install each day -- but failed each and every time.

I have to admit that I've spent a fair amount of time troubleshooting this error over the past month, but since it wasn't a blocking issue -- just a particularly irritating annoyance -- I kept putting it off. [Honestly, I rarely look at the SCOM reports and instead rely mostly on email notifications and the Operations Manager Console.]

Fortunately, I finally managed to determine the root cause tonight and resolve the issue.

After downloading and installing the standalone patch installation, I discovered the following in the installation log:

MSI (s) (F0:54) [21:09:49:565]: Invoking remote custom action. DLL: C:\Windows\Installer\MSIAC31.tmp, Entrypoint: Do_RSSetSharePointExclusionPath <Func Name='LaunchFunction'> Function=Do_RSSetSharePointExclusionPath <Func Name='GetCAContext'> <EndFunc Name='GetCAContext' Return='T' GetLastError='203'> Doing Action: Do_RSSetSharePointExclusionPath PerfTime Start: Do_RSSetSharePointExclusionPath : Mon Dec 07 21:09:49 2009 <Func Name='Do_RSSetSharePointExclusionPath'> The application pool /s already exists. Error Code: 0x80077374 (29556) Windows Error Text: Source File Name: sqlca\sqliisca.cpp Compiler Timestamp: Mon Nov 17 17:05:40 2008 Function Name: Do_RSSetSharePointExclusionPath Source Line Number: 914

As noted in KB 917826, there appears to be a known issue when Reporting Services is configured to run using a domain account. For JUBILEE, the ReportServer application pool was configured to run as TECHTOOLBOX\svc-mom-das (the SCOM data access service account). After changing the app pool to run as NetworkService instead, I ran the standalone install of KB 970892 and it completed successfully.

I then changed the app pool identity back to TECHTOOLBOX\svc-mom-das (since that appears to be how SCOM 2007 wants it configured) and verified that a couple of reports run successfully. Woohoo!

I'm crossing my fingers that tomorrow morning, Windows Update detects that KB 970892 is installed and no errors occur.

Database Default Locations in SQL Server

Jeremy Jameson — Thu, 03 Dec 2009 13:30:00 GMT

I've mentioned before the importance of using multiple "spindles" when working with large SQL Server databases.

Generally speaking, the recommendation is to use different RAID 1+0 arrays for data and log files -- and depending on the size and load of your database, you may also need to isolate data files on individual RAID 1+0 arrays.

For really large OLTP databases that require lots of IOPS, additional arrays might also be required to split the log files (although, honestly, I haven't worked on any projects where this has been necessary).

One of the configuration steps that I always recommend for any Production SQL Server environment is to configure the default database locations to ensure your "data I/O" is isolated from your "log I/O" (both of which should be isolated from other I/O -- specifically, the paging file).

For example, suppose you have the following disk configuration on your SQL Server cluster:

C: (Local Disk) - RAID 1 array for operating system files, program files, and paging file
D: (DATA01) - RAID 1+0 array for data files
L: (LOG01) - RAID 1+0 array for log files
Q: (Quorum)

In this simplistic example, the D:, L:, and Q: drives are LUNs on the backend SAN, whereas the C: drive is DAS (Direct Attached Storage). Hopefully, the Storage team responsible for managing your SAN provides dedicated physical drives for D: and L: -- although, honestly, I've seen several enterprise organizations that don't dedicate these drives and subsequently experience performance issues later on.

Given the above disk configuration, SQL Server Management Studio should be used to configure the default database locations similar to the following:

Server Properties
- Database Settings
  - Default database locations
    - Data: D:\NotBackedUp\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA
    - Log: L:\NotBackedUp\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA

You certainly don't have to use the NotBackedUp folder if you don't want to (that's just the standard that I've been using for years).

Once you've configured the default database locations, anytime you create a new database -- for example, when you create a new Web application or content database in Microsoft Office SharePoint Server (MOSS) 2007 -- the data and log files will be placed on the desired drives (i.e. D: and L:, respectively).

Of course, when creating MOSS 2007 databases for a Production (or Test) environment, you still need to resize them appropriately in order to avoid having them simply auto-grow from a very small initial size (in order to avoid fragmentation and optimize performance).

Suppose you need to determine the default database locations through SQL (perhaps because you are scripting the process to create your databases). If you fire up SQL Server Profiler and start a new trace (the default trace options are fine), you will find that SQL Server Management Studio executes the following SQL statements when viewing the Database Settings page in the Server Properties window:

declare @RegPathParams sysname
declare @Arg sysname
declare @Param sysname
declare @MasterPath nvarchar(512)
declare @LogPath nvarchar(512)
declare @ErrorLogPath nvarchar(512)
declare @n int

select @n=0
select @RegPathParams=N'Software\Microsoft\MSSQLServer\MSSQLServer'+'\Parameters'
select @Param='dummy'
while(not @Param is null)
begin
    select @Param=null
    select @Arg='SqlArg'+convert(nvarchar,@n)

    exec master.dbo.xp_instance_regread
        N'HKEY_LOCAL_MACHINE',
        @RegPathParams,
        @Arg,
        @Param OUTPUT
        
    if(@Param like '-d%')
    begin
        select @Param=substring(@Param, 3, 255)
        select @MasterPath=substring(
            @Param,
            1,
            len(@Param) - charindex('\', reverse(@Param)))            
    end
    else if(@Param like '-l%')
    begin
        select @Param=substring(@Param, 3, 255)
        select @LogPath=substring(
            @Param,
            1,
            len(@Param) - charindex('\', reverse(@Param)))
    end
    else if(@Param like '-e%')
    begin
        select @Param=substring(@Param, 3, 255)
        select @ErrorLogPath=substring(
            @Param,
            1,
            len(@Param) - charindex('\', reverse(@Param)))
    end
    
    select @n=@n+1
end
            
print 'LogPath = ' + @LogPath
print 'MasterPath = ' + @MasterPath

Note that I truncated the actual SQL batch and added the print statements.

Environment Naming Conventions

Jeremy Jameson — Wed, 10 Jun 2009 02:42:00 GMT

One of the challenges I see in organizations that I work with is the lack of naming conventions for various environments -- or sometimes naming conventions that provide little or no value.

For about the last ten years, I've been a strong proponent of a simple "-suffix" naming convention that is not only very easy to learn (and remember!) but also makes things incredibly obvious to all team members and stakeholders on a project.

Most enterprise IT organizations typically have a naming convention for servers that includes things like the Active Directory domain the server is a member of, the role of the server, and usually some unique identifier to distinguish multiple servers in a farm. Other "ingredients" such as the datacenter the server is physically located in may also be included.

For example, my favorite fictitious manufacturing company, Fabrikam Technologies, has Production servers named:

FAB-DC-01 (the first domain controller for the FABRIKAM domain),
FAB-DC-02,
FAB-WEB-01 (the first Web server in a farm),
FAB-WEB-02,
FAB-SQL-01A (the first node in a SQL Server cluster, for which the cluster is named FAB-SQL-01),
FAB-SQL-01B,
etc.

This is a great start. As you can see from these examples, it's pretty easy to tell what the role of each server is.

However, in any organization of reasonable size, we certainly need more than just the Production environment (PROD). At a minimum, I recommend using a Test environment (TEST) and a Development environment (DEV). Note that this is in addition to individual developer environments -- which I typically refer to as "local" evironments (LOCAL). Depending on how much parallel development is planned -- and the corresponding release schedule -- you might also need a Maintenance environment (MAINT). However, many organizations can function effectively with just the DEV-TEST-PROD triad.

So this begs the question, what names should we use for DEV and TEST?

Here is what I recommend:

Monikers in the Development environment utilize a “-dev” suffix. For example, the Web server in DEV corresponding to the FAB-WEB-01 server in PROD is named FAB-WEB-01-DEV. Likewise, the SQL Server in the Development environment is named FAB-SQL-01A-DEV. Note that typically Development environments do not have a cluster, but I still recommend following the same naming convention and even adding a DNS entry for the DEV "cluster" name (e.g. FAB-SQL-01-DEV). Test environments often do have a SQL Server cluster configuration (which is a great place to validate your failover configuration and load testing).

Host headers in the Development environment also follow the “-dev” naming convention. For example, if the internal name of the Fabrikam Web site in Production is http://fabrikam, then http://fabrikam-dev is the corresponding URL used in the Development environment.

In order to distinguish sites on the local development VMs, the “-local” suffix is used. For example, http://fabrikam-local is the URL on an individual developer’s VM corresponding to http://fabrikam in Production. The %WINDIR%\System32\Drivers\etc\hosts file is then used to associate these URLs with the loopback address (127.0.0.1). [Be sure you are aware of the workaround in KB 896861 when using the loopback address.]

Similarly, monikers and host headers in the Test environment utilize a “-test” suffix (e.g. FAB-WEB-01-TEST, FAB-SQL-01A-TEST, and http://fabrikam-test).

Also note that organizations typically create separate service accounts within Active Directory for the Development, Test, and Production environments (and if you are not currently doing this, I strongly recommend it). For example, suppose FABRIKAM\svc-web is the service account for the application pool running http://fabrikam in Production. Then we would expect the Web site in DEV to be running as FABRIKAM\svc-web-dev and the site in TEST to be running as FABRIKAM\svc-web-test.

This ensures that only the minimal number of people need to know the passwords for a particular environment. For example, either the whole Development team -- or just a small subset of team leads -- needs to know the password for FABRIKAM\svc-web-dev, but they certainly don't know the password for FABRIKAM\svc-web-test (since that environment is managed by the Test team). Likewise, the Test team had better not know the password for the service account in Production (since -- at least hopefully -- that environment is owned by a separate Release Management team).

It is also important to point out how this naming convention is applied to fully qualified domain names (FQDNs). For example, suppose the external address of http://fabrikam is http://www.fabrikam.com. What then should we use for the corresponding FQDN in DEV, or should we even configure an FQDN for DEV? The answer to that latter question is a resounding "Yes!" and the answer to the former is http://www-dev.fabrikam.com. Note that we almost certainly won't to expose DEV on the Internet -- although we may choose to expose TEST ( http://www-test.fabrikam.com)

The primary reason I recommend using these FQDNs (aside from the fact that we are following the simple "-suffix" naming convention) is that browsers behave differently between intranet names (e.g. http://fabrikam-dev) and FQDNs (e.g. http://www-dev.fabrikam.com). In other words, when you are trying to simulate a problem on the external site, you should ensure that you are simulating the same security "zone" in DEV, or even in your local environment (e.g. http://www-local.fabrikam.com).

Lastly, I want to mention documentation. Whenever I sit down to write an Installation Guide -- or similar documentation -- I typically only specify the values for the Production environment, even though I fully expect the document to also be used to install and configure the Test and Development environments. I simply include a brief section at the beginning of the document describing the naming convention and that it is the responsibility of the developer or tester to modify the server names, host headers, and service accounts appropriately as he or she is following along when configuring DEV or TEST.

Since we typically have "infrastructure models" (i.e. Visio diagrams showing the physical architecture of DEV, TEST, and PROD), identifying servers and host headers in various environments is really straightforward.

Add sysadmin in SQL Server 2008 Using Local Administrator

Jeremy Jameson — Fri, 29 May 2009 15:44:00 GMT

A couple of months ago, I had to SysPrep a copy of one of my VMs in order to remove dependencies on my home domain (I had to work out of the Microsoft office for a couple of days because my DSL router cratered).

However, while the SysPrep process was quick and painless, after the reboot I found that I could no longer use my domain account to administer SQL Server. Sure, I had local Administrator access, but starting with SQL Server 2005, being a local Admin no longer grants you seamless and unlimited access to SQL Server.

So the question that I had was: How do I add a user to the sysadmin role in SQL Server 2008 if all I have is local Administrator access?

Based on my experience with SQL Server 2005, I remembered this was done as part of the installation using the Surface Area Configuration wizard. However, I couldn't find the equivalent in SQL Server 2008. The SQL Server Books Online clearly stated that the Surface Area Configuration tool was discontinued, but the "Replacement" information didn't help me in the slightest.

I tried an Internet search (using both Windows Live Search and Google) for:

add sysadmin SQL Server 2008

However, neither search returned anything useful (at least not within the first two pages of results -- which is typically my threshold before I move on to a different approach to solving a problem).

Fortunately for me, I didn't have to wait long for a response to my inquiry to one of the internal discussion lists. David Browne, a Technology Architect here at Microsoft, pointed me to the following:

Troubleshooting: Connecting to SQL Server When System Administrators Are Locked Out

http://msdn.microsoft.com/en-us/library/dd207004.aspx

I wish that would have come up in my search!

Backing Up User Databases in SQL Server (and SQL Server Express)

Jeremy Jameson — Fri, 30 May 2008 17:22:00 GMT

Since I appear to be on a roll with my blog this morning, I figured that I should write one more post about SQL Server before I get back to my "day job."

I typically use SQL Server Management Studio to configure and schedule database backups, because the Maintenance Plan Wizard makes it very quick and easy to click through a few screens and select the appropriate options. However, on some of the servers running in the "Jameson Datacenter" (a.k.a. my basement), I only have SQL Server Express installed, not the full SQL Server product. For example, on my server that runs Windows Server Update Services (WSUS), I use SQL Server Express as the "backend" storage solution, because for this particular scenario, I want to keep the database local instead of relying on a separate server. However, I still want to ensure that I have periodic backups of the databases.

In order to make this as painless as possible, I wrote the following script:

USE [Tools]
GO
/****** Object:  StoredProcedure [dbo].[BackupUserDatabases]    Script Date: 03/15/2007 07:55:44 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE PROC [dbo].[BackupUserDatabases]
(
    @backupType VARCHAR(15)
)
AS

DECLARE @backupFolder VARCHAR(255)

SET @backupFolder = 'C:\BackedUp\Microsoft SQL Server\MSSQL.1\MSSQL\Backup\' + @backupType

DECLARE @timestamp DATETIME
DECLARE @dateString VARCHAR(8)
DECLARE @timeString VARCHAR(12)

SELECT @timestamp = GETDATE()

SELECT @dateString = CONVERT(VARCHAR(8), @timestamp, 112)

SELECT @timeString = CONVERT(VARCHAR(12), @timestamp, 14)

-- Remove seconds from timestamp
SET @timeString = LEFT(REPLACE(@timeString,':',''), 4)

DECLARE @databases TABLE
(
    ID INT IDENTITY ( 1, 1 )
    , DatabaseName SYSNAME
)

INSERT INTO
    @databases 
    SELECT name
    FROM master.dbo.sysdatabases 
    WHERE name NOT IN ( 'master', 'model', 'msdb', 'tempdb' )

DECLARE @id TINYINT
SELECT @id = MIN ( ID ) FROM @databases

WHILE @id IS NOT NULL BEGIN
    DECLARE @databaseName SYSNAME
    SELECT @databaseName = DatabaseName FROM @databases WHERE ID = @id

    DECLARE @backupFileName VARCHAR(512)
    SELECT @backupFileName = @databaseName + '_backup_' +@dateString + @timeString + '.bak'

    IF @backupType = 'Full'
    BEGIN
        EXEC ('BACKUP DATABASE [' + @databaseName + '] TO DISK =''' + @backupFolder + '\' + @BackupFileName + '''')
    END
    ELSE IF @backupType = 'Differential'
    BEGIN
        EXEC ('BACKUP DATABASE [' + @databaseName + '] TO DISK =''' + @backupFolder + '\' + @BackupFileName + ''' WITH DIFFERENTIAL')
    END
    ELSE IF @backupType = 'Transaction Log'
    BEGIN
        DECLARE @recoveryModel SQL_VARIANT

        SELECT @recoveryModel = DATABASEPROPERTYEX(@databaseName, 'Recovery')

        IF @recoveryModel <> 'SIMPLE'
        BEGIN
            EXEC ('BACKUP LOG [' + @databaseName + '] TO DISK =''' + @backupFolder + '\' + @BackupFileName + '''')
        END
    END
    ELSE
    BEGIN
        RAISERROR ('Invalid backup type', 16, 1)
    END

    DELETE FROM @databases WHERE ID = @id

    SELECT @id = MIN ( ID ) FROM @databases
END

Well, technically, it's a stored procedure, but nevertheless I still keep the script to generate the sproc in my toolbox: BackupUserDatabases.sql. Notice that I create the sproc in a separate database (I arbitrarily chose the name Tools).

I can then schedule full, differential, and transaction log backups using scheduled tasks, as shown below.

Figure 1: Scheduled tasks for backing up databases

See full-sized image.

Here is the command behind one of the scheduled tasks (you can easily deduce the others):

"C:\Program Files\Microsoft SQL Server\90\Tools\Binn\SQLCMD.EXE" -S .\SQLExpress -d Tools -Q "EXEC BackupUserDatabases @backupType='Full'"

Lastly, note that I have a separate server periodically ROBOCOPY the backup files off of this server to another location -- just in case the WSUS server happens to catch on fire or some other act of God completely wipes out the local database backups ;-)

Counting Rows in All Database Tables in SQL Server

Jeremy Jameson — Fri, 30 May 2008 16:56:00 GMT

Here is yet another of the SQL scripts that I like to keep handy in my toolbox: Count Records in All Tables.sql

Sometimes when I get "dropped into" a consulting situation with a new customer, I need to quickly get acquainted with one or more of their SQL Server databases. One of the first things I usually like to know is: "What are the largest tables in the database in terms of the number of rows?"

While you could certainly craft some SQL to SELECT COUNT(*) from each user table, this is very inefficient. A much better way is to simply query the system tables as shown below:

SELECT
    sysobjects.Name
    , sysindexes.Rows
FROM
    sysobjects
    INNER JOIN sysindexes
    ON sysobjects.id = sysindexes.id
WHERE
    type = 'U'
    AND sysindexes.IndId < 2
ORDER BY
    sysobjects.Namecode

Shrinking All Database Files in SQL Server

Jeremy Jameson — Fri, 30 May 2008 16:50:00 GMT

Here is another SQL script that I keep handy in my toolbox: Shrink All Database Files.sql. Unlike the script that I shared in my previous post that simply truncated all transaction logs to free up disk space, this script is suitable for running in a Production environment (PROD), as well as in non-production environments, such as a shared Development environment (DEV).

Here is the script:

DROP TABLE #CommandQueue

CREATE TABLE #CommandQueue
(
    ID INT IDENTITY ( 1, 1 )
    , SqlStatement VARCHAR(1000)
)

INSERT INTO    #CommandQueue
(
    SqlStatement
)
SELECT
    'USE [' + A.name + '] DBCC SHRINKFILE (N''' + B.name + ''' , 1)'
FROM
    sys.databases A
    INNER JOIN sys.master_files B
    ON A.database_id = B.database_id
WHERE
    A.name NOT IN ( 'master', 'model', 'msdb', 'tempdb' )

DECLARE @id INT

SELECT @id = MIN(ID)
FROM #CommandQueue

WHILE @id IS NOT NULL
BEGIN
    DECLARE @sqlStatement VARCHAR(1000)
    
    SELECT
        @sqlStatement = SqlStatement
    FROM
        #CommandQueue
    WHERE
        ID = @id

    PRINT 'Executing ''' + @sqlStatement + '''...'

    EXEC (@sqlStatement)

    DELETE FROM #CommandQueue
    WHERE ID = @id

    SELECT @id = MIN(ID)
    FROM #CommandQueue
END

As you can see, this script follows the same pattern that I described in my previous post.

I have found this script to be especially useful when working with Microsoft Office SharePoint Server (MOSS) 2007, because I sometimes migrate large amounts of content when working on certain features (particularly Search) but later decide to remove the content and need to recover the disk space on my VM.

Truncating All Transaction Logs in SQL Server

Jeremy Jameson — Fri, 30 May 2008 16:32:00 GMT

One of the SQL scripts that I keep handy in my toolbox is Truncate All Transaction Logs.sql. While I would never recommend running this script in a Production environment (PROD), I find it to be very helpful for periodically freeing up disk space in shared Development environments (DEV) and especially on my local VMs. True, I could instead choose to schedule periodic backups, but then I'd still have to periodically delete the backup files (or, I suppose, I could schedule that as well), but, honestly, I really don't care to put that much effort into managing these environments -- especially since I tend to periodically "nuke" them from time to time to start fresh.

Here is the script:

DROP TABLE #CommandQueue

CREATE TABLE #CommandQueue
(
    ID INT IDENTITY ( 1, 1 )
    , SqlStatement VARCHAR(1000)
)

INSERT INTO #CommandQueue
(
    SqlStatement
)
SELECT
    'BACKUP LOG [' + name + '] WITH TRUNCATE_ONLY'
FROM
    sys.databases
WHERE
    name NOT IN ( 'master', 'model', 'msdb', 'tempdb' )

DECLARE @id INT

SELECT @id = MIN(ID)
FROM #CommandQueue

WHILE @id IS NOT NULL
BEGIN
    DECLARE @sqlStatement VARCHAR(1000)
    
    SELECT
        @sqlStatement = SqlStatement
    FROM
        #CommandQueue
    WHERE
        ID = @id

    PRINT 'Executing ''' + @sqlStatement + '''...'

    EXEC (@sqlStatement)

    DELETE FROM #CommandQueue
    WHERE ID = @id

    SELECT @id = MIN(ID)
    FROM #CommandQueue
END

As you can see, there really isn't much to this script. However, what I really wanted to cover in this post is how I implemented the script, and why I think this is a good pattern for scripts that perform some operation on an arbitrary number of objects in a SQL Server database.

Notice that the first thing that I do is create a temporary table that I call the "command queue." Okay, actually the first thing I do is drop the temporary table if it exists, just in case I need to run the script multiple times in a single session (not necessarily all that helpful when truncating transaction logs, but remember this is more about the pattern than this particular script).

While I could certainly choose to bypass the "command queue" and simply execute the SQL statements directly, I find this approach to be much more robust in terms of error handling. If something unexpected happens during the execution of the script, I can easily resume processing after recovering from the error (without having to completely start over again).

The rest of the script really requires no explanation. You can see that once I've "queued" up all of the commands to be run, I simply process them one at a time in a FIFO (First-In-First-Out) manner -- nothing special there.

In my next post, I share another useful script that follows the same pattern and potentially frees up even more disk space than simply truncating the transaction logs.

Copying a SQL Server Database to Another Environment

Jeremy Jameson — Mon, 29 Oct 2007 16:03:00 GMT

A couple of weeks ago I was troubleshooting a performance problem with the variations feature in Microsoft Office SharePoint Server (MOSS) 2007 and I needed to copy the content database to another environment for further analysis and testing. An easy (an unobtrusive) way to "snapshot" a database and copy it to another environment is to create a backup with the COPY_ONLY option:

BACKUP DATABASE [WSS_Content]
TO DISK = N'H:\WSS_Content.bak'
WITH NOFORMAT, NOINIT
    , NAME = N'WSS_Content-Full Database Backup'
    , SKIP, NOREWIND, NOUNLOAD, STATS = 10
    , COPY_ONLY

From SQL Server 2005 Books Online:

Taking a backup normally changes the database, in turn affecting other backups and how they are restored. Sometimes, however, a backup must be taken for a special purpose that should not affect the overall backup and restore procedures for the database.

A data backup is normally a base backup for one or more differential backups taken after it. Microsoft SQL Server 2005 introduces support for creating copy-only backups, which do not affect the normal sequence of backups. Therefore, unlike other backups, a copy-only backup does not impact the overall backup and restore procedures for the database.

In other words, by using the COPY_ONLY option I avoided screwing up the scheduled differential backups on the database.

However, there are a couple of issues with this approach:

You cannot specify the COPY_ONLY option through the UI in SQL Server Management Studio, but this is no big deal -- you can start by configuring most of the backup options using the UI, script the action to generate the corresponding SQL, and then add the COPY_ONLY option as shown above
You cannot restore a backup created using the COPY_ONLY option through the UI in SQL Server Management Studio; in the Restore Database dialog, when you select the From device option and then specify the backup file previously created with the COPY_ONLY option, no backup sets are displayed

The second problem was puzzling to me. After specifying my backup file, when I attempted to change to the Options page, I encountered the following error:

You must select a restore source.

When I first encountered this problem, I thought I had a corrupt backup file. However, by once again reverting to SQL instead of the UI, I was able to verify the backup was, in fact, valid:

RESTORE FILELISTONLY
FROM DISK = N'E:\NotBackedUp\Temp\WSS_Content.bak'

To restore from a COPY_ONLY backup, use a command similar to the following:

RESTORE DATABASE [WSS_Content_TEST]
FROM DISK = N'E:\NotBackedUp\Temp\WSS_Content.bak'
WITH FILE = 1
    , MOVE N'WSS_Content'
        TO N'E:\Microsoft SQL Server\MSSQL.1\MSSQL\Data\WSS_Content_TEST.MDF'
    , MOVE N'WSS_Content_Log'
        TO N'L:\Microsoft SQL Server\MSSQL.1\MSSQL\Data\WSS_Content_TEST_Log.LDF'
    , NOUNLOAD, STATS = 10

Note that when copying a database from one environment to another, you often need to use the MOVE option to specify the new location for the data and log files (to account for different disk configurations and available disk space).