Brad’s Sure Guide to SQL Server Maintenance Plans- P48 pot

Chapter 18: Subplans and Precedence 236 Figure 18.10: Notice that the green arrow starts at the Backup Database Task and points at the Maintenance Cleanup task. The arrow always must originate at the precedent task, Back Up Database, which will execute first, and terminate at the dependent task, Maintenance Cleanup, which will execute second, depending on any imposed conditions. The conditions are imposed inside the precedence arrow itself and, in fact, the green color of this arrow in Figure 18.10 indicates that the arrow is, by default, imposing an "on success" condition on the execution of the Maintenance Cleanup task. In other words, the condition can be expressed as follows: "On success of the backup task, execute the cleanup task." How do we verify this? If you right-click on the green line and then select "Edit," or double-click on the green line, the Precedence Constraint Editor screen appears, as shown in Figure 18.11. Chapter 18: Subplans and Precedence 237 Figure 18.11: The Precedence Constraint Editor is used to help you establish the types of precedence that are available. There are quite a few options on this screen, but it turns out that we can ignore most of them. The Precedence Constraint Editor screen looks more complicated than it really is, because it includes options that aren't really applicable to creating Maintenance Plans. Like much of the code used by the Maintenance Plan Designer, it is reused in different parts of SSMS, and so certain options are presented out of context. For example, the Expression option, available as an Evaluation operation, is really designed to create SSIS packages, not Maintenance Plans. The only option with which we really need to be concerned is Value. By default, Success is selected in the drop-down list and this is the origin of the green color of the arrow in Figure 18.10. Only if the Back Up Database task executes successfully will the Maintenance Cleanup task execute. There are two other options available in the Values drop-down list, namely Failure and Completion, as shown in Figure 18.12. Figure 18.12: We need only focus on three Values. Chapter 18: Subplans and Precedence 238 To impose an "on failure" condition, simply select Failure from the list and the resulting precedent arrow will be red. To impose an "on completion" condition, select Completion, and the resulting arrow will be blue. The Completion condition stipulates that the dependent task should run as soon as the precedent task completes execution, regardless of whether it succeeded or failed. In most cases, you will find the success and failure conditions more useful. So far, we have only implemented half of our required logic. At the moment, if the backup task succeeds, the cleanup task will be executed. However, if the backup task fails, we want this event to immediately send a notification e-mail to the DBA (operator), via execution of the Notify Operator task. To do this, first click on the Back Up Database task so that it is selected (in focus), and a second green arrow appears on the Back Up Database task box, as shown in Figure 18.13. Figure 18.13: A task can have multiple precedence arrows. Once the second green arrow is displayed, drag and drop it on to the Notify Operator task box on the design surface, as shown in Figure 18.14. Chapter 18: Subplans and Precedence 239 Figure 18.14: Now the Back Up Database Task has two precedence arrows. As it stands now, in Figure 18.14, if the backup task succeeds then both the cleanup task and the notification task will be executed at the same time. Earlier, I referred to task parallelism, and recommended that you not use it, due to the complexity, and potential performance issues it brings; and it is not the desired behavior in this example. We need to change the existing green (success) between the Backup Database task and the Notify Operator task to a red (failure) arrow so that precedence replaces task parallelism. To do this, double-click on the arrow leading to the Notify Operator task, change the Value to Failure and click OK. This will impose the required "on failure" condition and change the green to a red arrow, as shown in Figure 18.15. Figure 18.15: The red arrow represents failure. Chapter 18: Subplans and Precedence 240 We are now done. If the Back Up Database task executes successfully, the Maintenance Cleanup task will be executed. If the Back Up Database task fails, then the Maintenance Cleanup task will not execute. Instead, the Notify Operator task will execute, sending an e-mail message to the designated operator. Summary Subplans are a necessary and useful feature, although I recommend you use them as sparingly as possible in order to avoid overcomplicating your Maintenance Plans. Precedence is a very powerful tool, assuming that it is correctly used. It allows you to add logic to your Maintenance Plans, and include error-trapping, of sorts. In the next (and final) chapter, where we create an entire Maintenance Plan from scratch, we investigate additional examples of how precedence can be used. . Notify Operator task to a red (failure) arrow so that precedence replaces task parallelism. To do this, double-click on the arrow leading to the Notify Operator task, change the Value to Failure. the backup task fails, we want this event to immediately send a notification e-mail to the DBA (operator), via execution of the Notify Operator task. To do this, first click on the Back Up Database. referred to task parallelism, and recommended that you not use it, due to the complexity, and potential performance issues it brings; and it is not the desired behavior in this example. We need to