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

SQL Server Configuration, Part 2

Last updated Mar 28, 2003.

In the last installment of this series, I introduced the concept of setting up the configuration options for SQL Server 2000 and higher. In this installment I’ll finish that explanation with some of the more advanced configuration options. If you haven’t read that first tutorial, take a break at this point and look that over first.

I’m covering settings in both SQL Server 2000 and higher, and some settings differ not only in what they do in each version, but even whether they exist in the earlier version. I’ll point out when I’m describing differences between 2000 and higher, and the screenshots in this tutorial are from SQL Server 2008.

I stopped at the Processor tab last time, and in this tutorial I'll complete the explanation of the other tabs that control SQL Server's behavior.

In both Enterprise Manager (EM) and SQL Server Management Studio (SSMS) I’ve right-clicked the Instance’s name, and I've selected Properties to access the configuration tabs. I'm moving next to the Security tab, and setting the options there.

The first selection in SSMS is the authentication mode. SQL Server allows accounts from the Windows context (local and domain) to access the Instance, but also allows you to select whether you want to create accounts in SQL Server that don’t know anything about Windows. In my case, I have the latter option selected. This is an option that you can change later if you wish.

Just below that is the audit level. Using this option, you can set whether SQL Server reports certain kind of login events to the event viewer. You can audit successful or unsuccessful attempts. If you need to monitor access to a more granular level, select the third option here [md] but it will add to your Windows Event Log growth. Make sure you’ve set that at a high enough value to keep the log from filling or “srapping around” and losing events.

The Server Proxy account allows you to have SQL Server perform actions on behalf of a developer or user. There’s a fairly significant difference between how this works in SQL Server 2000 and the later versions, so I’ll point you to this resource to learn more about this feature.

There are other options that deal with C2 and Common Criteria auditing as well – and again this is a fairly complex topic. If you’re not sure if you need these options, then odds are you don’t. If you do, I recommend you read and explore the security section here at InformIT and in SQL Server’s Books Online to ensure you set not only these options, but the rest of the processes you need to certify SQL Server to those higher levels.

The next option is cross-database ownership chains. One benefit of SQL Server security is that if a single account creates several objects, then permissions to the "parent" or calling object is all that is needed for users to access the underlying objects. If I create several tables and a view that references them, you only need to grant access to the view for the users to see the data when they use the view. This is called an "ownership chain."

Setting the cross-database ownership chain carries this concept all the way into another database. It means that my view can reference tables in other databases, and the users only need permissions on the original view to see them. There are both security and performance implications here, however, so I don't recommend this option.

The next tab, Connections, sets the options for applications and users that access this server.

These options aren't by database; they are defaults for all connections to the server that lack other specific settings. Because application developers can override these settings when they write their programs, I leave these at the defaults and communicate that fact (loud and often) to the development team.

One option you should ensure is checked is to allow remote connections to the server, or Instance. Without it, applications aren’t going to be able to contact the server.

The timeout is best left at the default unless you know you should change it. It’s the amount of time SQL Server will allow a connection to live before it reports that it is still working on a query. Don’t worry about long-running reports and so on [md] those will report properly. Again, communicate this value to your developers. They are the ones that will live with the results.

In SQL Server 2000 the Server Settings tab comes next – but in later versions this is found on the Advanced tab, so I’ll come back to that in a moment. In SQL Server 2005 and higher, the next tab is Database Settings (which also comes in a different place for version 2000).

These settings can also be overridden at the database level, by both graphical means and T-SQL commands. What is more interesting are the default values for database backups and file locations on this tab.

The first option controls the fill-factor that SQL Server uses for indexes by default. SQL Server stores data in 8k units called pages. When indexes are rebuilt, you can leave more room in them (a lower fill-factor) for additional entries. The advantage is that the indexes don't get as fragmented, since the related entries are kept together. The bad news is that you end up with a lot of wasted space, and a lot of page-switching to look things up. I covered index strategies in another tutorial, but the important thing to keep in mind is that you can change this behavior when you create your maintenance plan or use the DBCC T-SQL commands that rebuild the index.

The middle radio buttons set how long SQL Server takes to read from the tape device. Early in SQL Server's history, tape devices were notoriously slow. Some of these took quite a bit of tinkering in this tab to change SQL Server's behavior in dealing with them. You won't normally have to change any of these settings for two reasons. First, tape drives aren't as slow as they once were; and also, you rarely use the built-in tape software in an enterprise. Most of the time, a backup solution such as SAN copies, WORMS and the like have replaced the old single-tape setup, and are used for SQL Server, the file shares, servers, and Exchange.

The Recovery Interval sets how long the system waits for a retry after a system recovery event. You normally don't change this setting.

On my system I have the option to compress the backups by default. This is a SQL Server 2008 and later option, and only for Enterprise Edition. If I check this box, it means that my backups will be compressed without specifying that option in the BACKUP command.

Another important option here is the default data and log locations. You should always specify the location for your database files when you create a database, but you should pay attention to these settings for those times you don’t. Ensure you have plenty of room on that location, and ensure that you think it through before leaving this tab.

Now back to the Server Settings tab in SQL Server 2000, and the Advanced tab in SQL Server 2005 and higher.

This screen deals with features that you may not always use in SQL Server, such as Filestream in SQL Server 2008 and higher. You can also set the default language the server uses, and no, it doesn’t convert your Spanish data to English.

In SQL Server, the system catalogs can't be modified directly by default. Using this tab in SQL Server 2000, you can change that fact, but in SQL Server 2005 and higher you need to change it by using the sp_configure stored procedure. Do not make this change unless you know why, or have been instructed by someone who does.

In SQL Server 2000, this tab also allows you to change the Query Governor option which lets you to trim queries that exceed a certain cost. This cost is determined by the query optimizer engine; the developers should have a vague familiarity with these numbers. Unless this is something you know you want to do, it's best not to change it.

Also for SQL Server 2000, this tab sets the mail profile that SQL Server uses in SQL Mail. I've covered the various uses of mail within SQL Server in another tutorial, but this setting affects the ability of SQL Server to process mail within stored procedures. The other use of mail, in SQL Server Agent, can use the same or another mail profile.

Finally in SQL Server 2000, the last setting changes the date range that SQL Server recognizes within T-SQL statements. If your code includes two-digit years (shame on you!) this setting will affect how it considers them.

For SQL Server 2000, the last tab isn't really a server configuration setting; it's more of a wizard that sets up your system for replication. I've covered replication in another tutorial in depth.

The last tab in SQL Server 2005 and higher is Permissions.

Recall that you’re in the Server, or Instance, so the permissions you change here are at that level. The rights and permissions you grant here are for the entire Instance, not a particular database. You should read the security section of Books Online to understand exactly what you’re allowing your users to do in this screen.

Using these settings, you can properly configure your system, whether you use a client/server application or an N-tier architecture. Make sure you include your network admins on the decisions you make, document those decisions, and advise the developers how the system is configured.

InformIT Articles and Sample Chapters

The article Windows Processes and Threads: Weaving It All Together discusses NT threads in depth.

Books and eBooks

I cover these settings in more depth for SQL Server 2005 in my book Administrator's Guide to SQL Server 2005

Online Resources

Each setting is explained in more depth in Books Online.