Performance Tuning with SQL Server Dynamic Management Views

Chapter 1: Using Dynamic Management Objects
In releases prior to SQL Server 2005, SQL Server exposed metadata in a range of
physical system tables, stored or referenced in the master database (e.g. master.dbo.
sysobjects or dbo.sysprocesses). Microsoft warned SQL DBAs and developers not
to code against the system objects, as they could not guarantee that they would not be
changed, or that they would even continue to be supported in future releases. However,
most DBAs did just that, and the sysprocesses system table, in particular, became the
"go-to" source of information when troubleshooting performance concerns in SQL
Server. This single table gave the DBA access to the spid (unique identifier for the user
session), cumulative CPU usage, memory, and I/O consumption, client connectivity
information (host name, host program name, login information, and process id) and
a myriad of other important columns that identified, at a quick glance, what was
transpiring on the SQL instance at any given time. Many of us rolled our own
management solutions and queries, based on sysprocesses, allowing us to dig into the
guts of SQL Server.
Microsoft realized the importance of these scripts, and knew that many DBAs relied on
them but, at the same time, wanted to introduce a layer of abstraction between the user
and their metadata. So, starting in SQL Server 2005, they moved the system tables from
the master database into the new resource database that is inaccessible to the enduser,
and even the DBA (there are techniques to access the resource database, if it is
really necessary, but we won't cover them here).
In their place, in the master database, Microsoft created a set of compatibility views,
based on the data in these, now hidden, system tables. These compatibility views are
structured identically to the original system tables they were replacing (column names,
data types, and column order remain constant), but they are now owned by the sys
schema. They were provided purely for backwards compatibility purposes; they do not
reflect any new features and functionality added in SQL Server 2005 and later. However,
with a simple schema change in any applicable code, they allowed DBAs to keep using
their existing set of troubleshooting scripts and tools.
At the same time, with SQL Server 2005, Microsoft introduced a new set of system
catalog views, as well as the DMOs, both of which also live in the master database, but
18