SQL Server Reference Guide

Creating a Master Agent and Alert Server

Last updated May 1, 2009.

Most DBAs create a “Central Management System” that houses all of their scripts, server registrations and other controls so that they can monitor and manage their systems from a single location. You can certainly buy software (such as Microsoft’s System Center or packages from Idera or Quest) that will do this for you, but for many reasons, I normally build my own.

In SQL Server 2008, many new features make this very easy and convenient, such as the Central Management Server registration, Policy Based Management and the Management Data Warehouse. But there’s a feature that’s been around for quite a while that you can use to control two of the central parts of SQL Server: Alerts and Jobs.

I’ve written about both Jobs and Alerts, and the system that controls them, the SQL Server Agent. I’ll run through all three here quickly so that you have a common frame of reference for the terms I’ll use in this article, but if you’re new to any part of those, make sure you read those articles first.

The SQL Server Agent is a program (controlled by a Windows Service) that automates everything in SQL Server. It has a timing system, and can create “Jobs,” which are simply a collection of actions (called “steps”) that you want the Agent to run at a specific time.

A SQL Server Alert is a system that reports various error conditions. Although it isn’t controlled by the SQL Server Agent, it can run a SQL Server Agent Job based on an error condition. And in fact the word “error” is misleading here — while the Alert system certainly reports on actual errors in the SQL Server engine, you can create your own “errors,” assign them a number, and have the Alert system run a job based on that number. The “error” you create doesn’t have to be a problem per se; it can actually be anything you like. If you create your own Alerts, they can be based on an error condition or something that you “raise” in code. In other words, you might check to see if the inventory level in a database is at a desired value, and then raise an error number that you create, which in turn can run a job to print an invoice, or perhaps just send an e-mail that the level was reached.

So to recap where we are, the Alert system can run Jobs using the SQL Server Agent. And that’s fine for single-system management. You can set up Alerts and the Agent on each system, and have the logging, errors and so on controlled on each server. If, however, you have dozens or even hundreds of servers, it becomes difficult to check each one individually. It would be far more useful to have a single server (My “Central Management System” comes to mind) where all of the Agent Jobs are controlled, and all of the Events are recorded.

Creating and Using a SQL Server Master Jobs Server

When you create a master Jobs server, you can then create jobs on that server that will run on each “target” server that is owned by this master server. Each target server will also have its own Jobs, but they will also automatically have Jobs created on the master server as well.

Something that is very important to keep in mind when you create master Jobs is that they will run on each server — so if you have drives or Backup Devices or anything else defined in the Job, those objects must be identical on each server. If they aren’t, you’ll get a failure, or even worse, you’ll get unexpected results. That’s never good. Also, if you’re using multiple versions (as I am in this demo) make sure that the Steps in the Job only have things that can happen on each version. In SQL Server 2008, you can have a Job Step that uses PowerShell — but SQL Server 2005 doesn’t know how to do that. So in that case, don’t create a job that has PowerShell steps on the Master Server.

It’s best if all the servers are in the same domain, and that they use the same domain account for starting SQL Server Agent. If that’s not the case, you can use a “proxy” account, but I’m not going to cover that here. Books Online has the process for that.

Here’s the process I used to create my Central Management System (CMS) Master Jobs Server.

First, I opened SQL Server Management Studio (SSMS) and registered a SQL Server 2008 system (the one I’m using as the master, which is also my CMS) and a SQL Server 2005 system.

Next, I right-click the SQL Server 2008 server’s SQL Server Agent node and select “Multi Server Administration” and then “Make this a Master” from the menu that appears:

Figure 1

I click “Next” at the welcome screen of the Wizard that will configure everything for me. The next screen sets up the addresses the system will use to send out notifications — a very important step:

Figure 2

Clicking “Next” after I fill that out brings me to the screen where I can select the Target servers I want to enlist right away. I can actually set these up later, but since I’m here I’ll go ahead and select the SQL Server 2005 system. Even if I don’t have that registered, this panel has all of the buttons needed to connect now:

Figure 3

I click “Next” after I fill out this panel and then I get a feedback panel stating that all is well:

Figure 4

After I click the “Close” button there, I get a panel that sets up the Roles and Accounts that the system needs to run the Agent on multiple systems.

Figure 5

I leave the selection and click “Next” to bring up the next Panel. Here I get the summary panel where I have a chance to make those last minute changes, and then I click “Finish” to let the Wizard do its magic.

Figure 6

Now I have a new node underneath the SQL Server Agent | Jobs area in my “Master” server – called “Multi Server Jobs.”

Figure 7

I’ll create a simple Job here to test the Master Job server and make sure that it copies and runs on each of my servers. It’s a simple job that performs a SELECT @@VERSION step (note — your server names won’t be the same as mine, so read and edit this script carefully — or better yet, just create a simple Job yourself using the graphical tools):

USE [msdb]
GO

BEGIN TRANSACTION
DECLARE @ReturnCode INT
SELECT @ReturnCode = 0
IF NOT EXISTS (SELECT name FROM msdb.dbo.syscategories WHERE name=N'[Uncategorized (Multi-Server)]' AND category_class=1)
BEGIN
EXEC @ReturnCode = msdb.dbo.sp_add_category @class=N'JOB', @type=N'MULTI-SERVER', @name=N'[Uncategorized (Multi-Server)]'
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback

END

DECLARE @jobId BINARY(16)
select @jobId = job_id from msdb.dbo.sysjobs where (name = N'TestMultipleServers')
if (@jobId is NULL)
BEGIN
EXEC @ReturnCode = msdb.dbo.sp_add_job @job_name=N'TestMultipleServers', 
		@enabled=1, 
		@notify_level_eventlog=0, 
		@notify_level_email=0, 
		@notify_level_netsend=0, 
		@notify_level_page=0, 
		@delete_level=0, 
		@description=N'This is a test', 
		@category_name=N'[Uncategorized (Multi-Server)]', 
		@owner_login_name=N'sa', @job_id = @jobId OUTPUT
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback

END
IF NOT EXISTS (SELECT * FROM msdb.dbo.sysjobsteps WHERE job_id = @jobId and step_id = 1)
EXEC @ReturnCode = msdb.dbo.sp_add_jobstep @job_id=@jobId, @step_name=N'SELECT the Version', 
		@step_id=1, 
		@cmdexec_success_code=0, 
		@on_success_action=1, 
		@on_success_step_id=0, 
		@on_fail_action=2, 
		@on_fail_step_id=0, 
		@retry_attempts=0, 
		@retry_interval=0, 
		@os_run_priority=0, @subsystem=N'TSQL', 
		@command=N'SELECT @@VERSION', 
		@database_name=N'master', 
		@flags=0
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
EXEC @ReturnCode = msdb.dbo.sp_update_job @job_id = @jobId, @start_step_id = 1
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
EXEC @ReturnCode = msdb.dbo.sp_add_jobserver @job_id = @jobId, @server_name = N'YourServerNameHere\YourInstanceNameHere'
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
COMMIT TRANSACTION
GOTO EndSave
QuitWithRollback:
  IF (@@TRANCOUNT > 0) ROLLBACK TRANSACTION
EndSave:

I check the job at my CMS (Master Server) and the Target Server and see that it copied just fine.

To use the job, I fire it from the Master Server, not the Target. When I start it on the Master, it runs on all of the Targets I defined.

Event Forwarding

With the master Job server set up, you can now move on to creating an Event forwarding system. This isn’t required, of course — you can have one without the other — but it is a great way to manage both parts of the system from one location.

It’s much easier to set up Event Forwarding. I just right-clicked the SQL Server Agent node in SSMS on each “Target” server. Then I selected the “Advanced” tab. Here I simply filled out the name of the server that will receive the Alerts.

Figure 8

The interesting thing is that you have three modes of working with these Alerts. You can forward all Alerts (as I have here) or you can forward only the Alerts that this system does not handle. You can also have only certain severities of Alerts sent to the CMS.

Keep in mind with both of these features that you now have a single point of management, but also a single point of failure. If your CMS goes offline, the Agent won’t run the jobs and the Alerts won’t have any place to go. Treat that box with respect.

InformIT Articles and Sample Chapters

Learn more about the SQL Server Agent in Administering the SQL Server 2005 Database Engine.

Books and eBooks

You’ll find more about Alerting (and get certified at the same time) in MCTS 70-431 Exam Cram: Implementing and Maintaining Microsoft SQL Server 2005 Exam.

Online Resources

When I finish the CMS project, I’ll post it here.