SQL Server System Databases

ProblemI 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.

SolutionHaving 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

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

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.

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.

Post a comment or let the author know this tip helped.

All comments are reviewed, so stay on subject or we may delete your comment. Note: your email address is not published. Required fields are marked with an asterisk (*).

*Name
*Email
Email me updates

Signup for our newsletter
I agree by submitting my data to receive communications, account updates and/or special offers about SQL Server from MSSQLTips and/or its Sponsors. I have read the privacy statement and understand I may unsubscribe at any time.

Thank you for the questions. System databases are defined by Microsoft and are needed for SQL Server to operate. These databases include Master, Model, MSDB, TempDB, Resource, Distribution database used in replication as well as the ReportServer and ReportServerTempDB databases used for Reporting Services.

User defined databases are created by DBAs or Developers for specific applications. These databases can support custom development or third party applications.

In terms of the different types of databases I am not exactly sure what you mean. You can have read-only databases versus read-write. There are databases for line of business needs, reporting, staging for a data warehouse, data warehousing, etc. Please let me know what you are looking for here and I will try to provide additional assistance.

After reading this article, I would like to appreciate you for making it very simple and understandable. It helped me lot. There is some good articles too which helped me in completing my task, here I'm sharing that articles posts....

http://msdn.microsoft.com/en-us/library/aa174522%28v=sql.80%29.aspx

http://mindstick.com/Blog/223/System%20Databases%20in%20SQL%20Server

I would like to say thanks everyoen for their nice contribution.

I agree by submitting my data to receive communications, account updates and/or special offers about SQL Server from MSSQLTips and/or its Sponsors. I have read the privacy statement and understand I may unsubscribe at any time.