Microsoft SQL Server 2008 R2 Unleashed- P115 ppsx

Managing Maintenance Plans Without the Wizard You can create or modify maintenance plans in SQL Server 2008 without using the Maintenance Plan Wizard.. The plan designer surface on the D

Managing Maintenance Plans Without the Wizard

You can create or modify maintenance plans in SQL Server 2008 without using the

Maintenance Plan Wizard To create a new maintenance plan without the wizard, you

right-click the Maintenance Plan node in the Object Explorer and select New

Maintenance Plan You are prompted for a maintenance plan name and then taken to the

Design tab for the maintenance plan The Design tab consists of a properties section at the

top of the screen and a plan designer surface that is empty for a new maintenance plan

Existing maintenance plans are displayed in the Design tab when you right-click the plan

and select Modify Figure 33.13 shows the Design tab for a maintenance plan that was

created with the Maintenance Plan Wizard to back up the system databases

The Design tab represents a significant difference from the way maintenance plans were

managed in SQL Server 2000 The plan designer surface on the Design tab has

drag-and-drop capabilities that allow you to add maintenance tasks to your plan The available tasks

are located in the Toolbox component The Toolbox and the related tasks are shown in

Figure 33.13 in the middle portion of the screen To add a tool from the Toolbox, you drag

the item from the Toolbox to the plan designer surface Alternatively, you can double-click

the task, and the task appears on the plan designer surface

FIGURE 33.13 The maintenance plan Design tab

On the plan designer surface, you can move each of the tasks around, link them to other

tasks, and edit them by double-clicking them You can also right-click a task to edit it,

group it with other tasks, autosize it, and gain access to other task options You can

right-click an empty section of the plan designer surface to add annotations or comments that

provide additional information about the task or the overall plan

NOTE

The dialog boxes displayed when you edit a task are unique for each task The

avail-able maintenance plan tasks display an options screen like the one displayed during

the execution of the Maintenance Plan Wizard This provides consistency that is in

place regardless of where the task is defined

Adding a task to an existing maintenance plan is a good starting point to become familiar

with the workings of the Design tab Consider, for example, the maintenance plan shown

in Figure 33.13 This plan, which was initially created with the Maintenance Plan Wizard,

is used to create full database backups of all the system databases One critical aspect that

is missing from this plan is a task to remove older database backups The task that can

help you with this is the Maintenance Cleanup task If you double-click that task in the

Toolbox, the task is added to the plan designer surface, as shown in Figure 33.14

FIGURE 33.14 Adding a task to the plan designer surface

After you add a task to the plan designer surface, you need to configure it Note that a

small red X icon appears on the right side of the task if the task has not yet been

config-ured To configure the Maintenance Cleanup task, you double-click it on the plan designer

surface Figure 33.15 shows the screen that appears so you can configure the Maintenance

Cleanup task

You can use the Maintenance Cleanup task to clean up old backup files or maintenance

plan text reports The deletion of older backup files is particularly important because

data-base backups tend to be large files and can use up a significant amount of disk space The

File Location section of the screen enables you to delete a specific file, or you can delete

files in a folder based on search criteria In most cases, you want to search the folder to

delete older files

When cleaning up database backup files, you typically specify the file extension bak If

you chose to write each database’s backups to a separate folder, you should choose the

Include First-Level Subfolders options, which allows you to search all first-level subfolders

that exist under the folder specified This simplifies the cleanup process and eliminates the

need to have a separate cleanup task for each subfolder

In the last section of the configuration screen for the Maintenance Cleanup task, you

specify how old a file must be in order to be deleted The default is four weeks, but you

FIGURE 33.15 Configuring the Maintenance Cleanup task

can adjust this setting to the desired time frame by using the related drop-downs If you

uncheck Delete Files Based on the Age of the File at Task Run Time, all files in the folder

or subfolders are deleted, regardless of age

NOTE

The deletion of database backup files is not based on the file dates or the name of the

backup file The Maintenance Cleanup task uses a procedure named xp_delete_file

that examines the database backup and time the backup was created Renaming the

database backup file does not affect its inclusion in the deletion process

After configuring the options for the Maintenance Cleanup task, you can click the View

T-SQL button at the bottom of the screen This feature reveals what is going on behind the

scenes when the plan executes Prior to SQL Server 2005, you had to obtain this kind of

information by using the Profiler

When you click OK, the task is ready to use in the maintenance plan The task runs in

parallel with the other tasks defined in the plan unless a precedence or link is established

between the tasks To establish a link between the tasks, you select the first task that you

want to execute When the task is selected, a green arrow is shown at the bottom of the

task’s box in the plan designer surface You click the green arrow and drag it to the task

that you want to run next The green arrow is then connected to the other task If you

double-click the green arrow (or right-click and choose Edit), the Precedence Constraint

Editor appears, as shown in Figure 33.16

The paragraph at the top of the Precedence Constraint Editor gives a good description of

what a precedence constraint is In short, it can link tasks together based on the results of

their execution For example, if a backup database task succeeds, a Maintenance Cleanup

FIGURE 33.16 The Precedence Constraint Editor

task can be defined to run next You can also set the constraint value so that the next task

will run only if the first task fails, or you can have the next task run based on the prior

task’s completion, regardless of whether if succeeds or fails In addition, you can link

multiple tasks together with precedence You define the logical relationship between tasks

in the Multiple Constraints section of the Precedence Constraint Editor

The workflow and relationships that can be defined between tasks for a maintenance plan

are extensive and beyond the scope of this chapter Many of the workflow concepts are

similar to those of the DTS designer in SQL Server 2000 and the SSIS designer in SQL

Server 2008

Executing a Maintenance Plan

Maintenance plans that have been scheduled run automatically according to the schedule

defined You can also run maintenance plans manually by right-clicking a maintenance

plan and selecting Execute or by selecting the SQL Server Agent job associated with the

maintenance plan and starting the job The execution behavior is different, depending on

the means you use If you choose to run the maintenance plan from the Management node,

the SSIS package is launched, and the Execute Maintenance Plan window displays the

current status of the plan execution

If you run the SQL Server Agent job to execute the maintenance plan, a dialog box

indi-cating the execution status of the job appears The dialog does not indicate success for the

maintenance plan until the entire maintenance plan has completed The dialog box for

the job can be closed, and the job will still continue to run The Execute Maintenance

Plan window, on the other hand, does not have an option to close it, and it must stay

open until the plan completes

There are two other means for monitoring the execution of maintenance plans The Job

Activity Monitor shows a status of executing while a maintenance plan is executing You

can set the refresh settings on the Job Activity Monitor to auto-refresh for the desired

increment You can also monitor the execution by establishing a connection to the SSIS

server in SSMS To establish an SSIS connection in SSMS, you click the Connect

drop-down in the Object Explorer and choose Integration Services Figure 33.17 shows an

example of the Object Explorer with an Integration Services connection

The Integration Services connection in the Object Explorer shows the packages that are

running in addition to the packages that have been created If you expand the Stored

Packages node and navigate to the MSDB node, you see a node named Maintenance Plans

that shows all the SSIS packages that have been created You can also edit the package

with BIDS, but that topic is beyond the scope of this chapter See Chapter 52 for more

information

FIGURE 33.17 The Object Explorer with an Integration Services connection

NOTE

SSIS does not need to be installed on the SQL Server machine to be able to create

and execute maintenance plans In the initial release of SQL Server 2005, this was a

requirement but was changed with SQL Server 2005 SP2 This change carried over to

SQL Server 2008, and maintenance plans are now fully functional with the SQL Server

Database Services installation

Maintenance Without a Maintenance Plan

You can perform database maintenance without the use of the built-in maintenance plans

that come with SQL Server The additional complexity in SQL Server 2008 may steer some

people away from the use of these plans In addition, these plans cannot be scripted, so

deployment to multiple environments is not straightforward

Database maintenance that is performed without a maintenance plan is often performed

using custom scripts or stored procedures that execute the T-SQL commands to perform

the maintenance Other methods include manually executing the SQLMAINT utility to

perform various maintenance tasks such as database backups and consistency checks

Often these maintenance commands or custom scripts are then scheduled to run on a

regular basis by manually setting up jobs within the SQL Server Agent job scheduler in

SQL Server Management Studio (For more information on setting up and scheduling jobs

in SQL Server Agent, see Chapter 16, “SQL Server Scheduling and Notification.”)

Setting up maintenance tasks manually is a viable option, especially for the more

experi-enced DBA because it requires additional development work and familiarity with the

maintenance commands and options However, even the experienced DBA should

consider using maintenance plans because maintenance tasks set up manually may lack

the integration with other SQL Server components that is offered with the SQL Server

2008 maintenance plans

Database Maintenance Policies

Policy-Based Management, a new management feature introduced in SQL Server 2008,

allows you to manage your SQL Server instances through clearly defined policies, reducing

the potential for administrative errors or oversight The policy-based framework

imple-ments the policies you defined via a Policy Engine, SQL Server Agent jobs, SQLCLR, DDL

triggers, and Service Broker You can choose to have the policies you defined be applied or

evaluated against a single server or a group of servers, thus improving the scalability of

monitoring and administration

Policy-Based Management allows you to prescribe the way you want your databases

main-tained, and the system will help ensure things stay that way Essentially, Policy-Based

Management allows you to define rules for one or more SQL Servers and evaluate them

The goal of this feature is to make it easier for you to manage one or more servers by

noti-fying you when servers are out of compliance with the database maintenance policies you

have defined

For example, you could define a policy to ensure that transaction log backups are being

performed on the appropriate intervals on your OLTP databases Policy-Based

Management allows you to determine when one of your databases is not in compliance

with your log backup policy You can set up this policy to be evaluated on demand or via

a schedule

For more information on defining and using policies, see Chapter 22

Summary

Establishing a database maintenance plan is important Just like your car or your home, a

database needs maintenance to keep working properly The powerful features available

with the SQL Server 2008 maintenance plans and Maintenance Plan Wizard make the

creation of a robust maintenance plan relatively easy If you establish your maintenance

plans early in the life of your databases, you will save yourself time and aggravation in

the long run

Chapter 34 delves further into the importance of indexes and their relationship to

perfor-mance It expands on the optimization of indexes mentioned in this chapter and describes

the role that indexes play in keeping databases running fast

Data Structures, Indexes,

and Performance

What’s New for Data Structures, Indexes, and Performance

Understanding Data Structures

Database Files and Filegroups

Database Pages

Understanding Table Structures

Understanding Index Structures

Data Modification and Performance

Index Utilization

Index Selection

Evaluating Index Usefulness

Index Statistics

SQL Server Index Maintenance

Index Design Guidelines

Indexed Views

Indexes on Computed Columns

Filtered Indexes and Statistics

Choosing Indexes: Query Versus Update Performance

Identifying Missing Indexes

Identifying Unused Indexes

A number of factors affect SQL Server performance One

of the key factors is your table and index design; poor table

and index design can result in excessive I/O and poor

performance To aid in developing a good table and index

design in an effort to improve SQL Server performance by

minimizing I/O, you need to have a good understanding of

SQL Server data structures and indexes

Proper table and index design is a key issue in achieving

optimum SQL Server application performance For example,

you can often realize substantial performance gains in your

SQL Server applications by creating the proper indexes to

support the queries and operations being performed At the

same time, it’s important to keep in mind that although

many indexes on a table can help improve response time

for queries and reports, too many indexes can hurt the

performance of inserts, updates, and deletes due to the

overhead required to maintain the index and data rows

Additionally, other index design decisions, such as which

column(s) to create a clustered index on, might be

influ-enced as much by how the data is inserted and modified

and what the possible locking implications might be as they

are by the query response time alone

In this chapter, you learn about the underlying structures of

databases, tables, rows, and indexes and how SQL Server

maintains index and data structures because this

informa-tion provides a basis for understanding the performance of

your tables and indexes This chapter discusses the storage

structures in SQL Server and how these storage structures are

maintained and managed The chapter also discusses how

SQL Server evaluates and uses indexes to improve query

response time Using this information, you should have a

better understanding of the issues and factors that influence

good table and index design

What’s New for Data Structures, Indexes, and

Performance

SQL Server 2008 provides a number of new features related to data structures, indexes,

and performance

Among these new features are filtered indexes and statistics Filtered indexes utilize a WHERE

clause that filters or limits the number of rows included in the index The smaller filtered

index allows queries run against rows containing data values in the index to run faster

These filtered indexes can also save on the disk space used by the index A well-designed

filtered index can improve query performance, reduce index maintenance costs, and

reduce index storage costs compared with full-table indexes

Also new to SQL Server 2008 is the capability to compress data in indexes and tables to

reduce the amount of storage space required and, in turn, reduce the I/O needed for these

objects Page-level data compression helps to reduce both storage and memory requirements

as the data is compressed both on disk and when brought into the SQL Server data cache

Row-level compression isn’t true data compression but implements a more efficient storage

format for fixed-length data

Other storage features introduced in SQL Server 2008 to reduce storage space requirements

are sparse columns and column sets Sparse columns are ordinary columns that use an

opti-mized storage format for NULL values

FILESTREAM storage was also introduced in SQL Server 2008 as a new storage mechanism

for binary large object (BLOB) data FILESTREAM storage is a property that can be applied

to varbinary(max) columns and enables SQL Server applications to store unstructured

data, such as documents and images, directly in the NTFS file system while still

maintain-ing the behavior of a database column The advantages of FILESTREAM storage are

improved performance and increased size of BLOB data, expanding from the 2GB limit of

image columns to the available space in the file system

Spatial indexes are new to SQL Server 2008 as well These indexes are used against spatial

data defined by coordinates of latitude and longitude The spatial data is essential for

effi-cient global navigation The spatial indexes are grid-based and help optimize the

perfor-mance of searches against the spatial data

NOTE

This chapter assumes that you already have an understanding of the different types of

indexes and how to define them For more information on index types and how to

cre-ate indexes, see Chapter 25, “Creating and Managing Indexes.”

Understanding Data Structures

SQL Server DBAs and users do not see data and storage the same way SQL Server does A

DBA or end user sees a database more logically as the following:

Databases, physically stored in files

Tables and indexes, placed in filegroups within databases

Rows, stored in tables

SQL Server internally sees these storage structures at a lower, physical level as

Databases, physically stored in data and log files

Pages within these files, allocated to tables and indexes

Data and index rows, stored in slots on pages

Database Files and Filegroups

Databases in SQL Server 2008 span at least two, and optionally several, database files There

must always be at least one file for data and one file for the transaction log These database

files are normal operating system files created in a directory within the operating system

These files are created when the database is created or when a database is expanded

Each database file has the following set of properties:

A logical filename—This name is used for internal reference to the file.

A physical filename—This name is the actual physical pathname of the file.

An initial size—If no size is specified for primary data file, its initial size, by

default, is the minimum size required to hold the contents of the model database

An optional maximum size—A maximum file size limit can be specified.

A file growth increment—This amount is specified in megabytes or as a

percentage

The information and properties about each file for a database are stored in the database

visible via the system catalog view called sys.database_files This view exists in every

database and contains information about each of the database files The master database

contains a similar view, sys.master_files, that contains file information for all databases

within the SQL Server instance Table 34.1 lists the most useful columns in the

sys.database_files view