Microsoft SQL Server 2008 R2 Unleashed- P22 pot

CHAPTER 7 SQL Server System and Database Administration return information about Change Tracking and the Resource Governor have been added to cover these new features.. TABLE 7.1 System

CHAPTER 6 SQL Server Profiler

any other data columns that make sense for your specific trace After this task is complete,

you can launch the sample stored procedure from Listing 6.5 and get progress information

via SQL Profiler as the procedure executes You can accumulate execution statistics over

time with this kind of trace and summarize the results The execution command for the

procedure follows:

EXEC SampleApplicationProc @debug = 1

The resulting SQL Profiler results are shown in Figure 6.15

There are many other applications for User configurable events How you use them

depends on your specific need As is the case with many Profiler scenarios, there are

seem-ingly endless possibilities

Summary

Whether you are a developer or database administrator, you should not ignore the power

of the SQL Profiler It is often one of the most underused applications in the SQL Server

toolkit, yet it is one of the most versatile Its auditing capabilities and ability to unravel

complex server processes define its value

This chapter wraps up the introduction to the tools and utilities available with SQL Server

Now you should be equipped to start administering and working with SQL Server

The chapters in the next section focus on the overall administration of SQL, using some of

the tools that you have been exposed to thus far Chapter 7, “SQL Server System and

Database Administration,” gives you some insight into the inner workings of SQL Server

and what it takes to effectively administer a SQL Server instance

FIGURE 6.15 User configurable trace results.

SQL Server System and

Database Administration

What’s New in SQL Server System and Database Administration System Administrator Responsibilities System Databases System Tables System Views System Stored Procedures

This chapter outlines the role of a SQL Server system

administrator and explores some of the methods that an

administrator can use to query important system data As

with any other job, understanding the roles and

responsibil-ities of the job is critical to doing the job well The

responsi-bilities of an administrator vary depending on the job, but

there are some core responsibilities covered in this chapter

You also need the right tools and right information to do

the job well and do it efficiently The system data covered

in this chapter provides some of the key information The

methods discussed to access this information are among

the tools you will need System data discloses information

that can be invaluable when assessing your SQL Server

environment and is an essential part of administering a

SQL Server database

What’s New in SQL Server System

and Database Administration

The means for accessing system information has changed

very little from SQL Server 2005 to SQL Server 2008 The

new systems views that were introduced in SQL Server 2005

are still the preferred means for getting at that all-important

system information These views, which include catalog,

compatibility, and dynamic views, are discussed in detail

later in this chapter

What is new in SQL Server 2008 is an expanded set of

system views These new views are geared toward some of

the new functionality offered with SQL Server 2008 For

example, new catalog and dynamic management views that

CHAPTER 7 SQL Server System and Database Administration

return information about Change Tracking and the Resource Governor have been added

to cover these new features

System Administrator Responsibilities

A system administrator is responsible for the integrity and availability of the data in a

database This is a simple concept, but it is a huge responsibility Some large corporations

place a valuation on their data as high as $1 million per 100MB The investment in dollars

is not the only issue; many companies that lose mission-critical data simply never recover

Job descriptions for system administrators vary widely In small shops, the administrator

might lay out the physical design, install SQL Server, implement the logical design, tune

the installation, and then manage ongoing tasks, such as backups At larger sites, tasks

might be broken out into separate job functions Managing users and backing up data are

common examples However, a lead administrator should still be in place to define policy

and coordinate efforts

Whether performed by an individual or as a team, the core administration tasks are as

follows:

Install and configure SQL Server

Plan and create databases

Manage data storage

Control security

Tune the database

Perform backup and recovery

Another task sometimes handled by administrators is managing stored procedures

Because stored procedures for user applications often contain complex Transact-SQL

(T-SQL) code, they tend to fall into the realm of the application developer However, because

stored procedures are stored as objects in the database, they are also the responsibility of

the administrator If an application calls custom stored procedures, the system

administra-tor must be aware of this and coordinate with the application developers

The system administration job can be stressful, frustrating, and demanding, but it is a

highly rewarding, interesting, and respected position As a system administrator, you are

expected to know all, see all, and predict all, but you should be well compensated for

your efforts

System Databases

SQL Server uses system databases to support different parts of the database management

system (DBMS) Each database plays a specific role and stores information that SQL Server

needs to do its job The system databases are much like the user databases created in SQL

Server They store data in tables and contain the views, stored procedures, and other

TABLE 7.1 System Databases and Their Associated Database Files

Database mdf Filename ldf Filename

resource mssqlsystemresource.mdf mssqlsystemresource.ldf

distribution distmdl.ldf distmdl.mdf

database objects that you also see in user databases They also have associated database

files (that is, mdf and ldf files) that are physically located on the SQL Server machine

Table 7.1 lists system databases and their related database filenames

TIP

You can use the sys.master_files catalog view to list the physical locations of the

system database files as well as the user database files This catalog view contains

a myriad of information, including the logical name, current state, and size of each

database file

The folder where each of these database files is located depends on the SQL Server

installa-tion By default, the installation process places these files in a folder named

<drive>:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\ You can move

these files after the installation by using special procedures that are documented in the

SQL Server Books Online topic “Moving System Databases.”

The following sections describe the function of each system database

The master database contains server-wide information about the SQL Server system This

server-wide information includes logins, linked server information, configuration

information for the server, and information about user databases created in the SQL Server

instance The actual locations of the database files and key properties that relate to each

user database are stored in the master database

SQL Server cannot start without a master database This is not surprising, given the type

of information that it contains Without the master database, SQL Server does not know

the location of the databases that it services and does not know how the server is

config-ured to run

The resource database contains all the system objects deployed with SQL Server 2008

These system objects include the system stored procedures and system views that logically

appear in each database but are physically stored in the resource database Microsoft

moved all the system objects to the resource database to simplify the upgrade process

When a new release of the software is made available, upgrading the system objects is

accomplished by simply copying the single resource database file to the local server

Similarly, rolling back an upgrade only requires overwriting the current version of the

resource database with the older version

You do not see the resource database in the list of system databases shown in SQL Server

Management Studio (SSMS) You also cannot add user objects to the resource database

For the most part, you should not be aware of the existence of the resource database It

has database files named mssqlsystemresources.mdf and mssqlsystemresources.ldf that

are located in the Binn folder, but you cannot access the database directly In addition,

you do not see the database listed when selecting databases using system views or with

system procedures, such as sp_helpdb

The model database is a template on which all user-created databases are based All

bases must contain a base set of objects known as the database catalog When a new

data-base is created, the model is copied to create the requisite objects Conveniently, objects

can be added to the model database For example, if you want a certain table created in all

your databases, you can create the table in the model database, and it is then propagated

to all subsequently created databases

The msdb database is used to store information for the SQL Server Agent, the Service

Broker, Database Mail, log shipping, and more When you create and schedule a SQL

Server Agent job, the job’s parameters and execution history are stored in msdb Backups

and maintenance plan information are stored in msdb as well If log shipping is

imple-mented, critical information about the servers and tables involved in this process is stored

in msdb

The distribution database, utilized during replication, stores metadata and history

infor-mation for all types of replication It is also used to store transactions when transactional

replication is utilized By default, replication is not set up, and you do not see the

distribution database listed in SSMS However, the actual data files for the distribution

database are installed by default

CHAPTER 7 SQL Server System and Database Administration

Refer to Chapter 19, “Replication,” for a more detailed discussion of the intricacies of

replication

The tempdb database stores temporary data and data objects The temporary data objects

include temporary tables, temporary stored procedures, and any other objects you want to

create temporarily The longevity of data objects in the temporary database depends on

the type of object created Ultimately, all temporary database objects are removed when

the SQL Server service is restarted The tempdb database is re-created, and all objects and

data added since the last restart of SQL Server are lost

tempdb can also be used for some of SQL Server’s internal operations Large sort operations

are performed in tempdb before the result set is returned to the client Certain index

opera-tions can be performed in tempdb to offload some of the space requirements or to spread

I/O SQL Server also uses tempdb to store row versions that are generated from database

modifications in databases that use row versioning or snapshot isolation transactions

Refer to Chapter 37 “Locking and Performance,” for a more detailed discussion of

transac-tion isolatransac-tion levels and row versioning

Maintaining System Databases

You should give system databases the same attention that you give your user databases

These databases should be backed up on a regular basis and secured in the event that one

of them needs to be restored All the system databases, with the exception of tempdb and

resource, can be backed up These same databases can also be restored to bring them back

to a previous state

NOTE

Although you cannot back up the resource database using SQL Server’s BACKUP and

RESTORE commands, you can make a backup copy of it by performing a file-based or

disk-based backup of the mssqlsystemresource.mdf file (SQL Server must not be

run-ning at the time) Likewise, you can manually restore a backup copy of the

mssqlsystemresource.mdf file only when SQL Server is not running You must be

careful not to overwrite the current resource database with a version for a different

release level of SQL Server

It’s important that you monitor the size of your system databases The amount of data

that accumulates in these databases can be significant This is particularly true for the

tempdb, msdb, and distribution databases Large sort or index operations can increase the

size of your tempdb database in a short period of time The msdb and distribution

data-bases contain a great deal of historical information Consider, for example, a server with

hundreds of databases that have log backups occurring every 15 minutes The information

captured for each individual backup is not significant, but the total number of databases

FIGURE 7.1 System tables listed in Object Explorer

and frequency of the backups cause many rows to be stored in the msdb database Cleanup

tasks and similar activities that remove older historical data can help keep the database

size manageable

System Tables

System tables contain data about objects in the SQL Server databases (that is, metadata) as

well as information that SQL Server components use to do their job Many of the system

tables are now hidden (in the resource database) and are no longer available for direct

access by end users In SQL Server 2008, compatibility views, which are discussed later in

this chapter, have the same names as the system tables available in SQL Server 2000 For

example, if you had a query in SQL Server 2000 that selected from syscolumns, this query

continues to work in SQL Server 2008, but the results come from a view instead of a

system table

The system tables that you can view are now found in some of the system databases, such

as msdb or master You can use the Object Explorer in SSMS to view the system tables in

these databases Figure 7.1 shows the system tables listed for the master database in the

Object Explorer

CHAPTER 7 SQL Server System and Database Administration

The most significant number of viewable system tables is found in the msdb system

data-base The system tables there support backup and restore, log shipping, maintenance

plans, Notification Services, the SQL Server Agent, and more You can retrieve a

tremen-dous amount of information from these system tables if you know what you are looking

for The following query selects from the system tables in msdb to report on recent restores

for the AdventureWorks2008R2 database:

select destination_database_name ‘database’, h.restore_date, restore_type,

cast((backup_size/1024)/1024 as numeric(8,0)) ‘backup_size MB’,

f.physical_device_name

from msdb restorehistory h (NOLOCK)

LEFT JOIN msdb backupset b (NOLOCK)

ON h.backup_set_id = b.backup_set_id

LEFT JOIN msdb backupmediafamily f (NOLOCK)

ON b.media_set_id = f.media_set_id

where h.restore_date > getdate() - 5

and UPPER(h.destination_database_name) = ‘AdventureWorks2008R2’

order by UPPER(h.destination_database_name), h.restore_date desc

One of the challenges with using system tables is determining the relationships between

them Some vendors offer diagrams of these tables, and you can also determine the

rela-tionships by reviewing the foreign keys on these tables and by referring to SQL Server

2008 Books Online, which describes the use for each column in the system table

CAUTION

Microsoft does not recommend querying system tables directly It does not guarantee

the consistency of system tables across versions and warns that queries that may

have worked against system tables in past versions may no longer work Catalog views

or information schema views should be used instead, especially in production code

Queries against system tables are best used for ad hoc queries The values in system

tables should never be updated, and an object’s structure should not be altered, either

Making changes to the data or structure could cause problems and cause SQL Server

or one of its components to fail

System Views

System views are virtual tables that expose metadata that relates to many different aspects

of SQL Server Several different types of views target different data needs SQL Server 2008

offers an extended number of system views and view types that should meet most, if not

all, your metadata needs

The available system views can be shown in the Object Explorer in SSMS Figure 7.2 shows

the Object Explorer with the System Views node highlighted There are far too many

views to cover in detail in this chapter, but we cover each type of view and provide an

example of each to give you some insight into their value Each system view is covered in

ptg CHAPTER 7 SQL Server System and Database Administration

FIGURE 7.2 System views listed in Object Explorer

detail in SQL Server Books Online, which includes descriptions of each column in the

view

Compatibility Views

Compatibility views were retained in SQL Server 2008 for backward compatibility Many

of the system tables available in SQL Server 2000 and prior versions of SQL Server are now

implemented as compatibility views These views have the same name as the system tables

from prior versions and return the same metadata available in SQL Server 2000 They do

not contain information that was added after SQL Server 2000

You can find most of the compatibility views in the Object Explorer by looking for system

views that have names starting with sys.sys For example, sys.syscolumns,

sys.syscomments, and sys.sysobjects are all compatibility views The first part of the

name indicates the schema that the object belongs to (in this case, sys) All system objects

are part of this sys schema or the INFORMATION_SCHEMA schema The second part of the

name is the view name, which corresponds to the name of a system table in SQL Server

2000

TIP

To see a list of compatibility views, use the index lookup in SQL Server 2008 Books

Online and look for sys.sys The index is placed at the beginning of a list of

compatibility views, starting with sys.sysaltfiles Objects in the list that are

compatibility views have the text compatibility view following the object name, so

you can easily identify them and get help

You also can use the new IntelliSense feature available with SQL Server 2008 to

obtain information about the compatibility views and other system views Simply open a

query window in SSMS and start typing a SELECT statement When you start typing the

name of the view that you want to select from (for example, sys.) the IntelliSense

drop-down appears listing the views that start with the letters sys You can also

deter-mine the columns available from the view by referencing the view or alias for the view

in the column selection list When you enter the period following the view or alias, the

IntelliSense drop-down shows you the available columns

You should transition from the use of compatibility views to the use of other system

views, such as catalog views The scripts that were created in SQL Server 2000 and

refer-ence SQL Server 2000 system tables should continue to function in SQL Server 2008, but

this capability is strictly for backward compatibility Table 7.2 provides a list of SQL Server

2000 system tables and alternative SQL Server 2008 system views you can use instead

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

sysaltfiles sys.master_files Catalog view

syscacheobjects sys.dm_exec_cached_plans DMV

sys.dm_exec_plan_attributes DMV sys.dm_exec_sql_text DMV syscharsets sys.syscharsets Compatibility view

syscomments sys.sql_modules Catalog view

sysconfigures sys.configurations Catalog view

sysconstraints sys.check_constraints Catalog view

sys.default_constraints Catalog view sys.key_constraints Catalog view