Brad’s Sure Guide to SQL Server Maintenance Plans- P47 docx

Figure 18.4: The schedule for Subplan_1 has been set.The next task is to create a second subplan, then add a second instance of the Back Up Database task to the new subplan, configure th

Figure 18.4: The schedule for Subplan_1 has been set.

The next task is to create a second subplan, then add a second instance of the Back Up Database task to the new subplan, configure the task to perform transaction log backups, and then to schedule the subplan appropriately To add a new subplan, click on the Add

Subplan icon in the Designer menu bar to bring up the Subplan Properties screen shown in

Figure 18.5

Figure 18.5: The Subplan Properties screen can use all default values, if you wish.

Here, you can enter your own custom name for the subplan, a useful description, and even add the schedule However, let's keep things simple and simply accept the default values and click OK The Maintenance Plan Designer screen should now list the newly-created subplan, with its default name of Subplan_2, as shown in Figure 18.6

Figure 18.6: Two subplans are now part of this Maintenance Plan.

Click on Subplan_2 to bring that subplan's design surface into focus, drag and drop another Back Up Database task onto it, and then configure it to perform transaction log backups When done, the screen should look as shown in Figure 18.7

Once the Back Up Database task has been added to the design surface of Subplan_2 and

configured, you can schedule it as required In this case, I schedule the subplan to run hourly, every day The final designer screen looks as shown in Figure 18.8

Figure 18.8: This Maintenance Plan, although oversimplified, is ready to run.

As you can see, adding subplans to a Maintenance Plan, and setting the schedule for each subplan, is not a difficult task However, as I mentioned in the introduction to the chapter,

my advice is to keep the number of subplans to a minimum Instead, place as many tasks as you can in a single subplan, and use precedence links to carefully control their execution

How to Use Precedence

Precedence is used within a subplan of Maintenance Plan in order to control what happens next in the subplan, based on the outcome of a preceding task In other words, it's the equivalent of adding conditional logic inside your Maintenance Plan to the effect that "if task

A succeeds, execute task B However, if task A fails, execute task C in place of task B." This powerful "green arrow" feature allows you much more control over your Maintenance Plans than is offered by the Maintenance Plan Wizard

Task Parallelism in the Designer

Designer also supports a feature called task parallelism (discussed later), which allows you to run two or more tasks in parallel Based on my experience, I don't recommend this option as it adds complexity, and could potentially cause performance problems if you accidently run two resource intensive maintenance tasks at the same time

The easiest way to understand how precedence works is to see it in action in a simple, but realistic example Let's say that we have a simple Maintenance Plan that consists of the following three tasks:

• Back Up Database

• Maintenance Cleanup

• Notify Operator

The Backup Database task should occur first, and will perform a full backup of the specified

database (AdventureWorks in this example) This is the precedent task and what happens

subsequent to the execution of this task will depend on its outcome If the Backup Database task succeeds, the Maintenance Cleanup task should immediately execute, our goal being

to preserve only the two most recent backup files on the local SQL Server, and delete any older backup (BAK) files If the Backup Database task should fail, we do not want to execute

the Maintenance Cleanup task because it may well be that we need the older backup files

to be easily accessible, if the reason the backup failed was because the database had become corrupted and a good backup of it could not be made It's always wise not to remove old backups from the local server until you're sure that more recent backups are "sound."

In addition, should the full backup fail, we want an e-mail to be sent to an operator so that a DBA can quickly check out what the problem is, and fix it In other words, if the Backup Database task fails, we want the next action to be the execution of the Notify Operator task

As discussed earlier, if you want to establish precedence between a given set of tasks, then each of the tasks must be part of the same subplan and design surface To start this example, let's drag and drop these three Maintenance Plan tasks onto the default subplan, as shown in Figure 18.9

Figure 18.9: Three Maintenance Plan Tasks have been dropped onto a design surface.

Before establishing the precedence of these tasks, the first step is to configure each one appropriately, depending on your needs I won't cover all the options again for each

individual task, so just configure each one as appropriate to our example, so that you have three configured tasks sitting on the surface, not as yet related to each other in any way Now it's time to establish a conditional relationship between them in order to achieve the stated goals of our example Let's tackle it one step at a time The Back Up Database task needs to run first followed by one of the two dependent tasks Assuming that the Back Up Database task succeeds, then we want the Maintenance Cleanup task to run In other words, we need to establish the precedence that the Back Up Database task runs first, and that the Maintenance Cleanup task runs second, assuming that the Backup Database task was successful In order to do this, click on the Backup Database task so that it has focus and then drag and drop the green arrow from that task directly onto the Maintenance Cleanup task The screen should now look as shown in Figure 18.10