Chapter 17: Configuring Maintenance Tasks Using the Designer 216 As you can see, the names I have assigned to each instance make it clear exactly what each instance of the task is supposed to do. In addition, note that I had to increase the width of each box in order to prevent the new names being truncated, and so defeating the purpose of assigning more descriptive names. Next, select the first task instance, which, in our example, is intended to clean up old BAK files, and bring up its configuration screen, as shown in Figure 17.20. Figure 17.20: The Maintenance Cleanup Task configuration screen. As you can see, the Maintenance Cleanup Task configuration screen is one we have seen before, in the Maintenance Plan Wizard, so I'll refer you to Chapter 15 for details of all the options. The goal is simply to configure each of the three Maintenance Cleanup task instances, one at a time, so that the first one deletes older BAK files, the second one deletes older TRN files, and the third one deletes older report TXT files. When you're done, you'll have a single plan that can perform all of the three required file cleanup operations. Chapter 17: Configuring Maintenance Tasks Using the Designer 217 Back Up Database Task Using the Maintenance Plan Wizard, the process of backing up database files involved configuring up to three separate tasks: • Back Up Database (Full) – a backup of all the data in a given database (see Chapter 12) • Back Up Database (Differential) – a backup of any data that has changed since the last full backup (see Chapter 13) • Back Up Database (Transaction Log) – a backup of the transaction log file (see Chapter 14) You won't find any of these three options in the Maintenance Plan Tasks Toolbox. Instead, you will find a single backup task, Back Up Database, which you can use to perform full, differential, and transaction log backups. Figure 17.21 shows the task box for the Backup Database task, as dropped onto a design surface. Figure 17.21: The Back Up Database Task handles full, differential, and transaction log backups. The Back Up Database task configuration screen is shown in Figure 17.22. Chapter 17: Configuring Maintenance Tasks Using the Designer 218 Figure 17.22: While we have seen this screen from the Maintenance Plan Wizard, one thing that is different is that now you can select a "Backup type" an option not available from the Wizard. This screen is identical to the backup screen found in the Maintenance Plan Wizard, with one exception: the Backup type option is now available (it was grayed out in the Wizard), as shown in Figure 17.23. Figure 17.23: The Back Up Database Task offers the option for full, differential, and transaction log backups. Chapter 17: Configuring Maintenance Tasks Using the Designer 219 So, when creating a backup scheme for your SQL Server instances, using Designer, you simply define multiple instances of the Back Up Database task, one for each type of backup you need to make. For example, if you needed to run full backups and transaction log backups on a given database (or set of databases), then you would create two instances of the Back Up Database task. Since these two tasks require very different schedules – for example, daily for full backups; but hourly, or even more frequently, for log backups – it is highly likely that you'll create each of the two task instances on a separate subplan, and assign it a separate schedule. Other than selecting the Backup type, configuring the Back Up Database task is the same in the Designer as it is in the Wizard, and you can find full details of the available options in Chapter 12. Execute T-SQL Statement Task Up to this point, all the Maintenance Plan Tasks we have covered are available from the Maintenance Plan Wizard, albeit with some small changes in a few cases. Now, we take a look at the first of two Maintenance Plan tasks that are only available when using the Maintenance Plan Designer. The Execute T-SQL Statement task allows you to run virtually any T-SQL code you want from within a Maintenance Plan. In many ways, it is similar to the Execute SQL Server Agent Job task in that it allows you to run custom T-SQL from within a Maintenance Plan. The main difference between these two is that the Execute T-SQL Statement task doesn't require that a separate SQL Server Agent job be created to run the T-SQL, as the T-SQL can be executed directly from this task. Execute T-SQL Statement versus Execute SQL Server Agent Job You might be thinking that if you can run the Execute T-SQL Statement task, why would you need to run the Execute SQL Server Agent Job task? One key difference between these two options is that the Execute T-SQL Statement task only runs T-SQL code, while the Execute SQL Server Agent Job task not only runs T-SQL code, but it also run ActiveX, PowerShell, and operating system scripts. With the ability to execute virtually any T-SQL from within a Maintenance Plan comes a great deal of flexibility. However, in order to exploit this task sensibly, you'll need to ensure firstly, that the custom T-SQL performs a useful task that makes sense in the context of the overall Maintenance Plan and secondly, that the T-SQL code itself is crafted correctly. Chapter 17: Configuring Maintenance Tasks Using the Designer 220 If used sparingly, the Execute T-SQL Statement task can be useful. For example, let's say that you want to perform a database integrity check on a database, but you find the options available with the Check Database Integrity task too limiting. In this case, you could write your own T-SQL statement that executed the DBCC CHECKDB command, using the exact parameters that meet your needs. If you decide to use the Execute T-SQL Statement task for such a purpose, then simply drag the task from the Toolbox, onto a design surface, as shown in Figure 17.24. Figure 17.24: The Execute T-SQL Statement Task is very powerful, but it can also be overkill. Configuring the task is easy; just add the required T-SQL code to the T-SQL statement box provided on the task configuration screen, shown in Figure 17.25. Figure 17.25: You can enter most any T-SQL command you want using the Execute T-SQL Statement task. Of course, you will first want to create and test the T-SQL using SSMS, before including it in this maintenance task. . similar to the Execute SQL Server Agent Job task in that it allows you to run custom T -SQL from within a Maintenance Plan. The main difference between these two is that the Execute T -SQL Statement. require that a separate SQL Server Agent job be created to run the T -SQL, as the T -SQL can be executed directly from this task. Execute T -SQL Statement versus Execute SQL Server Agent Job You might. Maintenance Plan tasks that are only available when using the Maintenance Plan Designer. The Execute T -SQL Statement task allows you to run virtually any T -SQL code you want from within a Maintenance