Speed up SQL script deployment

Problem
In your earlier tip (Die Sucker - Killing SQL Server Process Ids (spids)) you outlined an option to kill spids (system process ids) to perform database restores or database maintenance when exclusive use of the database is needed.  Do any other options exist?  What are the advantages and disadvantages to these approaches?  When should one approach be used over another?

Solution
The typical approach to gaining exclusive use of a database is to use the ALTER DATABASE command.  This command has a few different parameters that can be helpful without writing any custom code to gain exclusive or restricted access to a database.  Check out the options and examples below in addition to some high level option analysis.

ALTER DATABASE Options

• SET - Determines the type of user access to the database
  • SINGLE_USER - Single user connection to the database
  • RESTRICTED_USER - Any number of users with db_owner or dbcreator or logins with sysadmin rights can connect to the database
  • MULTI_USER - Any number of users with rights to the database can connect to the database
• WITH ROLLBACK - Determines how the exclusive access to the database will take place
  • ROLLBACK AFTER integer [SECONDS] - Rollback the spids after a particular number of seconds
  • ROLLBACK IMMEDIATE - Rollback the spids immediately
  • NO_WAIT - If all of the spids do not commit or rollback immediately the request to put the database in an exclusive state will fail

ALTER DATABASE Example

ALTER DATABASE - Advantages and Disadvantages

• Advantages
  • Easily incorporated into scripts for database restoration processes
  • A fair amount of flexibility based on the options listed above without having to write any custom code
• Disadvantages
  • Could potentially have a long rollback process
    • The typical resolution would be to use the NO_WAIT option
  • Could potentially kill spids that need to finish for business reasons that are unexpectedly running slow

Kill spid Script - Advantages and Disadvantages

• Advantages
  • Can modify the script to determine if a specific application is running and determine if any spids should be killed or just wait for a finite period of time with a WAITFOR command
  • Can modify the script to conditionally issue the ALTER DATABASE statement as opposed to the KILL commands to determine if the database should be put in an exclusive state
  • Can modify the script to meet conditional needs
• Disadvantages
  • Could potentially have a long rollback process
    • Since you are using custom code and have knowledge of your environment you could conditionally kill spids as opposed to just killing all spids
  • Could potentially kill your own spid
    • The typical resolution would be to connect to a database that will not have spids killed as a portion of the process

Next Steps

• As is the case in many scenarios, a variety of options exist to address an issue or resolve a problem.  What is really necessary is to review the scenario, gather as much information as possible, determine the viable options then determine the best approach based on previous steps.  When it comes to killing spids for whatever reason, this scenario is no different.
• For additional information, reference the following:
  • Die Sucker - Killing SQL Server Process Ids (spids)
  • ALTER DATABASE (Transact-SQL) - SQL Server 2005
  • ALTER DATABASE - SQL Server 2000
• Special thanks to Mike, Ted and Robert of the MSSQLTips.com for feedback from the Die Sucker - Killing SQL Server Process Ids (spids) tip to serve as input for this tip.  Thanks again!

• Script to check that backup files still exist for SQL Server
• List columns and attributes for every table in a SQL Server database
• Splitting Delimited Strings Using XML in SQL Server
• Auto generation of UPDATE triggers for data auditing of your SQL Server tables
• Capture all statements for a SQL Server session
• More...

• Building a Data Mart with Integration Services

• Discuss this tip, post comments and feedback