Home > Articles > Data > SQL Server

SQL Server Reference Guide

Hosted by

Toggle Open Guide Table of ContentsGuide Contents

Close Table of ContentsGuide Contents

Close Table of Contents

Database Configuration Options

Last updated Mar 28, 2003.

I've explained the options for configuring a server instance, and databases also have options for configuration. These options have to do with many parts of the database operation; from the way it protects the transactions to restricting the number of users who can access it.

One of the best ways to see the options is using the graphical tools, such as Enterprise Manager for SQL Server 2000 or SQL Server Management Studio for SQL Server 2005. In both cases, you should open the tools and locate a specific database, and then right click that database. From the menu that appears, you can select the Properties item, and then within the various panels on that screen you'll see these options.

I won't cover all of the options you can set in a database, since there are quite a few, and the references for each version (2000 and 2005) are at the end of this article. The official documentation covers more specific knowledge for each of these options, and it is updated more frequently than these articles are. What I will do is cover the particular options that you'll probably see most often in a more practical way, based on the settings I've seen in the field as a DBA and a developer.

Before we begin, I need to give you a word of caution. Some of these options are quite powerful, and as such, you should study each one carefully before you change the setting from what you have today to something else. In some cases, changing one of the options could make the database unavailable to your users.

Also, it's a good idea to record the settings you have before you make any changes, and then record the changes you make along with the date and the reason you're changing them. If you don't have a change management system, you should create one. I do this with a series of web pages, but you can also just use the command-based techniques I'll describe a little later on, and print the results out or save them to a spreadsheet somewhere. In any case, I always make a "back-out" script before I commit the change, that way if I hear screams down the hall I can quickly put everything back to what it was, quickly and easily.

With all that being said, you can use the graphical tools I've referenced to set the values — the nice thing about using the graphical tools is that they only present you with the options that are possible, rather than letting you type anything in and then giving you an error. That doesn't mean it couldn't happen, but it's less likely with the graphical tools.

There is another method to reading and setting these options, using stored procedures. You'll most often use this method when you are more familiar with the options and what they do, or in scripts. Even when you are an expert in SQL Server, it's often a good idea to use the graphical tools, since they allow you to think about what you are doing before you hit the "Go" key. In any case, here are the commands you can use to set the database options, now that you know a little more about them.

The primary command in dealing with the server and database settings is sp_configure. It should normally be followed with the command RECONFIGURE, but some configuration changes require the command RECONFIGURE WITH OVERRIDE. You can always use RECONFIGURE WITH OVERRIDE, so that's what I normally do.

If you just run the sp_configure command without any options, you won't see a lot of information. You actually need to prep it a little, telling the command that you want to see every option on the system. To do that, you use the same command to set its own options like this:

sp_configure 'show advanced options', 1;

So that sets up the full list, and now you can see each setting with this command:


It's a good idea to run this command periodically and store it in your system's binder, meta-data tables or whatever you're using to track your system's state. Not only will you want to periodically know this information, it's a great idea to record the information before and after a change, along with the date and the reason the change was made.

To set a server option, just type the command, followed by the option you care about in single quotes (ticks) and then a comma with the value.

sp_configure 'fill factor', 100;

For database-specific options, you can use the ALTER DATABASE statement. This example would set the database offline:


And there's yet another way to set the options — using a SET command in your queries. That format looks like this:


Although the SET commands (which you can read more about here for SQL Server 2005) don't change as many database options as ALTER DATABASE.

It's important to note that a database option overrides a server-level option. And if you use the SET command during a query, that option overrides a database option. Of course, not all options are available to the three, but the point remains that your setting for a database overrides that same option set at the server level, and that if someone issues a query with a SET option they can override that particular option on your database. And as always, practice the commands against a test server — one that you don't depend on for anything else except testing. Never try these commands on a production system until you verify what they will do on it.

I'll explain some of the database options that you can use with SQL Server 2000 and 2005, and let you know if any of those options are different for SQL Server 2005. Once again, these aren't all the options available, just the ones I've dealt with most often.

SQL Server 2000 and 2005 Database Options

I'll present these options in the order I've seen them used most often, not necessarily alphabetically or in the order you'll see them in the graphical or command-line tools. The official documentation lists them alphabetically to help you locate them that way. Also, I'll mention the "friendly" name that you'll see in the Graphical tools (GUI).

Options that deal with Availability

The first group of options has to with whether the database will be available to users, and how many people can access the system at one time.




Setting the database to Single-user mode, only one connection is allowed into the database, regardless of who that is.
In Restricted User mode, as many people as are in the db_owner database role and dbcreator and sysadmin roles are allowed in.
In Multi-User mode, everyone is allowed in.
The GUI name for this is "Restrict Access"


In Read-only mode, the database is available for queries, but not changes.
In Read-Write mode, the database is available for reading data and making data changes.
The GUI name for this is "Database Read-Only"


Setting this to OFFLINE makes the database unavailable for use. You can then copy the files if you wish, or do other file-based maintenance.
Online sets the database to be ready for access.
SQL Server 2005 adds another option: EMERGENCY. This mode sets the database to Read Only mode, disables all the transaction logging, and limits the database only to the members of the sysadmin server role.
The GUI name for this is at the right-click option of the database.

Options that deal with Maintenance

Several database options deal with the maintenance you'll do on the database, most notably the backups and recovery options.




The recovery model sets how the completed transactions will be purged from the database, and how the backups are handled. I've got a lot more information about this here.
The GUI name for this is "Recovery Model"


This mode automatically recovers the space in the database when you delete a lot of data. While this is useful for small databases that don't need constant attention, it causes lots of locks to be taken while it does the work, and steals some CPU and memory resources. I normally turn this off and just run the shrink operations during my normal maintenance windows.
The GUI name for this is "Auto Shrink"

Options that deal with performance

Many other options have performance impacts. These are something you want to talk with the developers about so that they don't re-set them using code.




Statistics help determine how well the engine can choose to use an index or other plan to get to the data quickly. I normally turn this on, along with the update option below. If you don't turn this on, you should create the statistics manually either periodically or during your maintenance window.
The GUI name for this is "Auto Create Statistics"


After the statistics are created, they need to periodically be updated. I normally set this option on, but if you don't you should update them periodically or during your normal maintenance runs.
The GUI name for this is "Auto Update Statistics"


There is quite a bit of debate about this option. It watches the connections, and when the last connection leaves the database, it closes all of the resources associated with the connections and shuts it down. This is normally not what you want to do. Normally you want to leave the database resources assigned so that they can be quickly use them again without having to spin them all up.
There are, however, times when this makes sense. It usually has to do with very specific uses of a system that needs its resources to be returned to the operating system just after the database work finishes. For the most part, you're fine to leave this off.
The GUI name for this is "Auto Close"

Other options

These are a list of some of the other options that you'll find affecting performance, use and maintenance in your system, and a couple that don't fit into a combination like the others.




This option has to do with the logging activity during BULK LOAD operations. If you turn this on, the system will bypass the logs when you use that statement. This is better for speed, but not for safety.
I normally turn this on, and perform a full backup just after these type of operations.


This option is only available in SQL Server 2005. It has to do with the impersonation options available in SQL Server 2005. When it is on, the impersonation can reach outside of the database, and when it is off, the impersonation operations are restricted to the database only.
The GUI name for this is "Trustworthy"

InformIT Articles and Sample Chapters

Deac Lancaster covers these options from a developer's perspective in his book SQL Building Blocks and Server Settings.

Online Resources

There are quite a few more options — here are the links to the official documentation. The first two are for SQL Server 2000, and the second two are for 2005: