Microsoft SQL Server 2008 R2 Unleashed- P53 ppt

ptg 464 CHAPTER 16 SQL Server Scheduling and Notification TIP The Retry options are useful for polling scenarios. For example, you might have a job step that tests for the existence of a file during a given period of the day. The job can be scheduled to start at a time of day when the file is expected. If the file is not there and the step fails, Retry Attempts can be set to poll again for the file. Retry Interval determines how often it retries, and the combination of Retry Attempts and Retry Interval determines the total polling window. For example, if you want to check for the file for 2 hours, you can set Retry Attempts to 24 with a Retry Interval of 5 minutes. If the job step fails more than the number of retries, the step completes in failure. The last set of options on the Advanced page relate to the output from the job step. Job step output can be saved to an output file that can be overwritten each time the job step is run, or the output can be appended each time. The Log to Table option writes the job step output to the sysjobstepslogs table in the msdb database. The table contains one row for each job step with the Log to Table option enabled. If Append Output to Existing Entry in Table is enabled, the sysjobstepslogs data row for the step can contain output for more than one execution. If this option is not selected, the table contains only execu- tion history for the last execution of the step. CAUTION If you choose the Append Output to Existing Entry in Table option, the size of the sysjobstepslogs table will grow over time. You should consider using the sp_delete_jobsteplog stored procedure to remove data from the sysjobstepslogs table. This stored procedure has several different parameters that allow you to filter the data that will be removed. You can use these parameters to remove log data by job, job step, date, or size of the log for the job step. Defining Multiple Jobs Steps You can define multiple jobs steps in a single job. This allows you to execute multiple dependent job actions. The job steps run one at a time (serially), and you can specify the order of the job steps. The job order and the related dependencies are called control of flow. Figure 16.10 shows an example of a job that has multiple dependent job steps. Take note of the On Success and On Failure columns, which define the control of flow. For example, if step 1 succeeds, the next step occurs. If step 1 fails, no further steps are executed, and the job quits, reporting a job failure. The control of flow is slightly different for the second step, whereby the control of flow passes to the next step on success but flows to the fourth step if a failure occurs. The control of flow is defined on each job step. As discussed earlier in this chapter, the Advanced tab of the New Job Step dialog provides drop-down lists that allow you to specify the actions to take on success and on failure. In addition, the Steps page that lists all of a job’s steps allows you to specify the start step for the job. The drop-down box at Download from www.wowebook.com ptg 465 Managing Jobs 16 FIGURE 16.10 Multiple job steps. the bottom of the Steps page provides this function. You can also use the Move Step arrows to change the start step. Manipulating the start step is useful when you’re restart- ing a job manually, as in the case of a job failure; in this situation, you might want to set the job to start on a step other than the first step. NOTE SSIS provides the same type of flow control capabilities as the SQL Server Agent. In fact, maintenance plans that contain multiple related actions (such as optimization, backup, and reporting) utilize SSIS packages. A scheduled job starts an SSIS package, which executes the package in a single step, but the actual maintenance steps are defined within the package. The SSIS Designer utilizes a graphical tool that depicts the flow of control and allows you to modify the individual steps. Defining Job Schedules The SQL Server Agent contains a comprehensive scheduling mechanism you can use to automate the execution of your jobs. A job can have zero, one, or more schedules assigned to it. You can view the schedules associated with a job by selecting the Schedules page of the Job Properties screen. To create a new schedule for a job, you can click the New button Download from www.wowebook.com ptg 466 CHAPTER 16 SQL Server Scheduling and Notification at the bottom of the Schedules page. Figure 16.11 shows the New Job Schedule Properties page, with a sample schedule and options defined. The options on this screen vary, depending on the frequency of the job schedule. For example, if the frequency of the schedule shown in Figure 16.11 were changed from daily to weekly, the screen would change to allow for the selection of specific days during the week to run the job. You have the ability to share job schedules so that one job schedule can be utilized by more than one job. When you select the Schedule page, a Pick button is available at the bottom of the page. If you click the Pick button, a screen appears showing all the defined schedules. If you highlight one of the schedules in the list and click OK, the schedule is linked to the related job. You can also view all the jobs associated with a particular sched- ule by editing the schedule and clicking the Jobs in Schedule button in the top-right portion of the Job Schedule Properties screen. Tracking multiple job schedules and schedule execution can be challenging in an environ- ment that has many jobs and schedules. The sp_help_jobs_in_schedule, and sp_help_jobactivity stored procedures are helpful system stored procedures that are found in the msdb database. The sp_help_jobs_in_schedule stored procedure provides information about the relationship between jobs and schedules. The sp_help_jobactivity stored procedure provides point-in-time information about the runtime state of SQL FIGURE 16.11 The New Job Schedule Properties page. Download from www.wowebook.com ptg 467 Managing Jobs 16 Server jobs. This stored procedure returns a lot of information, including recent job execu- tions, the status of those executions, and the next scheduled run date. Defining Job Notifications The Notifications page of the Job Properties dialog, as shown in Figure 16.12, allows you to define the notification actions to perform when a job completes. As discussed earlier in this chapter, notifications can be sent via email, pager, or NET SEND command. The notifications for a Schedule Job can be sent based on the following events: . When the job succeeds . When the job fails . When the job completes Each of these events can have a different notification action defined for it. For example, a notification might send an email if the job succeeds but page someone if it fails. You also have the option of writing notification information into the Windows Application event log or automatically deleting the job when it completes. These two FIGURE 16.12 The Notifications page of the Job Properties dialog. Download from www.wowebook.com ptg 468 CHAPTER 16 SQL Server Scheduling and Notification options are also available on the Notifications page. Writing events to the Application log is a useful tracking mechanism. Monitoring software is often triggered by events in the application log. The automatic job deletion options are useful for jobs that will be run only once. As with the other notification options, you can set up the delete job action such that it is deleted only when a specific job event occurs. For example, you might want to delete the job only if the job succeeds. Viewing Job History You view job history via the Log File Viewer, which is a comprehensive application that allows for many different types of logs to be viewed. You right-click a job in the SQL Server Agent and select History to display the Log File Viewer. Figure 16.13 shows the Log File Viewer with several examples of job history selected for viewing. Compared to viewing job history in SQL Server versions prior to SQL Server 2005, the current form of the Log File Viewer has some distinct advantages for viewing job history. In the Log File Viewer, you can select multiple jobs for viewing at one time. To view job step details, you expand the job entries and select a job step. You can use the row details shown below the log file summary to troubleshoot job errors and isolate problems. The Log File Viewer also has filtering capabilities that allow you to isolate the jobs to view. Click on the Filter button and the Filter Settings dialog appears. You can filter jobs by using a number of different settings, including User, Start Date, and Message Text. You must click the Apply Filter button for the selected filtering option to take effect. The amount of history that is kept is based on the history settings defined for the SQL Server Agent. You access the history settings by right-clicking the SQL Server Agent node, selecting Properties, and then selecting the History page on the left part of the screen. The settings available on the History page are shown in Figure 16.14. By default, the job FIGURE 16.13 Job history shown in the Log File Viewer. Download from www.wowebook.com ptg 469 Managing Alerts 16 history log is limited to 1,000 rows, with a maximum of 100 rows per job. You can also select the Automatically Remove Agent History option and select a period of time to retain history. This setting causes the SQL Server Agent to periodically remove job history from the log. This is a good approach for keeping the size of the log manageable. Managing Alerts The SQL Server Agent can monitor events that occur on the database server and automati- cally respond to these events with alerts. Alerts can be fired based on SQL Server events, performance conditions, and Windows Management Instrumentation (WMI) events. After an alert is fired, the SQL Server Agent can respond by notifying an operator or executing a job. This provides a proactive means for identifying and reacting to critical conditions on a database server. Defining Alert Properties To define alerts, you select the SQL Server Agent node in the Object Explorer tree and then right-click on the Alerts node and select New Alert. Figure 16.15 shows an example of the New Alert dialog that appears. FIGURE 16.14 Job history settings. Download from www.wowebook.com ptg 470 CHAPTER 16 SQL Server Scheduling and Notification The General page selected in Figure 16.15 allows you to define the basic alert properties, including the name of the alert and type of event you want the alert to respond to. The default type of alert, the SQL Server event alert, is triggered by SQL Server events that write to the Windows Application event log. SQL Server writes to the Application event log when the following events occur: . When sysmessages errors with a severity of 19 or higher are generated. You can use the sys.sysmessages catalog view to view all the sysmessages that are stored in the server. You can create new user-defined messages by using the sp_addmessage stored procedure; they must have a msg_id (or error number) that is greater than 50,000. The error message must be created before you can reference the error number in an alert. . When sysmessages errors are generated by the database engine. These messages have error numbers lower than 50,000 and are installed by default. . When any RAISERROR statement is invoked with the WITH LOG option. The WITH LOG statement forces the event to be written to the Application event log. Messages generated with RAISERROR that have a severity level greater than 18 are required to write to the Application event log. FIGURE 16.15 The General page of the New Alert dialog. Download from www.wowebook.com ptg 471 Managing Alerts 16 . When sysmessages have been altered with the sp_altermessage statement to write to the application log. The sp_altermessage command has a write_to_log parame- ter that you can use to modify error numbers found in sys.messages. When the write_to_log parameter is set to WITH_LOG, these message automatically write to the Application event log, regardless of whether the WITH_LOG option is used when the error is raised. . When application calls are made to xp_logevent to log an event to the application log. The bottom portion of the General page of the New Alert dialog allows you to define which events in the Application event log the alert should respond to. You can have the event respond to a specific error number, the error severity level, or specific text that is contained in the error message. The sys.sysmessages catalog view contains a complete list of all the error message details for all the supported languages. You can use the follow- ing SELECT statement to list the error messages for the English language: SELECT * FROM SYS.SYSMESSAGES where msglangid = 1033 order by msglangid, error You can define an alert for hundreds of messages. For example, you can define an alert that responds to changes to database options. You do this by selecting error number 5084, which is triggered whenever a change is made to the database options. You can also narrow the scope of the alert to look at a specific database by using the Database Name drop-down. This limits the alert to errors that occur in the specific database you choose. The default option is to look at all databases. The two other types of alerts you can define are SQL Server performance condition alerts and WMI event alerts. A SQL Server performance condition alert reacts to performance conditions on the server. Figure 16.16 shows an example of this type of alert. When you select a SQL Server performance condition alert, you need to select the perfor- mance object and counter for that object to monitor. The SQL Server performance objects and counters available on the General page of the New Alert dialog are a subset of those available in the Windows Performance Monitor application. These performance metrics encompass key indicators, such as memory, CPU, and disk space. After selecting the object and counter, you need to define the performance threshold for the alert at the bottom of the General page, below the Alert if Counter label. In the example shown in Figure 16.16, the alert is monitoring the transaction log file for the AdventureWorks database. The threshold has been set such that the alert will fire if the transaction log for this database rises above 2KB. The WMI event alerts use WMI to monitor events in an instance of SQL Server. The SQL Server Agent can access SQL Server events by using the WMI provider for server events by issuing WMI Query Language (WQL) statements. WQL is a scaled-down version of SQL that contains some WMI-specific extensions. When a WMI query is run, it essentially creates an event notification in the target database so that a related event will fire. The Download from www.wowebook.com ptg 472 CHAPTER 16 SQL Server Scheduling and Notification FIGURE 16.16 A SQL Server performance condition alert on the General page. number of WMI events is extensive. Refer to the “WMI Provider for Server Events Classes and Properties” topic in SQL Server Books Online for a complete list. Figure 16.17 shows an example of a WMI event alert. This example uses a WQL query that detects any Data Definition Language (DDL) changes to any of the databases on the server. After the alert is created, you can test it by running a DDL statement against the database (for example, alter table Person.address add newcol int null). Defining Alert Responses The definition of an alert has two primary components. As discussed earlier in this chapter, the first component involves the identification of the event or performance condition that will trigger the alert. The second part of an alert definition involves the desired response when the alert condition is met. You can define an alert response by using the Response page on the alert’s Properties screen. Figure 16.18 shows a sample response that has been configured to use NET SEND on a message to the operator named ChrisG. Operator notification and job execution are the two responses to an alert. Operator notifi- cation allows for one or more operators to be notified via email, pager, or the NET SEND command. Job execution allows for the execution of a job that has been defined in the SQL Server Agent. For example, you could execute a job that does a database backup for an alert that is triggered based on database size. You can define both job execution and operator notification in a single alert; they are not mutually exclusive. Download from www.wowebook.com ptg 473 Managing Alerts 16 FIGURE 16.17 The General page showing a WMI event alert. FIGURE 16.18 Configuring an alert response. Download from www.wowebook.com . of SQL Server. The SQL Server Agent can access SQL Server events by using the WMI provider for server events by issuing WMI Query Language (WQL) statements. WQL is a scaled-down version of SQL. respond to. The default type of alert, the SQL Server event alert, is triggered by SQL Server events that write to the Windows Application event log. SQL Server writes to the Application event log. alerts you can define are SQL Server performance condition alerts and WMI event alerts. A SQL Server performance condition alert reacts to performance conditions on the server. Figure 16.16 shows