Microsoft SQL Server 2008 R2 Unleashed- P52 docx

Configuring Email Notification The SQL Server Agent can send email notifications; it can send email via SQL Mail or Database Mail.. The Configuration Wizard and many other details relate

Configuring Email Notification

The SQL Server Agent can send email notifications; it can send email via SQL Mail or

Database Mail SQL Mail was retained for backward compatibility It utilizes an Extended

Messaging Application Programming Interface (Extended MAPI) interface to send email

and requires that you install an email application (such as Outlook) that supports

Extended MAPI communication on the computer that is running SQL Server

Database Mail, which is now the recommended mail solution for the SQL Server Agent, is

the focus of this section It was added in SQL Server 2005, and it utilizes Simple Mail

Transfer Protocol (SMTP) instead of Extended MAPI to send mail This simplifies email

setup and has many benefits over SQL Mail, including the following:

There is no requirement that an email client be installed on the SQL Server machine

Email is queued for later delivery if the mail server stops or fails

Multiple SMTP servers can be specified so that mail continues to be delivered in the

event that one of the SMTP servers stops

Database Mail is cluster aware

Database Mail is disabled by default in SQL Server 2008 but can be enabled using the

Database Mail Configuration Wizard This wizard provides a comprehensive means for

configuring Database Mail The Database Mail Configuration Wizard is not launched from

the SQL Server Agent node Instead, you can launch it by expanding the Management

node, right-clicking Database Mail, and selecting Configure Database Mail This wizard

guides you through the configuration of mail profiles, SMTP accounts, and other options

relevant to Database Mail The Configuration Wizard and many other details related to

Database Mail are discussed in detail in Chapter 15, “Database Mail.”

After you set up Database Mail and confirm that it is working properly, you can select it as

your mail system for the SQL Server Agent to send mail You do this by right-clicking the

SQL Server Agent node in the Object Explorer and selecting Properties Then you select

the Alert System page in the SQL Server Agent Properties dialog, and the screen shown in

Figure 16.3 appears In this figure, Database Mail is selected as the mail system, along with

a mail profile for Database Mail created with the Database Mail Configuration Wizard The

mail profile you select can have multiple SMTP accounts assigned to it This allows for

redundancy in the event that the mail cannot be sent to one of the SMTP accounts

To ensure proper functioning of the alert system, you should restart the SQL Server Agent

service after the alert system has been configured If you experience problems sending

notifications via the SQL Server Agent, you should check the service account that SQL

Server is running under If the SQL Server Agent is running with the local system account,

resources outside the SQL Server machine will be unavailable; this includes mail servers

that are on other machines You should change the service account for the SQL Server

Agent to a domain account to resolve this issue Chapter 15 provides more information on

using Database Mail in SQL Server 2008

CHAPTER 16 SQL Server Scheduling and Notification

ptg FIGURE 16.3 The Alert System page of the SQL Server Agent Properties dialog 16

SQL Server Agent Proxy Account

Proxy accounts allow non–Transact-SQL (non–T-SQL) job steps to execute under a specific

security context By default, only users in the sysadmin role can execute these job steps

Non-sysadmin users can be assigned to a proxy account to allow them to run the special

job steps In SQL Server 2000, a single proxy account was provided for this function With

SQL Server 2008, multiple proxy accounts can be established, each of which can be

assigned to a different SQL Server Agent subsystem

To establish a proxy account for the SQL Server Agent, you must first create a credential A

credential contains the authentication information necessary to connect to a resource

outside SQL Server The credential is typically linked to a Windows account that has the

appropriate rights on the server To create a credential, you open the Security node in the

Object Explorer, right-click the Credentials node, and select New Credential You give the

credential a name, enter an identity value that corresponds to a valid Windows account,

and provide a password for the account

After creating a credential, you can create a new proxy account and link it to the

creden-tial To create a new proxy account, you expand the SQL Server Agent node in the Object

Explorer tree, right-click Proxies, and select New Proxy Account Figure 16.4 shows an

example of the New Proxy Account dialog In this example, the proxy name and

creden-tial name are the same, but they do not need to be The only subsystem selected for the

CHAPTER 16 SQL Server Scheduling and Notification

FIGURE 16.4 Creating a new proxy account

sample proxy account in Figure 16.4 is the operating system, but a proxy account can be

linked to multiple subsystems

After a proxy account is created, a sysadmin can assign one or more SQL logins, msdb roles,

or server roles to the proxy You do this by using the Principals page of the New Proxy

Account dialog A proxy account can have zero or many principals assigned to it

Conversely, a principal can be assigned to many different proxies Linking non-admin

principals to the proxy allows the principal to create job steps for subsystems that have

been assigned to the proxy

Proxy accounts are referenced within a SQL Server Agent job step The General page of the

Job Step Properties dialog contains a Run As drop-down that lists valid accounts or proxies

that can be used to run the particular job step After you add a proxy account, you see it

in this drop-down list Keep in mind that the account is not visible for a T-SQL job step

that does not utilize a proxy account Steps that utilize the T-SQL subsystem execute under

the job owner’s context and they do not utilize a proxy account

Viewing the SQL Server Agent Error Log

The SQL Server Agent maintains an error log that records information, warnings, and error

messages concerning its operation A node named Error Logs is located in the SQL Server

Agent tree in the Object Explorer The Error Logs node contains multiple versions of the

SQL Server Agent error log By default, a maximum of 10 versions of the error log are

displayed under the Error Logs node The versions displayed include the current error log

and the last 9 versions Each time the SQL Server Agent is restarted, a new error log is

generated, with a name that includes a time stamp The first part of the current version’s

name is Current Names of older logs start with Archive #, followed by a number; the

newer logs have lower numbers The SQL Server error log works in much the same way as

the SQL Server Agent’s error log

TIP

You can cycle the error log at any time without stopping and starting the SQL Server

Agent To do so, you right-click the Error Logs node in the Object Explorer and select

Recycle; a new error log is then generated You can also use the

msdb.dbo.sp_cycle_agent_errorlog stored procedure to cycle the error log You need

to remember to also select the Refresh option to show the latest available error logs

To view the contents of any of the logs, you need to double-click the particular log

Double-clicking a particular log file launches the Log File Viewer The Log File Viewer

contains the SQL Server Agent error logs in addition to logs that are associated with other

SQL Server components, including Database Mail, SQL Server, and Windows NT Figure

16.5 shows a sample Log File Viewer screen with the current SQL Server Agent error log

selected for display The Log File Viewer provides filtering capabilities that allow you to

focus on a particular type of error message, along with other viewing capabilities that are

common to all the logs available for viewing

FIGURE 16.5 The SQL Server Agent error log

CHAPTER 16 SQL Server Scheduling and Notification

SQL Server Agent Security

Many changes were made to the security model related to the SQL Server Agent in SQL

Server 2005 In the past, everyone could view the SQL Server Agent Starting in SQL Server

2005, logins must be a part of the sysadmin server role or assigned to one of three msdb

database roles to be able to view and modify the SQL Server Agent The SQL Server Agent

node does not appear in the Object Explorer tree if the login does not have the

appropri-ate permissions Following are the msdb database roles and their basic permissions:

SQLAgentUserRole—Users with this permission can create and manage local jobs

and job schedules that they own They cannot create multiserver jobs or manage

jobs that they do not own

SQLAgentReaderRole—Users with this permission can view jobs that belong to

other users in addition to all the permissions associated with SQLAgentUserRole

SQLAgentOperatorRole—Users with this permission can view operators and alerts

and control jobs owned by other users The job control on jobs owned by other

users is limited to stopping or starting and enabling or disabling those jobs

SQLAgentOperatorRole also has all the permissions available to SQLAgentUserRole

and SQLAgentReaderRole

SQLAgentUserRole has the fewest privileges, and each subsequent role has increasing levels

of security In addition, each subsequent role inherits the permissions of the roles with

fewer permissions For example, SQLAgentReaderRole can do everything that

SQLAgentUserRole can do and more Refer to the topic “Implementing SQL Server Agent

Security” in SQL Server Books Online for a detailed list of all the permissions related to the

new database roles

Managing Operators

Operators are accounts that can receive notification when an event occurs These accounts

are not linked directly to the user and login accounts that are defined on the server They

are basically aliases for people who need to receive notification based on job execution or

alerts Each operator can define one or more electronic means for notification, including

email, pager, and the NET SEND command

To add a new operator, you expand the SQL Server Agent node in the Object Explorer

and right-click the Operators node Then you select New Operator from the right-click

menu Figure 16.6 shows the New Operator screen, with many of the fields populated for

the creation of a new operator named LauraG

The General page of the New Operator screen allows you to enter the name of the

opera-tor, the notification options, and the “on duty” scheduled for the operator The operator

name can be any name, but it must be unique within the SQL Server instance and must

be no more than 128 characters The operator name can be the same as another login or

user on the server, but this is not required

FIGURE 16.6 Creating a new operator

The notifications options are the key to operators You create operators so that you can

then define notification options and have messages sent from SQL Server

If you use the email notification option, the email address you specify must be a valid

address that can be reached via Database Mail or SQL Mail One of the two mail options

must be configured before the email functionality will work If Database Mail is

config-ured, the email is sent via an SMTP server To send email with SQL Mail, SQL Server must

be able to access a Microsoft Exchange server, and you must have the Extended MAPI

client installed on the SQL Server machine

The NET SEND notification option causes a pop-up window to appear on the recipient’s

computer; this window contains the notification text In the Net Send Address text box,

you specify the name of the computer or user that is visible on the network to the SQL

Server machine For NET SEND to work, the Messenger service on SQL Server must be

started This Messenger service must also be started on the machine that is receiving the

NET SEND message You can test the basic NET SEND capabilities by executing NET SEND at

the command prompt The basic syntax for NET SEND follows:

NET SEND {name | * | /domain[:name] | /users} message

The following example uses the NET SEND command to send the message “Test net send

message” to the operator LauraG:

NET SEND LauraG “Test net send message”

CHAPTER 16 SQL Server Scheduling and Notification

The final notification option is through a pager email address Pager email requires that

third-party software be installed on the mail server to process inbound email and convert

it to a pager message The methods for implementing pager email and the available

soft-ware are dependent on the pager provider You should contact your pager vendor for

implementation details

If you implement pager notification, you can also define the pager schedule for the

opera-tor The Pager on Duty Schedule section of the New Operator dialog allows you to define

the days and times when the operator will be available to receive a page The General page

includes a check box for each day the operator can receive a page It also includes the

Workday Begin and Workday End settings, which you can use to define the valid time

periods to receive a page

The other page available when defining a new operator is the Notifications page, which

displays the alerts and jobs for which the operator will receive notifications For a new

operator, the Alert List or Job List is empty, as shown in Figure 16.7

You’ll have a better understanding of the usefulness of operators after you read the

follow-ing discussions of jobs and alerts Jobs and alerts can have operators linked to them for

notification purposes

FIGURE 16.7 The Notifications page of the New Operator dialog

Managing Jobs

A job is a container for operations that can be executed by the SQL Server Agent Jobs can

be run once or scheduled to run on a regular basis Jobs provide the basis for SQL Server

automation and allow for the execution of many different types of operations, including

T-SQL, SQL Server Integration Services (SSIS) packages, and operating system commands

Defining Job Properties

The Jobs node is located under SQL Server Agent in the Object Explorer You right-click

the Jobs node and select New Job to create a new SQL Server Agent job A New Job dialog

like the one shown in Figure 16.8 appears

NOTE

Only logins that are part of one of the msdb fixed database roles or are members of

the sysadmin fixed server role are able to create or modify jobs

The General properties page shown in Figure 16.8 contains the basic information about

the job, including the name and description The owner of the job defaults to the login

FIGURE 16.8 The New Job dialog

CHAPTER 16 SQL Server Scheduling and Notification

for the person creating the job; however, if the login of the person creating the job is part

of the sysadmin fixed server role, the default can be changed You use the Category

selec-tion to group or organize jobs There are several predefined categories for selecselec-tion,

includ-ing Database Maintenance and Log Shippinclud-ing The default category is set to

[Uncategorized(local)]

Defining Job Steps

After you add the general information for a new job, you are ready to add the job steps

that actually perform the work To do this, you select the Steps page on the left side of the

New Job dialog, and the job steps for this job are listed To create a new job step, you click

the New button, and a New Job Step dialog like the one shown in Figure 16.9 appears

A step name is the first piece of information you need to provide for the job step It can

be up to 128 characters long and must be unique within the job Then you need to select

a job step type The SQL Server Agent can run a variety of types of job steps, including the

following:

ActiveX script (Visual Basic, Java, Perl script)

Operating System (CmdExec)

PowerShell

FIGURE 16.9 The New Job Step dialog

Replication Distributor

Replication Merge

Replication Queue Reader

Replication Snapshot

Replication Transaction Log Reader

SQL Server Analysis Services Command

SQL Server Analysis Services Query

SQL Server Integration Services Package

Transact-SQL script (T-SQL)

SQL Server Analysis Services Command, Server Analysis Services Query, and SQL

Server Integration Services Package are types that were added in SQL Server 2005

They provide integration with SQL Server Analysis Services (SSAS) and SSIS Chapters 45,

“SQL Server and the NET Framework,” and 46, “SQLCLR: Developing SQL Server Objects

in NET,” provide detailed discussions of these technologies The PowerShell job type was

added in SQL Server 2008; further information on PowerShell is provided in Chapter 17,

“Administering SQL Server 2008 with PowerShell.”

The Step properties page displays different information, depending on the type of step

selected When the Transact-SQL script (T-SQL) type is selected, you see a window

similar to the one shown in Figure 16.9 If you choose the SQL Server Integration

Services Package type, the Step properties page changes to allow you to enter all the

rele-vant information needed to execute an SSIS package

In many cases (including T-SQL), a command window is available to input the step

commands With a T-SQL command, you can enter the same type of commands you would

enter in a query window You click the Parse button to validate the SQL and ensure proper

syntax The Operating system (CmdExec) type allows you to enter the same types of

commands that you can enter in a command prompt window Each step type has its own

command syntax that you can test in the native environment to ensure proper operation

You can select the Advanced page to configure job flow information and other

informa-tion related to the job step On Success Acinforma-tion allows you to specify the acinforma-tion to perform

when the current job step completes Actions include the execution of the next job step (if

one exists) and the ability to set job status based on the step completion The same

selec-tion opselec-tions also exist for On Failure Acselec-tion

The Retry options define the options that relate to retrying the job step in the event that

the job step fails Retry Attempts defines the number of times the job step will be

re-executed if it fails Retry Intervals (Minutes) defines the amount of time (in minutes)

between retry attempts