Datasheet

Chapter 1: Being Objective: Re-Examining Objects in SQL Server
change. The worst offense comes when performing updates on objects in the master
database. Trust me when I tell you that altering these tables in any way is asking for
a SQL Server that no longer functions. (I’ve saved a system doing this, and I’ve
killed a system doing this; I don’t like 50/50 odds with the life of my server ... .).
Microsoft has created several alternatives (for example, system functions, system
stored procedures,
information_schema views, and a wide array of system metadata
functions) for retrieving much of the information that is stored in the system tables.
These alternatives are what you should be using.
The model Database
The model database is aptly named, in the sense that it’s the model on which a copy can be based. The
model database forms a template for any new database that you create. This means that you can, if you
wish, alter the model database if you want to change what standard, newly created databases look like.
For example, you could add a set of audit tables that you include in every database you build. You
could also include a few user groups that would be cloned into every new database that was created on
the system. Note that since this database serves as the template for any other database, it’s a required
database and must be left on the system; you cannot delete it.
There are several things to keep in mind when altering the model database. First, any database you create
has to be at least as large as the model database. That means that if you alter the model database to be
100MB in size, you can’t create a database smaller than 100MB. There are several other similar pitfalls.
As such, for 90 percent of installations, I strongly recommend leaving this one alone.
The msdb Database
msdb is where the SQL Agent process stores any system tasks. If you schedule backups to run on a
database nightly, there is an entry in msdb. Schedule a stored procedure for one-time execution, and yes,
it has an entry in msdb. Other major subsystems in SQL Server make similar use of msdb. SQL Server
Integration Services (SSIS) packages and Policy Based Management definitions are examples of other
processes that make use of msdb.
The tempdb Database
tempdb is one of the key working areas for your server. Whenever you issue a complex or large query
that SQL Server needs to build interim tables to solve, it does so in tempdb. Whenever you create a
temporary table of your own, it is created in tempdb, even though you think you’re creating it in the
current database. Whenever there is a need for data to be stored temporarily, it’s probably stored in
tempdb.
tempdb is very different from any other database in that not only are the objects within it temporary, but
the database itself is temporary. It has the distinction of being the only database in your system that is
completely rebuilt from scratch every time you start your SQL Server.
4