Brad’s Sure Guide to SQL Server Maintenance Plans- P49 pdf

241
Chapter 19: Create and Modify
Maintenance Plans Using the
Designer
It has been quite a long journey through the Designer to get to the point where we are ready
to design, create, test, and schedule a full Maintenance Plan.
In this chapter, we'll walk through the full process of creating from scratch, and deploying,
a Maintenance Plan that could be used to perform the following essential database
maintenance tasks:
• back up database data and log files
• run regular database integrity checks
• perform index rebuilds
• delete old data from the msdb database
• remove old backup and report files that are no longer required
to be stored on the local server
• notify the designated operator should one of the tasks fail.
While the example does perform many of the essential maintenance tasks, it's not intended
as a "template" for how to create Maintenance Plans, nor does it cover all the necessary
maintenance tasks. The exact nature of a Maintenance Plan will always depend on the exact
nature of your business and administration needs. You must establish exactly what your
Maintenance Plans need to achieve, and then implement them appropriately, using the
available options that best meet your needs.
Establishing Your Maintenance Goals
Before you can create a Maintenance Plan for your SQL Server instances, you have to
first establish what you want to accomplish. Based on established goals, the DBA must
create Maintenance Plans that include the appropriate tasks, appropriately configured and
scheduled, to meet these goals.
Chapter 19: Create and Modify Maintenance Plans Using the Designer
242
To some extent, these goals will be established at an organizational level. For example,
tolerance towards potential data loss should be established at a business level and on a

system-by-system basis. This, in turn, will dictate the DBA's maintenance policy in regard to
the nature and frequency of database backups in his or her Maintenance Plans. Elsewhere,
the nature of the plans will be guided by the DBA's knowledge of a given system, of its
databases, the data they contain, how that data is queried, how indexes are used, and so on.
However, all plans must start somewhere and, if you don't have all the information available
to make an informed decision, you'll need to create the plans using the data and knowledge
you do have available, and then monitor them. As your knowledge of a system grows, so
your plans can evolve and become more ecient. What's most crucial is that these essential
maintenance tasks do get performed on a regular basis.
Following is an example list of the objectives of a Maintenance Plan designed to maintain the
AdventureWorks database on a SQL Server instance.
• Once a day, use the Back Up Database task to perform a full backup on the
AdventureWorks database.
• Every hour, use the Back Up Database task to perform a transaction log backup
on the AdventureWorks database.
• Every Sunday, during a scheduled maintenance window, perform the following tasks:
• Run the Check Database Integrity task
• Run the Rebuild Index task
• Run the History Cleanup task, deleting files older than 1 week
• Run the Maintenance Cleanup task as follows:
• Delete BAK files older than 2 days
• Delete TRN files older than 2 days
• Delete report text files older than one week.
• If any of the previously listed tasks should fail, execute the Notify Operator task to
immediately send an e-mail that tells the operator what task failed.
• If any of the tasks fail, stop the execution of the Maintenance Plan so that any
subsequent tasks aren't executed. This means that the operator has the opportunity to
fix a problem before remaining tasks are executed.
Having established the identity and nature of the database maintenance tasks that need to be
carried out, we need to translate them into an actual Maintenance Plan.

Chapter 19: Create and Modify Maintenance Plans Using the Designer
243
Creating Maintenance Plans: the Big
Picture
While there are many ways in which to translate database maintenance goals into an actual
Maintenance Plan, I like to follow the ten steps below.
1. Create the new Maintenance Plan.
2. Create any necessary subplans.
3. Add the Maintenance Plan tasks to each subplan, as appropriate.
4. Configure each Maintenance Plan task.
5. Establish the necessary precedence links between tasks in a given subplan.
6. Define reporting and logging requirements.
7. Save the Maintenance Plan.
8. Test the Maintenance Plan.
9. Set the subplan schedules.
10. Run in production, and follow up.
While you don't have to follow these steps in this exact order (the Maintenance Plan Designer
is very flexible) I think you will find this particular order will help you manage the process
most effectively, when you are first starting out using the tool.
Create the New Maintenance Plan
Before we can do anything, we must first create a new Maintenance Plan using the
Maintenance Plan Designer. Right-click on Maintenance Plans, within the Management
folder of SSMS Object Explorer, and select New Maintenance Plan. Enter a descriptive name
in the New Maintenance Plan dialog box, and click OK. The new (empty) Maintenance Plan
is created, as shown in Figure 19.1, and we are ready to begin.
Chapter 19: Create and Modify Maintenance Plans Using the Designer
244
Figure 19.1: Once you have created the Maintenance Plan, you are now ready to build it.
In this example, the new plan is called AdventureWorks Maintenance Plan. Optionally, we
can add a description of this plan in the dialog box immediately below its name. Once this

initial step is completed, we are ready to create any subplans appropriate to the goals of our
Maintenance Plan.
Chapter 19: Create and Modify Maintenance Plans Using the Designer
245
Create the Subplans
As you may recall, the purpose of a subplan is to separate Maintenance Plan tasks into
different schedules, as required. So, how many subplans do we need to meet our database
maintenance goals? Did you guess right? We need three subplans, because our maintenance
goals include three different scheduling requirements.
• Once a day – for full database backups.
• Once an hour – for transaction log backups.
• Once a week – for all other database maintenance tasks.
Since there is already one default subplan, we need to create two more, so add these to
the Designer using the Add Subplan button in the menu bar. While your subplans will
automatically be assigned non-descriptive names, it is always wise to make each plan as
self-documenting as possible, as it will make it much easier for another DBA to review it and
understand how it works. Having created the extra subplans, and given all three subplans
descriptive names, the screen should look as shown in Figure 19.2.
Figure 19.2: Three subplans have been created
When you add subplans, they appear in the order that you create them, and you can't change
that order. Fortunately, this is not a problem, because each of these subplans operates on a
different schedule, so their order on the screen is irrelevant.
The presence of those calendar buttons next to each subplan may tempt you into assigning
the schedules now. However, resist the temptation. If you schedule the subplans, and then
subsequently save the unfinished plan (in order to preserve your progress), the underlying
SSIS packages and Agent jobs will be created, and SQL Server may attempt to start running
the scheduled jobs! Never schedule the subplans until the plan is complete and tested, and