Microsoft SQL Server 2008 R2 Unleashed- P23 pps

ptg
174
CHAPTER 7 SQL Server System and Database Administration
TABLE 7.2 SQL Server 2008 Alternatives for SQL Server 2000 System Tables
SQL Server 2000
System Table
SQL Server 2008 System View View Type
sys.foreign_keys
Catalog view
syscurconfigs sys.configurations
Catalog view
sysdatabases sys.databases
Catalog view
sysdepends sys.sql_dependencies
Catalog view
sysdevices sys.backup_devices
Catalog view
sysfilegroups sys.filegroups
Catalog view
sysfiles sys.database_files
Catalog view
sysforeignkeys sys.foreign_keys
Catalog view
sysfulltextcatalogs sys.fulltext_catalogs
Catalog view
sysindexes sys.indexes
Catalog view
sys.partitions
Catalog view
sys.allocation_units
Catalog view

sys.dm_db_partition_stats
DMV
sysindexkeys sys.index_columns
Catalog view
syslanguages sys.syslanguages
Compatibility view
syslockinfo sys.dm_tran_locks
DMV
syslocks sys.dm_tran_locks
DMV
syslogins sys.sql_logins (transact-sql)
Catalog view
sysmembers sys.database_role_members
Catalog view
sysmessages sys.messages
Catalog view
sysobjects sys.objects
Catalog view
sysoledbusers sys.linked_logins
Catalog view
sysopentapes sys.dm_io_backup_tapes
DMV
sysperfinfo sys.dm_os_performance_counters
DMV
syspermissions sys.database_permissions
Catalog view
sys.server_permissions
Catalog view
sysprocesses sys.dm_exec_connections
DMV

Download from www.wowebook.com
ptg
175
System Views
7
TABLE 7.2 SQL Server 2008 Alternatives for SQL Server 2000 System Tables
SQL Server 2000
System Table
SQL Server 2008 System View View Type
sys.dm_exec_sessions
DMV
sys.dm_exec_requests
DMV
sysprotects sys.database_permissions
Catalog view
sys.server_permissions
Catalog view
sysreferences sys.foreign_keys
Catalog view
sysremotelogins sys.remote_logins
Catalog view
sysservers sys.servers
Catalog view
systypes sys.types
Catalog view
sysusers sys.database_principals
Catalog view
Catalog Views
Using catalog views is the preferred method for returning information used by the
Microsoft SQL Server database engine. There is a catalog view to return information about

almost every aspect of SQL Server. The number of catalog views is far too large to list here,
but you can gain some insight into the range of information available by looking at the
following list, which shows the categories of information covered by catalog views:
. Change Tracking
. Common language runtime (CLR) assembly
. Data spaces and full text
. Database mirroring
. Data spaces
. Endpoint
. Extended properties
. Linked servers
. Messages (for errors)
. Objects
. Partition function
. Resource Governor
. Scalar types
. Schemas
Download from www.wowebook.com
ptg
176
CHAPTER 7 SQL Server System and Database Administration
. Security
. Server-wide configuration
. Service Broker
. SQL Server Extended Events
. XML schemas (XML type system)
Some of the catalog views return information that is new to SQL Server 2008. Examples
include the Change Tracking and Resource Governor catalog views. Other catalog views
provide information that may have been available in prior versions through system tables,
system procedures, and so on, but the new catalog views expand on the information

returned and include elements that are new to SQL Server 2008.
To demonstrate the use of a catalog view, let’s compare a simple SQL Server 2000 SELECT
statement that returns object information to a SELECT statement in SQL Server 2008 that
returns similar information. The following example shows a SELECT statement written in
SQL Server 2000 to return any stored procedure created after a given date:
select o.crdate, o.name
from sysobjects o
where type = ‘p’
and crdate > ‘1/1/08’
order by crdate, name
Now, compare this SELECT statement to one that uses a SQL Server 2008 catalog view. The
sys.objects catalog view is a new alternative to the SQL Server 2000 sysobjects system
table. The following SELECT uses the sys.objects catalog view to return the same type of
information as the preceding example:
select o.create_date, o.modify_date, name
from sys.objects o
where type = ‘p’
and (create_date > ‘1/1/08’
or o.modify_date >= ‘1/1/08’)
order by 1, 2, 3
As you can see, the modify_date column has been added to the SELECT statement. This
column did not exist with the sysobjects system table. The addition of this column
allows you to identify objects that were created as well as objects that were modified or
altered.
Let’s look at an example of using a catalog view to return the same kind of information
returned in SQL Server 2000 with a system procedure. The handy sp_helpfile system
procedure returns information about database files associated with a given database. This
SQL Server 2000 procedure is still available in SQL Server 2008. An alternative to this
procedure is the new sys.master_files catalog view. This view returns all the information
that sp_helpfile returns and more. The following example shows a SELECT statement

Download from www.wowebook.com
ptg
177
System Views
7
using the sys.master_files catalog view to return the database files for the
AdventureWorks2008R2 database:
select *
from sys.master_files
where db_name(database_id) = ‘AdventureWorks2008R2’
You have the distinct advantage of being able to select the database files for all the data-
bases on your server by using this catalog view. You can also tailor your SELECT statement
to isolate database files based on the size of the database or the location of the physical
database files. For example, to return all database files that are found somewhere on your
C drive, you could use the following SELECT:
select db_name(database_id), physical_name
from sys.master_files
where physical_name like ‘c:\%’
There are plenty of catalog views that provide information about SQL Server. When you are
looking to return information about SQL Server components, you should look to the
catalog views first. These views provide a great deal of flexibility and allow you to isolate
the specific information you need.
Information Schema Views
Information schema views provide another system table–independent option for accessing
SQL Server metadata. This type of view was available in prior versions of SQL Server. Using
information schema views is a viable alternative for accessing SQL Server metadata from a
production application. The information schema views enable an application that uses
them to function properly even though the underlying system tables may have changed.
Changes to the underlying system tables are most prevalent when a new version of SQL
Server is released (such as SQL Server 2008), but changes can also occur as part of service

packs to an existing version.
The information schema views also have the advantage of being SQL-92 compatible.
Compliance with the SQL-92 standard means that SQL statements written against these
views work with other DBMSs that also adhere to the SQL-92 standard. The SQL-92 stan-
dard supports a three-part naming convention, which SQL Server has implemented as
database.schema.object.
In SQL Server 2008, all the information schema views are in the same schema, named
INFORMATION_SCHEMA. The following information schema views or objects are available:
. CHECK_CONSTRAINTS
. COLUMN_DOMAIN_USAGE
. COLUMN_PRIVILEGES
. COLUMNS
. CONSTRAINT_COLUMN_USAGE
Download from www.wowebook.com
ptg
178
CHAPTER 7 SQL Server System and Database Administration
. CONSTRAINT_TABLE_USAGE
. DOMAIN_CONSTRAINTS
. DOMAINS
. KEY_COLUMN_USAGE
. PARAMETERS
. REFERENTIAL_CONSTRAINTS
. ROUTINES
. ROUTINE_COLUMNS
. SCHEMATA
. TABLE_CONSTRAINTS
. TABLE_PRIVILEGES
. TABLES
. VIEW_COLUMN_USAGE

. VIEW_TABLE_USAGE
. VIEWS
When you refer to information schema views in a SQL statement, you must use a qualified
name that includes the schema name. For example, the following statement returns all
the tables and columns in a given database, using the tables and columns information
schema views:
select t.TABLE_NAME, c.COLUMN_NAME
from INFORMATION_SCHEMA.TABLES t
join INFORMATION_SCHEMA.COLUMNS c on t.TABLE_NAME = c.TABLE_NAME
order by t.TABLE_NAME, ORDINAL_POSITION
TIP
You can expand the Views node in a given database in the Object Explorer and open
the System Views node to see a list of the available information schema views. The
information schema views are listed at the top of the System Views node. If you
expand the Column node under each information schema view, you see the available
columns to select from the view. You can then drag the column into a query window for
use in a SELECT statement. You can also use IntelliSense in a query window determine
the columns.
Fortunately, the names of the information schema views are fairly intuitive and reflect the
kind of information they contain. The relationships between the information schema
views can be derived from the column names shared between the tables.
Download from www.wowebook.com
ptg
179
System Views
7
Dynamic Management Views
Dynamic management views (DMVs), which were introduced in SQL Server 2005, provide
a simple means for assessing the state of a server. These views provide a lightweight means
for gathering diagnostic information without the heavy burden associated with the tools

available in SQL Server 2000. The SQL Server 2000 diagnostic tools, such as heavy Profiler
traces, PerfMon, dbcc executions, and pssdiag, are still available, but oftentimes, the
information returned from the DMVs is enough to determine what may be ailing a SQL
Server machine.
An extensive number of DMVs are available in SQL Server 2008. Some DMVs are scoped at
the server level, and others are scoped at the database level. They are all found in the sys
schema and have names that start with dm_. Table 7.3 lists the different types of DMVs.
The DMVs in this table are categorized based on function as well as the starting characters
in the DMV names. The naming convention gives you an easy means for identifying the
type of each DMV.
TABLE 7.3 Types of DMVs
Category Name Prefix Information Captured
Auditing
dm_audit
New Auditing information
Service
Broker
dm_broker
Server Broker statistics, including activated tasks and connections
Change Data
dm_cdc
New Change Data Capture information
CLR
dm_clr
CLR information, including the CLR loaded assemblies
Cryptographic
dm_cryp
Security related data
TDE
dm_database

Transparent D ata Encr yption
Database
dm_db
Databases and database objects
Execution
dm_exec
Execution of user code
Full-Text
dm_fts
Full-Text Search information
I/O
dm_io
Input and output on network disks
Operating
system
dm_os
Low-level operating system information, including memory and
locking information
Provider
dm_provider
Extensible Key Management (EKM)
Query
Notification
dm_qn
Active Query Notification subscriptions
Replication
dm_repl
Replication information, including the articles, publications, and
transaction involved in replication
Download from www.wowebook.com

ptg
180
CHAPTER 7 SQL Server System and Database Administration
TABLE 7.3 Types of DMVs
Category Name Prefix Information Captured
Server
dm_server
Server Audit status
Transaction
dm_tran
Transactions and isolati on-leve l information
Object
dm_sql
Object References
Extended
Events
dm_xe
New event handling infrastructure
TIP
You can expand the Views node in a given database in the Object Explorer and open
the System Views node to see a list of the available DMVs. The DMVs are all listed
together and start with dm_. If you expand the Column node under each DMV, you see
the available columns to select from the view. You can then drag the column into a
query window to be included in a SELECT statement.
To illustrate the value of the DMVs, let’s look at a performance scenario and compare the SQL
Server 2000 approach to a SQL Server 2008 approach using DMVs. A common performance-
related question is “What stored procedures are executing most frequently on my server?”
With SQL Server 2000, the most likely way to find out is to run a Profiler trace. You must have
a Profiler trace that has already been running to capture the stored procedure executions, or
you must create a new trace and run it for a period of time to answer the performance ques-

tion. The trace takes time to create and can affect server performance while it is running.
With SQL Server 2008, you can use one of the DMVs in the execution category to
answer the same performance question. The following example uses the
sys.dm_exec_query_stats DMV along with a dynamic management function named
dm_exec_sql_text. It returns the object IDs of the five most frequently executed stored
procedures, along with the actual text associated with the procedure:
select top 5 q.execution_count, q.total_worker_time,
s.dbid, s.objectid, s.text
from sys.dm_exec_query_stats q
CROSS APPLY sys.dm_exec_sql_text (q.sql_handle) s
ORDER BY q.execution_count desc
The advantage of using a DMV is that it can return past information without having to explic-
itly create a trace or implement some other performance tool. SQL Server automatically caches
the information so that you can query it at any time. The collection of the data starts when
the SQL Server instance is started, so you can get a good cross-section of information. Keep in
mind that your results can change as the server continues to collect information over time.
Many of the performance scenarios such as those that relate to memory, CPU utilization,
blocking, and recompilation can be investigated using DMVs. You should consider using
Download from www.wowebook.com
ptg
181
System Views
7
DMVs to address performance problems before using other methods in SQL Server 2008.
In many cases, you may be able to avoid costly traces and glean enough information from
the DMV to solve your problem.
NOTE
Dynamic management functions return the same type of information as DMVs. The
dynamic management functions also have names that start with dm_ and reside in the
sys schema. You can find the dynamic management functions listed in the Object

Explorer within the master database. If you select Function, System Functions, Table-
Valued Functions, you see the dynamic management functions listed at the top.
DMVs are also a great source of information that does not relate directly to performance.
For example, you can use the dm_os_sys_info DMV to gather important server informa-
tion, such as the number of CPUs, the amount of memory, and so on. The following
example demonstrates the use of the dm_os_sys_info DMV to return CPU and memory
information:
select cpu_count, hyperthread_ratio, physical_memory_in_bytes
from sys.dm_os_sys_info
/* Results from prior select
cpu_count hyperthread_ratio physical_memory_in_bytes

2 2 2146357248
*/
The cpu_count column returns the number of logical CPUs, hyperthread_ratio returns
the ratio between physical CPUs and logical CPUs, and the last column selected returns
the physical memory on the SQL Server machine.
System Stored Procedures
System stored procedures have been a favorite of SQL Server DBAs since the inception of
SQL Server. They provide a rich set of information that covers many different aspects of
SQL Server. They can return some of the same types of information as system views, but
they generally return a fixed set of information that cannot be modified as you can when
using a SELECT statement against the system views. That is not to say that they are not
valuable; they are valuable, and they are particularly useful for people who have been using
SQL Server for a long time. System stored procedures such as sp_who, sp_lock, and sp_help
are tools for a database professional that are as basic as a hammer is to a carpenter.
System stored procedures have names that start with sp_, and they are found in the sys
schema. They are global in scope, which allows you to execute them from any database,
Download from www.wowebook.com
ptg

182
CHAPTER 7 SQL Server System and Database Administration
TABLE 7.4 Useful System Stored Procedures
System Stored
Procedure
Description
sp_configure
Displays or changes server-wide configuration settings.
sp_createstats
Creates statistics that are used by the Query Optimizer for all tables in a
database.
sp_help
Provides details about the object that is passed to it. If a table name is
passed to this procedure, it returns information on the columns,
constraints, indexes, and more.
sp_helpdb
If no parameters are supplied, returns relevant database information
(including the space used) for all the databases on an instance of SQL
Server.
without qualifying the stored procedure name. They also run in the context of the data-
base where you are working. In other words, if you execute sp_helpfile in the
AdventureWorks2008R2 database, the database files for the AdventureWorks2008R2 database
are returned. This same type of behavior exists for any stored procedure that is created in
the master database with a name that starts with sp_. For example, if you create a proce-
dure named sp_helpme in the master database and execute that procedure in the
AdventureWorks2008R2 database, SQL Server ultimately looks for and finds the procedure
in the master database.
NOTE
It is often useful to create your own system stored procedures to make it easier to exe-
cute complex queries against the system views (or to provide information not provided

by the built-in system procedures). For more information and tips on creating your own
system stored procedures, refer to Chapter 28, “Creating and Managing Stored
Procedures.”
System stored procedures are listed in the Object Explorer, in the Programmability node
within Stored Procedures and then System Stored Procedures. There are far too many
system stored procedures to list or discuss them all here. A quick check of the master
database lists more than 1,000 procedures. SQL Server Books Online provides detailed
help on these procedures, which it groups into 18 different categories.
Useful System Stored Procedures
You are likely to use only a handful of system stored procedures on a regular basis. What
procedures you use depends on the type of work you do with SQL Server and your capac-
ity to remember their names. Table 7.4 contains a sample set of system stored procedures
that you may find useful.
Download from www.wowebook.com
ptg
183
System Stored Procedures
7
Many of the administrative functions performed by SSMS can also be accomplished with
system stored procedures. Examples include procedures that start with sp_add and sp_delete,
which can be used to add and delete database objects. In addition, more than 90 system
stored procedures start with sp_help, which return help information on database objects.
TIP
You can use the sys.all_objects catalog view to search for available system stored
procedures. This catalog view lists objects that are schema scoped as well as system
objects. For example, the query SELECT * FROM sys.all_objects WHERE name LIKE
‘sp_help%’ returns all the system stored procedures that start with sp_help. You can
turn to Books Online for detailed help on any of the system stored procedures. Just
enter sp_ in the index search, and you see a list of them all.
Becoming familiar with some of the system stored procedures is well worth your while.

Using them is a very fast and effective means for gathering information from SQL Server.
They do not require the formation of a SELECT statement, and using them is often the
easiest way to get information via a query window.
Summary
Administering SQL Server can be a complex and time-consuming job. Understanding the
SQL Server internals and some of the easy ways to obtain information about a SQL Server
instance can make this job a lot easier. Taking the time to learn what makes SQL Server
tick expands your knowledge of this comprehensive DBMS and helps you make better
decisions when working with it.
Now that you know a bit about managing SQL Server, you may need to install an instance
of SQL Server to administer. Take a look at Chapter 8, “Installing SQL Server 2008,” which
guides you through the installation process.
TABLE 7.4 Useful System Stored Procedures
System Stored
Procedure
Description
sp_helpfile
Lists the database files associated with the database you are connected
to.
sp_lock
Displays current locking information for the entire SQL Server instance.
sp_spaceused
Provides the number of rows and disk space used by the table, indexed
view, or queue passed to it.
sp_who
Lists current processes that are connected to an instance of SQL Server.
Download from www.wowebook.com