Microsoft SQL Server 2008 R2 Unleashed- P115 ppsx

ptg
1084
CHAPTER 33 Database Maintenance
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.
Download from www.wowebook.com
ptg
1085
Managing Maintenance Plans Without the Wizard
33
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.
Download from www.wowebook.com
ptg
1086
CHAPTER 33 Database Maintenance
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.
Download from www.wowebook.com
ptg
1087
Managing Maintenance Plans Without the Wizard
33
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.
Download from www.wowebook.com
ptg
1088
CHAPTER 33 Database Maintenance
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.
Download from www.wowebook.com
ptg
1089
Maintenance Without a Maintenance Plan
33
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.
Download from www.wowebook.com
ptg
1090
CHAPTER 33 Database Maintenance
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.
Download from www.wowebook.com
ptg
CHAPTER 34
Data Structures, Indexes,
and Performance
IN THIS CHAPTER
. 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.
Download from www.wowebook.com
ptg
1092
CHAPTER 34 Data Structures, Indexes, and Performance
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.”
Download from www.wowebook.com
ptg
1093
Database Files and Filegroups
34
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.
Download from www.wowebook.com