Microsoft SQL Server 2008 R2 Unleashed- P52 docx

ptg
454
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
Download from www.wowebook.com
ptg
455
FIGURE 16.3 The Alert System page of the SQL Server Agent Properties dialog.
Configuring the SQL Server Agent
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
Download from www.wowebook.com
ptg
456
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

Download from www.wowebook.com
ptg
457
Viewing the SQL Server Agent Error Log
16
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 e rr or log at any time without stopping and star ting the SQL Ser ver
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.
Download from www.wowebook.com
ptg
458

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.
Download from www.wowebook.com
ptg
459
Managing Operators
16
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”
Download from www.wowebook.com
ptg
460
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.
Download from www.wowebook.com
ptg
461
Managing Jobs

16
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.
Download from www.wowebook.com
ptg
462
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 selection, includ-
ing Database Maintenance and Log Shipping. 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.
Download from www.wowebook.com
ptg
463
Managing Jobs
16
. 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 Action allows you to specify the action 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 options also exist for On Failure Action.
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.
Download from www.wowebook.com