Microsoft SQL Server 2008 R2 Unleashed- P54 ppsx

ptg
474
CHAPTER 16 SQL Server Scheduling and Notification
You can further define an alert response by using the Options page of an alert’s Properties
window (see Figure 16.19).
You can include an alert’s error text in the operator notification message on this page.
This alert error text provides further details about why the alert was fired. For example, if
you have an alert that is triggered by changes to database options, the alert error text
would include the actual option that was changed. You can also define additional notifica-
tion text that is included when the message is sent. This message could include directives
for the operators or additional instructions. Finally, you can define the amount of time
that the alert will wait before responding to the alert condition again. You do this by
using the Delay Between Responses drop-downs (Minutes and Seconds) to set the wait
time. This capability is useful in situations in which an alert condition can happen repeat-
edly within a short period of time. You can define a response delay to prevent an unneces-
sarily large number of alert notifications from being sent.
Scripting Jobs and Alerts
SQL Server has options that allow for the scripting of jobs and alerts. As with many of the
other objects in SQL Server, you might find that it is easier and more predictable to gener-
ate a script that contains the jobs and alerts on the server. You can use these scripts to
FIGURE 16.19 Alert options.
Download from www.wowebook.com
ptg
475
Scripting Jobs and Alerts
16
reinstall the jobs and alerts or deploy them to another server. You can right-click the job
or alert you want to script and choose a scripting option to generate the T-SQL for the
individual object. You can also select the Job or Alerts node to view the Object Explorer
Details that lists all the objects. You can also display the Object Explorer Details through
the View menu or by selecting it as the active tab. When Object Explorer Details is

selected, you have the option of selecting one or more jobs to script. You can select multi-
ple jobs by holding down the Ctrl key and clicking the jobs you want to script.
Figure 16.20 shows a sample Object Explorer Details for jobs, with several of the jobs
selected for scripting. To generate the script, you simply right-click one of the selected jobs
and select the Script Job As menu option to generate the desired type of script.
NOTE
With SQL Server 2008, you can also filter the jobs you want to script by using the filter-
ing capabilities that are available on the Object Explorer Details. For example, you can
filter on jobs whose names contain specific text. After you filter the jobs, you can script
the jobs that are displayed. The filtering options and the capability to selectively script
jobs are particularly useful in environments in which many jobs and alerts exist.
FIGURE 16.20 Script generation for jobs.
Download from www.wowebook.com
ptg
476
CHAPTER 16 SQL Server Scheduling and Notification
Multiserver Job Management
Multiserver job management allows you to centralize the administration of multiple target
servers on a single master server. The master server is a SQL Server instance that contains
the job definitions and status information for all the enlisted target servers. The target
servers are SQL Server instances that obtain job information from the master server and
continually update the master server with job statistics.
Multiserver job management is beneficial in SQL Server environments in which there are
many instances to manage. You can establish jobs, operators, and execution schedules one
time on the master server and then deploy them to all the target servers. This promotes
consistency across the enterprise and can ease the overall administrative burden. Without
multiserver job management, administrative jobs must be established and maintained on
each server.
Creating a Master Server
The first step in creating a multiserver environment involves the creation of a master

server. SQL Server 2008 provides the Master Server Wizard, which simplifies this task. You
launch the Master Server Wizard by right-clicking the SQL Server Agent node in the
Object Explorer and selecting Multi Server Administration and Make This a Master. The
Master Server Wizard then guides you through the creation of an operator to receive
multiserver job notifications and allows you to specify the target servers for SQL Server
Agent jobs.
Figure 16.21 shows the Master Server Wizard screen that allows you to add information
related to the master server’s operator. The operator created on the master server, named
MSXOperator, is the only one that can receive notifications for multiserver jobs.
FIGURE 16.21 The Master Server Wizard.
Download from www.wowebook.com
ptg
477
Event Forwarding
16
The Master Server Wizard also validates the service accounts that the SQL Server Agent
uses on the target servers. These accounts are typically Windows domain accounts that are
in the same domain as the master server. The service accounts are important because the
target servers utilize Windows security to connect to the master server and download jobs
for the SQL Server Agent. The validation process and security considerations are simplified
if the master server and target servers are run with the same domain account.
Enlisting Target Servers
The Master Server Wizard allows you to enlist one or more target servers. Enlisting a target
server identifies it to the master server and allows the master server to manage the
administration of its jobs. You can also enlist additional target servers after the wizard
completes. You do this by right-clicking the SQL Server Agent node of the target server
and then selecting Multi Server Administration and then Make This a Target. Doing so
launches the Target Server Wizard, which guides you through the addition of another
target server. The Target Server Wizard performs some of the same actions as the Master
Server Wizard, including the following:

. It ensures that the SQL Server versions on the two servers are compatible.
. It ensures that the SQL Server Agent on the master server is running.
. It ensures that the Agent Startup account has rights to log in as a target server.
. It enlists the target server.
Creating Multiserver Jobs
After setting up the master and target servers, you can create jobs on the master server and
specify which target servers they should run on. Periodically, the target servers poll the
master server. If any jobs defined for them have been scheduled to run since the last
polling interval, the target server downloads the jobs and runs them. When a job
completes, the target server uploads the job outcome status to the master server.
Event Forwarding
Event forwarding is another multiserver feature that allows a single SQL Server instance to
process events for other servers in your SQL Server environment. This involves the desig-
nation of an alerts management server to which other servers can forward their events.
You enable the alerts management server by right-clicking the SQL Server Agent node
and selecting Properties. When the Properties pages appears, you click the Advanced page
(see Figure 16.22).
Download from www.wowebook.com
ptg
478
CHAPTER 16 SQL Server Scheduling and Notification
To configure event forwarding, you select the Forward Events to a Different Server option
on the Advanced page. You can then select the SQL Server instance you want as the alerts
management server by using the Server drop-down. The servers shown in the drop-down
are those that have been registered in SSMS. If the server you want does not appear in the
drop-down, you need to choose Registered Servers from the View menu and ensure that
the server is registered.
You can choose to forward unhandled events, all events, or only a subset of the events.
The default is to send all unhandled events, but you can customize this for your needs.
You can further limit the messages that are forwarded by specifying the severity level that

the message must have in order to be forwarded. For example, you can configure the
servers to forward only fatal error messages that have a severity greater than or equal to
Level 19. In this scenario, you could define alerts on the alerts management server that
respond to these fatal errors and notify operators that specialize in their resolution.
You need to consider a number of trade-offs when using event forwarding. You need to
weigh the benefits of central administration and a lack of redundancy against the disad-
vantages of having a single point of failure and increased network traffic. The available
network bandwidth, number of servers involved in event forwarding, and stability of the
alerts management server are some of the key factors you need to think about in making
your decision.
FIGURE 16.22 Configuring event forwarding.
Download from www.wowebook.com
ptg
479
Summary
16
Summary
The SQL Server Agent in SQL Server 2008 delivers a powerful set of tools to make your
administrative life easier. It provides automation in the form of jobs, operators, and alerts
that help you deliver a consistent and healthy database environment. After you have set
up the appropriate automation with the SQL Server Agent, you can rest assured that you
have been proactive in managing your database environment.
PowerShell is another tool to help with your automation needs. This new tool, that was
integrated into SQL Server 2008, provides a powful command-line facility you can use to
access SQL Server objects. This tool is discussed in Chapter 17.
Download from www.wowebook.com
ptg
This page intentionally left blank
Download from www.wowebook.com
ptg

CHAPTER 17
Administering SQL
Server 2008 with
PowerShell
. Overview of PowerShell
. PowerShell Scripting Basics
. PowerShell in SQL Server 2008
. Step-By-Step Examples
Windows PowerShell is Microsoft’s next-generation
scripting language. More and more server-based products
are being released with various levels of support for this
scripting language.
This chapter provides an overview of what Windows
PowerShell is and describes some of the basic features of
Windows PowerShell that SQL Server 2008 users should find
useful. It also presents examples that demonstrate the use of
these features with SQL Server 2008.
SQL Server 2008 includes additional features to support
PowerShell. The chapter also presents step-by-step examples
showing how to use Windows PowerShell for various OS
and database tasks.
What’s New with PowerShell
The integration of Windows PowerShell into the SQL Server
environment is new to SQL Server 2008. The PowerShell
scripting language has been around for some time, but it
was not installed with prior versions of SQL Server or inte-
grated into the SQL Server environment. With SQL Server
2008, it is installed, and there are now means for easily
accessing SQL Server objects via this powerful scripting
shell.

The SQLPS utility is at the crux of the new PowerShell inte-
gration in SQL Server 2008. SQLPS is a command-line shell
that loads and registers SQL Server snap-ins that provide
access to SQL Server via PowerShell. There is no need to
manually reference or load the SQL Server libraries, which is
Download from www.wowebook.com
ptg
482
CHAPTER 17 Administering SQL Server 2008 with PowerShell
necessary if you launch the PowerShell environment independently using the native
PowerShell (powershell.exe) utility.
In SQL Server 2008, the new SQLPS utility has also been integrated into the SQL Server
Management Studio (SSMS) environment. You can launch a SQLPS session by right-clicking
on an object in the Object Explorer tree and selecting Start PowerShell. A SQLPS command
window is launched with the path for that object already referenced. You can now work
with the properties of that object in a command-line environment that provides options
that go beyond the traditional GUI environment.
The integration of SQLPS is also visible in the SQL Server Agent. You can now add
PowerShell job steps to SQL Server jobs. The PowerShell commands that you can enter for
the job step are the same as you would enter interactively in a PowerShell session. This
new kind of job step allows you to schedule PowerShell commands and integrate
PowerShell actions with other SQL Server Agent job steps.
Overview of PowerShell
Windows PowerShell is Microsoft’s next-generation automation and scripting language. It
is built on the Microsoft .NET 2.0 Framework.
Windows PowerShell was first released to the public in November 2006 as version 1.0. It
was released as a separate install for Windows XP and Windows 2003, and shortly after, an
install for Windows Vista was made available. Since its release, Windows PowerShell has
been downloaded over two million times.
NOTE

From this point on, we refer to Windows PowerShell simply as PowerShell.
When Windows Server 2008 was released, PowerShell was provided with the operating
system. To have access to PowerShell, you simply had to add the Windows PowerShell
feature through the new Server Manager.
NOTE
Currently, PowerShell is not available on Windows Server 2008 Core because of the .NET
Framework requirement. Server 2008 Core officially doesn’t support the .NET Framework.
In 2008, Microsoft announced that PowerShell is now part of its Common Engineering
Criteria for 2009 and beyond. This announcement basically means that all of Microsoft’s
server products should have some level of PowerShell support. Microsoft Exchange 2007
was the earliest server-class product to come out with full PowerShell support. In fact, all
of Exchange’s administrative tasks are based on PowerShell. The PowerShell functionality
in Exchange is actually named Exchange Management Shell.
Download from www.wowebook.com
ptg
483
Overview of PowerShell
NOTE
PowerShell 1.0 is installed by default when SQL Server 2008 client software or
Database Services are installed. Keep in mind that PowerShell 1.0 is not the latest
version available. The next version, PowerShell version 2, is available for download and
is installed by default with newer operating systems such as Windows Server 2008
R2. V2 introduces a number of new features that are not covered in this chapter.
NOTE
The intent of this chapter is to introduce the basic concepts and functionality of
PowerShell and how it integrates with SQL Server 2008. Use of more advanced
features is beyond the scope of what can be covered in a single chapter.
For more information on PowerShell, be sure to check out the main PowerShell address
at and also the PowerShell team blog at http:/
/blogs.msdn.com/powershell.

A number of script examples and resources are also available in the Microsoft
Technet PowerShell Script Center : http://te chnet.m icrosof t.com/e n-us/sc riptcen ter/
powershell.aspx
If you want to get into some of the more advanced features and capabilities of
PowerShell, you may also want to check out a PowerShell-specific book such as
Windows PowerShell Unleashed from Sams Publishing.
Start Using PowerShell Now
PowerShell supports all the regular DOS commands and can run scripts written in any
other language (the script engine specific to that scripting language still needs to be used).
If any kind of scripting is currently being done, there is no reason why users can’t start
using PowerShell now, even if they are not using its vast functionality.
Common Terminology
Here are some of the common terms used when working with PowerShell:
. Cmdlet—This is the name given to the built-in commands in PowerShell. Cmdlets
are the most basic component within PowerShell and are used when doing anything
in PowerShell. They are always of the form “verb-noun.” Cmdlets also have argu-
ments called parameters, and values can be passed to these parameters.
. Script—With automation comes the requirement for scripts. Using scripts is as
simple as putting a single cmdlet in a file and then executing the file. In PowerShell,
scripts have the extension .ps1 and can be executed or invoked by simply calling it
as ./my_script.ps1.
. Pipeline—This PowerShell functionality allows a series of cmdlets to be combined
together using the pipe character (|). The output from one cmdlet is then piped to
the following cmdlet for further processing.
17
Download from www.wowebook.com