Chapter 17: Configuring Maintenance Tasks Using the Designer 211 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 shows the task box for the Reorganize Index task, as dropped onto a design surface in its unconfigured state. Chapter 17: Configuring Maintenance Tasks Using the Designer 212 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. Chapter 17: Configuring Maintenance Tasks Using the Designer 213 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 remove one of the three types of file within any given Maintenance Plan. If you wanted to use the Maintenance Plan Wizard to delete all three types of files, you would have to suffer the Chapter 17: Configuring Maintenance Tasks Using the Designer 214 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. Chapter 17: Configuring Maintenance Tasks Using the Designer 215 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. Figure 17.19: The names of Maintenance Plan Tasks can be changed. . 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. 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. 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