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

Back Up Database TaskUsing 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 al

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.

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

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.

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

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