Microsoft SQL Server 2008 R2 Unleashed- P23 pps

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 sy

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

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

syslogins sys.sql_logins (transact-sql) Catalog view

sysmembers sys.database_role_members 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

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

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

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

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

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

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 Data Encryption

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

TABLE 7.3 Types of DMVs

Category Name Prefix Information Captured

Server dm_server Server Audit status

Transaction dm_tran Transactions and isolation-level 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

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 -2146357 -248

*/

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,

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

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