Brad’s Sure Guide to SQL Server Maintenance Plans- P45 ppt

Chapter 17: Configuring Maintenance Tasks Using the Designer The Execution time out option on this screen is set to zero, which means that the T-SQL code you add can run as long as it ta

Chapter 17: Configuring Maintenance Tasks Using the Designer

The Execution time out option on this screen is set to zero, which means that the T-SQL code you add can run as long as it takes to complete If you want to prevent the code from taking an inordinate amount of time to run, you can set a value here, in seconds, which determines when the T-SQL code in this task times out, and the task is aborted Of course,

if your T-SQL code takes a long time to run, then it is probably not appropriate for use from within the Execute T-SQL Statement task

Another point to notice about this task is that you can't specify a database, as you can with most of the other Maintenance Plan tasks Because of this, this task is best suited to T-SQL code designed to run in any database, such as T-SQL code to run a custom form of the DBCC command, as described earlier Or, if you are a clever T-SQL coder, you can write code that can check for existing databases and, based on some criteria you specify, perform specific actions

You can write database-specific code if you want, but if you do, you should keep in mind that if you add or remove a database to a SQL Server instance you may break your code, requiring you to go back and modify the code to take into account the change in the

databases on the instance

Overall, if you have complex database maintenance needs that can only be satisfied using custom T-SQL then you may be better off creating your maintenance plans using custom T-SQL (or PowerShell) scripts in the first place The Maintenance Plan Designer is intended

to make database maintenance easier and faster; if you overcomplicate things by adding a lot

of custom T-SQL tasks, then you are defeating its very purpose

Notify Operator Task

The Notify Operator task is one of the main reasons why you may decide to create your Maintenance Plans using the Maintenance Plan Designer instead of the Maintenance Plan Wizard

What this simple task does is to notify a designated operator (or several operators) when a Maintenance Plan task within your Maintenance Plan fails, succeeds, or completes This adds

a very useful level of granularity and control to the basic reporting options available in the Maintenance Plan Wizard In the Wizard, a single screen is available, shown in Figure 17.26, which allows us to configure a text report to be sent to an individual operator (e.g a DBA) whenever a Maintenance Plan completes execution

Figure 17.26: This screen, from the Maintenance Plan Wizard, is the only way that it can

communicate with an operator.

While this is a great Wizard feature, it is also lacking in several important ways First, it works

at the plan level, so an e-mail is sent to the operator each time the plan is run This contains details of all the tasks that were run as part of that plan Just because an operator receives this e-mail doesn't mean that every step of the Maintenance Plan succeeded If part of a Maintenance Plan were to fail, it's possible that the report will still be sent (assuming there

is no major failure that prevents this), and the details of the failed step will be buried in the body of the report In other words, you have to actually read the report text file to find out that something failed Ask yourself: do I really want to read every e-mail sent to me by the Maintenance Plan Wizard to see if all the maintenance tasks inside it succeeded? The answer

is probably "No."

Via precedence links, with the Notify Operator task in the Designer (more on this very

Chapter 17: Configuring Maintenance Tasks Using the Designer

Of course, you can also configure the Notify Operator task to send an e-mail when a job succeeds, or if a job completes (whether it fails or succeeds) In other words, you have lots

of options

Using plan- and task-level reports

Alongside reports of success or failure at the task level, you'll still want to have the plan-level reports written to file, which will detail the execution of every task within every

subplan of your Maintenance Plan See the Reporting and Logging section in Chapter 16.

Furthermore, you can send the reports to multiple operators By sending e-mails to individual operators (rather than to an e-mail group) you can exploit the fact that each operator can be configured to include their duty schedule For example, operator A can receive and respond to failure reports when he or she is on duty, operator B when he or she is on duty, and so on

Creating and Configuring Operators

Remember that operators are created and configured as a SQL Server Agent task, as

described in Chapter 2

Now that you understand the potential of this task, let's take a closer look at it When you first drag and drop it onto the design surface, it looks as shown in Figure 17.27

Figure 17.27: This simple task is very powerful.

The task is configured via the screen shown in Figure 17.28

Figure 17.28: You can create custom e-mail messages to be sent to any selected

operator based on the success, failure, or completion of any task within a Maintenance Plan.

On this screen you can create custom e-mail messages to send to the designated operators,

by specifying the e-mail's subject and body text So, for example, let's say you want to create a Notify Operator task that sends you an e-mail message if a full backup fails In this case, you include text in the Notification message subject textbox and in the Notification message

body textbox, which makes it abundantly clear that it's a message about a failed backup This

way, when you do get e-mail messages, you will know exactly why you received the message The hard part is coming up with well-designed error messages for each separate task that can potentially fail In the next chapter, we will see an example of how to create your own custom e-mail notifications

Chapter 17: Configuring Maintenance Tasks Using the Designer

Now, given the previous discussion, I bet you are wondering how to configure the

Notify Operator task to send a specific e-mail when a particular Maintenance Plan task fails, succeeds, or completes? After all, these options don't seem to be visible on the

configuration screen

The secret lies in those green arrows that we've mentioned from time to time, and the subject

of precedence For example, let's say that if the Back Up Database task fails, you want an e-mail notification to be sent The first step is to create the Back Up Database task Next, you create a Notify Operator task Finally, you link the two tasks together using the green arrows that determine the precedence between them For example, if the Back Up Database task fails, the Notify Operator task will be executed, and the designated operator will then receive a customized e-mail alerting him or her to this fact

Never fear, precedence will be made clear and demonstrated in the very next chapter

Summary

As this point, you know the fundamentals of how to use the Maintenance Plan Designer and how to configure individual maintenance tasks Now, you may be thinking, how do I make this all fit into a larger Maintenance Plan that includes many different tasks?

Before we can get there, there are two very important features that have been mentioned several times but need to be explained in full detail: subplans and precedence The next chapter is dedicated to these topics After that, in the final chapter, we will be ready to tie all this knowledge together and use it to create a full Maintenance Plan, from beginning to end, using the Designer