Chapter 17: Configuring Maintenance Tasks Using the Designer 221 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. Chapter 17: Configuring Maintenance Tasks Using the Designer 222 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 shortly) you can associate the Notify Operator task with specific maintenance tasks in the Maintenance Plan, and so send e-mail reports to the designated operator on a task-by- task basis. Furthermore, you can specify more than one operator (without the use of e-mail groups). This adds a whole new level of flexibility and convenience. For example, let's say you have a Maintenance Plan that performs hourly transaction log backups. With the Wizard the poor, put-upon operator would receive an e-mail report every hour, which he or she would have to open and read to ensure the task completed successfully. With the Designer, you can configure the Notify Operator task to specify that the operator only receives an e-mail if the backup task fails, thus restricting e-mails to those occasions that require investigation and action. Chapter 17: Configuring Maintenance Tasks Using the Designer 223 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. Chapter 17: Configuring Maintenance Tasks Using the Designer 224 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. Don't confuse the Notify Operator task with standard reporting and logging options The Notify Operator task only sends e-mail messages that you have created. It does not send text file reports. If you remember from the Reporting and Logging section in Chapter 16, text file reports are set up using the Reporting and Logging button at the top right-hand side of the Designer. In most cases, you will probably want to have the Notify Operator task send you e-mails about failed tasks and, in addition, you will want to have text file reports written to disk, just in case you need to follow up when troubleshooting failed tasks. Chapter 17: Configuring Maintenance Tasks Using the Designer 225 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. . 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,. 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. 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