Article Index
SQL Tutorial
Microsoft SQL Server
Stored In The Master Database?
Installing A Production Data Server
SQL Server B (Middle Of The Road)
SQL Commands
SQL BETWEEN
SQL Aggregate Functions
SQL ALIAS
SQL Subquery
SQL INTERSECT
Table Manipulation
SQL CREATE INDEX Statement
SQL PRIMARY KEY
SQL UPDATE Statement
Advanced SQL
SQL Running Totals

The server's system catalog and all the environmental information is stored in the master database, which is contained within the master device. The master database is the brains of your server. Great care should be taken when modifying any information contained in the master database. You should get in the habit of backing up your master database whenever you make environmental changes to your server, including changing the sizes of databases or adding users. The following items should trigger a backup of the master database:

CREATE, ALTER, or DROP statements (SQL)

DISK statements (SQL)

Altering a transaction log
;
Adding or removing a mirrored device

Adding or dropping remote servers
·
Adding or dropping a login ID
·
Any change in server configuration

The size of the master device is another important consideration. By default in current versions of Microsoft SQL Server, the master is set to 25MB. This value is totally dependent on the system that it must support. Many things affect the size of the master device. For most production systems, you must alter the size of the master device when adding major components to the server.

Most end up in the 30MB range unless they need an abnormally large Tempdb. Upon installation, I usually change this setting to 30MB to avoid having to resize it a few weeks down the road. The additional 5MB of disk space will not hurt the server and provides more flexibility right off the bat. Keep in mind, however, that the size of the master device can be increased after installation.

Having a good understanding of the master device and its components will help you in later configuration and troubleshooting issues. By default Microsoft SQL Server stores the master database, the Pubs database, the model database, Tempdb, and the Msdb database in the master device.

 The Master Database

System tables and environmental information are stored in the master database. Tables such as Sysdatabases, Syslocks, Sysprocesses, and Sysusages store critical information about your server. Other tables, such as Sysobjects, keep track of the objects that reside in each database on your server; each database has a copy of these tables.

The server will allow you to edit these and other important tables through raw SQL; however, I strongly recommend that you do not modify data in any of the tables in the master through SQL commands. Such modifications should be attempted only when absolutely necessary and only by someone with an intimate understanding of Microsoft SQL Server. Plenty of tools are available in Microsoft SQL Server to protect you from yourself. Use these tools at your disposal to make server changes.

This is not to say that you cannot check these tables for information needed to run your client-server applications effectively. I have often used information in system tables to find certain server-side permission or relation information. You can read data all day long without making direct modifications to these tables.

By default all users of a database will have some kind of permission to access the system tables for that database. This is a requirement for the system to run well and cannot be avoided.

To clarify, let's look at this kind of information in a different light. You probably have committed to memory the layout of all the furniture in your house or apartment. If you woke up in the middle of the night and made a trip to the kitchen to get a drink of milk, you would probably make that trip fairly well even without the lights on.

The system tables store the information you take for granted, similar to the location and size of the coffee table, the doors, and so on. Incorrectly changing these stored values by hand would in effect move the furniture on you. This would not lend itself to a good environment for getting to your data. It could in some cases crash your server, rendering it useless.

The Pubs Database

In a production environment, Pubs does you no good and should probably be removed. This database is used as a learning tool and for testing the basics of your installation. Once your production machine is up and running, you can remove this database from the master device.

The Model Database

The model database is like a stencil for creating new user-defined databases. This stencil gives you a starting point for your CREATE DATABASE statements. The system tables for user-defined databases are stored in the model. Any stored procedures or users that need to exist in all your user databases should be placed in the model database. By placing them in the model, they will be copied to each successive database that is created. Be careful when placing things in the model. This action will increase the minimum size of your databases and may add unnecessary objects to databases.

Tempdb

I often refer to Tempdb as a pad of Post-it notes: very small scratch paper that you use for a short period of time and then discard when you no longer need the information on each piece of paper.

Many things can affect the space required for Tempdb. This database is part of the master device by default and resides on disk. This scratch pad is shared by all the users on the server for worktable space and to resolve join issues in processing your queries.

If you have many users on your system, you might need a bigger Tempdb. You might also need a bigger Tempdb if your users have the ability to write their own ad hoc queries or reports, or if a query returns a large number of rows.

So how big is big enough? This is a newsgroup topic in itself. You really have to look hard at what your server is going to handle and make your best guess. Following are some guidelines to optimize performance:

Keep your queries under control.

Limit the ad hoc report and free-formed query abilities against your system.
·
Use indexed columns for your join conditions and sorting needs
whenever possible.
·
Watch all ORDER BY statements.

If you are going to place Tempdb in RAM, install it to disk and test the performance. Then move it to RAM and test it again. If your tests show a good margin of improvement, then leave it in RAM. Otherwise, change it back to disk.

You'll wish you had later when you start seeing the "Can't Allocate Space in Tempdb" error messages. After you have installed your server, made setting changes, and established some of the basic configuration options, back up your master database. You might as well get used to it now and make a habit out of performing a backup whenever you change the server configuration. It's better to restore your master from a backup than to reconstruct it from memory and any notes you might have in a folder somewhere.

The Msdb Database

The Msdb database is perhaps the most versatile piece of your server. This is basically your server's to-do list. You can add tasks to this database that will be performed on a scheduled recurring basis. You can also view the history of the defined tasks and their execution results. The Msdb database is the component that allows you to proactively manage your data server. Used primarily by the SQL Executive service, the Msdb is created on two separate devices: one for your data and one for the transaction log.