Brad’s Sure Guide to SQL Server Maintenance Plans- P43 doc

Shrink Database Task In Chapter 6, I explained why I strongly advise you avoid using the Shrink Database task found in the Maintenance Plan Wizard.. Execute SQL Server Agent Job Task As

Figure 17.12: The Update Statistics Task configuration settings.

Once again, these options are identical to those shown and described in the Configuring the Update Statistics Task section of Chapter 9, and so will not be covered again here.

Shrink Database Task

In Chapter 6, I explained why I strongly advise you avoid using the Shrink Database task found in the Maintenance Plan Wizard The exact same advice holds for the Shrink Database task in the Designer, so I won't be discussing it further here

Execute SQL Server Agent Job Task

As detailed in Chapter 10, the Execute SQL Server Agent Job task allows you to run one (and only one) predefined SQL Server Agent job as part of a Maintenance Plan The big advantage

of using this task in the Designer is that, while the Maintenance Plan Wizard only allowed you to create one of these tasks per plan, the Designer allows you to create multiple instances

of this task within the same plan, allowing you to include multiple jobs inside a plan

Figure 17.13: The Execute SQL Server Agent Job Task on the design surface.

Double-click on the task box to bring up the configuration screen, shown in Figure 17.14

Figure 17.14: The Execute SQL Server Agent Job Task configuration screen Your screen

will look very different because your SQL Server instance will have different jobs than my SQL Server instance Above, one job has been selected to run.

Yet again, these options are identical to those shown and described in the Configuring the Execute SQL Server Agent Job Task section of Chapter 10, and so will not be covered again here

History Cleanup Task

As discussed in Chapter 11, the History Cleanup task simply removes old data from the msdb database, which the SQL Server Agent uses to store various bits of information about the jobs it runs Figure 17.15 shows the task box for the History Cleanup task, as dropped onto a design surface

Figure 17.15: The History Cleanup Task on the design surface.

The configuration screen for this task is shown in Figure 17.16

Figure 17.16: The History Cleanup Task configuration screen.

For the final time in this chapter, I need to note that these options are identical to those

shown and described previously, in the Configuring the History Cleanup Task section of

Chapter 11, and so will not be covered again here

From here in, however, it gets a little more interesting Of the four remaining Maintenance Plan tasks, the first two are available from the Maintenance Plan Wizard, but work slightly differently within the Maintenance Plan Designer, while the second two are new to the Maintenance Plan Designer

Maintenance Cleanup Task

As discussed in Chapter 15, the Maintenance Cleanup task is designed to remove older backup (BAK and TRN) and text report (TXT) files that no longer need to be stored locally However, in the context of the Wizard, this task had a very serious limitation: you could only

inconvenience, and added complexity, of creating three separate Maintenance Plans, one to remove each of the three types of files

One of the compelling advantages of using the Maintenance Plan Designer is that it

allows you to create a single Maintenance Plan that contains multiple instances of the same Maintenance Plan task So, for example, we can add three different instances of the Maintenance Cleanup task to a single Maintenance Plan, and so delete all three types of older files in a single plan

Let's take a look at how we can do this Figure 17.17 shows the task box for the Maintenance Cleanup task, as dropped onto a design surface

Figure 17.17: The Maintenance Cleanup Task on the design surface.

As you can see, by default the task is configured to clean up backup files that are more than four weeks old We're going to want to execute three separate instances of this task, one to clean up old full and differential backup files (BAK), one to clean up old transaction log backup files (TRN) and one to clean up old text report (TXT) files Therefore, the first step is to drag and drop two additional instances of the Maintenance Cleanup task to the design surface, as shown in Figure 17.18

Figure 17.18: Multiple instances of Maintenance Cleanup Task on the design surface While

it may look like the green arrow is connecting the first two boxes, it is not.

In this example, I've dragged all three instances of the task onto the same design surface,

so they are all part of the same subplan, and will execute according to the single schedule established for that subplan If, for some reason, it was necessary to run one of the tasks on

a different schedule, then it would need to be moved to a different subplan We will take a deeper look at subplans in Chapter 18

In Figure 17.18, while it may look as if the first two task instances are connected by a green arrow, they are not If we wished to establish that these cleanup tasks should occur in a particular order, we would need to physically drag the arrow from the precedent task (at the start of the arrow) to any dependent task Establishing the order in which tasks execute in a subplan is often very important because, if you don't, all the tasks in the subplan will try to run at the same time

In this particular case, running all three of these tasks at the same time probably won't cause any problems, but in many other cases, running two or more tasks in the same subplan at the same time will cause problems, such as when you want to reorganize indexes and update statistics in the same subplan The only way for this to work is to set the Reorganize Index task as the precedent task, which will execute first, with the Update Statistics task being

a dependent task However, in this example, we will not set any precedence, so we can forget about the arrows for the time being

You'll notice, in Figure 17.18, that the Designer has assigned each instance of the task a subtly different name, in order to distinguish them However, our first goal is to rename them

in order to better identify what each instance is supposed to do To change the name of a Maintenance Plan task, right-click on the instance, select Rename, enter the new name,

and click OK When you're finished the design surface should look similar to that shown in

Figure 17.19