SQL Server System Databases

Problem

I have seen the Master, Model, MSDB, etc. databases in Management Studio and in a variety of scripts.  Right now I have a fairly rudimentary set of knowledge about these databases just based on reviewing those scripts.  As I expand my  SQL Server knowledge, I am interested in learning more about the SQL Server system databases and how I can use them to help me on a daily basis.  I am sure their are many recommendations when working with these databases and I am interested in those as well.

Solution

Having a firm understanding of the SQL Server databases is beneficial when you need to troubleshoot an issue, gather data from SQL Server, etc.  This tip will outline the SQL Server system databases, explain the core objects used in the relational databases and outline some do’s and don’ts when working with the system databases. 

SQL Server System Databases

Below are the various SQL Server system databases you will find.

Master

• Purpose – Core system database to manage the SQL Server instance.  In SQL Server 2005, the Master database is the logical repository for the system objects residing in the sys schema.  In SQL Server 2000 and previous editions of SQL Server, the Master database physically stored all of the system objects.
• Prominent Functionality
  • Per instance configurations
  • Databases residing on the instance
  • Files for each database
  • Logins
  • Linked\Remote servers
  • Endpoints
• Additional Information
  • The first database in the SQL Server startup process
  • In SQL Server 2005, needs to reside in the same directory as the Resource database
  • Sources for Database Information – SQL Server 2000 to 2005 Crosswalk
  • SQL 2000 to 2005 Crosswalk – Startup Parameters

Resource

• Purpose – The Resource database is responsible for physically storing all of the SQL Server 2005 system objects. This database has been created to improve the upgrade and rollback of SQL Server system objects with the ability to overwrite only this database.
• Prominent Functionality
  • System object definition
• Additional Information
  • Introduced in SQL Server 2005 to help manage the upgrade and rollback of system objects
  • Prior to SQL Server 2005 the system related data was stored in the master database
  • Read-only database that is not accessible via the SQL Server 2005 tool set
  • The database ID for the Resource database is 32767
  • The Resource database does not have an entry in master.sys.databases

TempDB

• Purpose – Temporary database to store temporary tables (#temptable or ##temptale), table variables, cursors, work tables, row versioning, create or rebuild indexes sorted in TempDB, etc. Each time the SQL Server instance is restarted all objects in this database are destroyed, so permanent objects cannot be created in this database.
• Prominent Functionality
  • Manage temporary objects listed in the purpose above
• Additional Information
  • Properly Sizing the TempDB Database
  • Each time a SQL Server instance is rebooted, the TempDB database is reset to its original state

Model

• Purpose – Template database for all user defined databases
• Prominent Functionality
  • Objects
  • Columns
  • Users
• Additional Information
  • User defined tables, stored procedures, user defined data types, etc can be created in the Model database and will exist in all future user defined databases
  • The database configurations such as the recovery model for the Model database are applied to future user defined databases

MSDB

• Purpose – Primary database to manage the SQL Server Agent configurations
• Prominent Functionality
  • SQL Server Agent Jobs, Operators and Alerts
  • DTS Package storage in SQL Server 7.0 and 2000
  • SSIS Package storage in SQL Server 2005
• Additional Information
  • Provides some of the configurations for the SQL Server Agent service
  • For the SQL Server 2005 Express edition installations, even though the SQL Server Agent service does not exist, the instance still has the MSDB database
  • Missing SQL Server Agent History
  • MSSQLTips Category – SQL Server Agent

Distribution

• Purpose – Primary data to support SQL Server replication
• Prominent Functionality
  • Database responsible for the replication meta data
  • Supports the data for transaction replication between the publisher and subscriber(s)
• Additional Information
  • MSSQLTips Category – Replication

ReportServer

• Purpose – Primary database for Reporting Services to store the meta data and object definitions
• Prominent Functionality
  • Reports security
  • Job schedules and running jobs
  • Report notifications
  • Report execution history
• Additional Information
  • MSSQLTips Category – Reporting Services

ReportServerTempDB

• Purpose – Temporary storage for Reporting Services
• Prominent Functionality
  • Session information
  • Cache
• Additional Information
  • MSSQLTips Category – Reporting Services

System Databases Do’s and Don’ts

• Data Access – Based on the version of SQL Server query only the recommended objects.  In general the system database objects are being deprecated to a set of views, so be sure all of your scripts are accessing the right objects.  If not, you are going to have a big project in the future to convert all of your scripts.
• Changing Objects – Do not change system objects.  In SQL Server 2005 all of the database objects have been moved to the Resource database which stores the definition for the system objects and can be updated via new SQL Server releases independent of the data.
• New Objects – Creating objects in the system databases is not recommended.  If you have objects that are needed for the instance i.e. administrative items, just create a separate DBA database to store these objects.
• Sneaking a Peak – Up to this point, all of the T-SQL code for the tables, views, stored procedures, functions, etc. has been clear text.  So you can review the objects and learn from the techniques used by Microsoft.
• Dropping Objects – The most prominent reason to drop system objects are for specific types of lock downs and auditing in particular industries.  Although some of those practices are well documented, be sure you understand the ramifications related to administering and developing applications once those restrictions are in place.
• Security – Do not forget about the Public role and Guest user, they are the conduit for users to access the system objects.  So that should answer the question of how people (logins\users) can access the objects based on the object owner or schema, depending on the SQL Server version.
• Backups – Be sure to have a consistent backup process for your system databases.  Including the system databases with your user defined databases might be the best approach if a disaster occurs.
• Scope – Each SQL Server instance (including the Express Edition) has its own set of SQL Server system databases.  As such, if a single Windows server has multiple SQL Server instances installed, a change to one system database only impacts the single instance, not all instances on the Windows server.

Next Steps

• Building your knowledge about the system databases is important to have a better understanding of how SQL Server works internally.
• Next time you see a script referencing a system object, dig a little deeper to learn about the object to expand your understanding of the script and how SQL Server works.
• Although system databases are databases, heed caution when working with them due to the potential impact the change could have across the instance.
• Check out these related tips:
  • Interview Questions – SQL Server System Databases