Microsoft SQL Server 2008 R2 Unleashed- P53 ppt

You right-click a job in the SQL Server Agent and select History to display the Log File Viewer.. You access the history settings by right-clicking the SQL Server Agent node, selecting P

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 execuexecu-tion 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

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

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 schedsched-ule and clicking the Jobs in Schedsched-ule 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

Server jobs This stored procedure returns a lot of information, including recent job

execu-tions, the status of those execuexecu-tions, 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

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

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

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

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 perforperfor-mance 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

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

ptg