Tải bản đầy đủ (.pdf) (10 trang)

Microsoft SQL Server 2008 R2 Unleashed- P53 ppt

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (605.9 KB, 10 trang )

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

×