- Table of Contents
- Microsoft SQL Server Defined
- Microsoft SQL Server Features
- Microsoft SQL Server Administration
- Microsoft SQL Server Programming
- Performance Tuning
- Practical Applications
- Choosing the Back End
- The DBA's Toolbox, Part 1
- The DBA's Toolbox, Part 2
- Scripting Solutions for SQL Server
- Building a SQL Server Lab
- Using Graphics Files with SQL Server
- Enterprise Resource Planning
- Customer Relationship Management (CRM)
- Building a Reporting Data Server
- Building a Database Documenter, Part 1
- Building a Database Documenter, Part 2
- Data Management Objects
- Data Management Objects: The Server Object
- Data Management Objects: Server Object Methods
- Data Management Objects: Collections and the Database Object
- Data Management Objects: Database Information
- Data Management Objects: Database Control
- Data Management Objects: Database Maintenance
- Data Management Objects: Logging the Process
- Data Management Objects: Running SQL Statements
- Data Management Objects: Multiple Row Returns
- Data Management Objects: Other Database Objects
- Data Management Objects: Security
- Data Management Objects: Scripting
- Powershell and SQL Server - Overview
- PowerShell and SQL Server - Objects and Providers
- Powershell and SQL Server - A Script Framework
- Powershell and SQL Server - Logging the Process
- Powershell and SQL Server - Reading a Control File
- Powershell and SQL Server - SQL Server Access
- Powershell and SQL Server - Web Pages from a SQL Query
- Powershell and SQL Server - Scrubbing the Event Logs
- SQL Server 2008 PowerShell Provider
- SQL Server I/O: Importing and Exporting Data
- SQL Server I/O: XML in Database Terms
- SQL Server I/O: Creating XML Output
- SQL Server I/O: Reading XML Documents
- SQL Server I/O: Using XML Control Mechanisms
- SQL Server I/O: Creating Hierarchies
- SQL Server I/O: Using HTTP with SQL Server XML
- SQL Server I/O: Using HTTP with SQL Server XML Templates
- SQL Server I/O: Remote Queries
- SQL Server I/O: Working with Text Files
- Using Microsoft SQL Server on Handheld Devices
- Front-Ends 101: Microsoft Access
- Comparing Two SQL Server Databases
- English Query - Part 1
- English Query - Part 2
- English Query - Part 3
- English Query - Part 4
- English Query - Part 5
- RSS Feeds from SQL Server
- Using SQL Server Agent to Monitor Backups
- Reporting Services - Creating a Maintenance Report
- SQL Server Chargeback Strategies, Part 1
- SQL Server Chargeback Strategies, Part 2
- SQL Server Replication Example
- Creating a Master Agent and Alert Server
- The SQL Server Central Management System: Definition
- The SQL Server Central Management System: Base Tables
- The SQL Server Central Management System: Execution of Server Information (Part 1)
- The SQL Server Central Management System: Execution of Server Information (Part 2)
- The SQL Server Central Management System: Collecting Performance Metrics
- The SQL Server Central Management System: Centralizing Agent Jobs, Events and Scripts
- The SQL Server Central Management System: Reporting the Data and Project Summary
- Time Tracking for SQL Server Operations
- Migrating Departmental Data Stores to SQL Server
- Migrating Departmental Data Stores to SQL Server: Model the System
- Migrating Departmental Data Stores to SQL Server: Model the System, Continued
- Migrating Departmental Data Stores to SQL Server: Decide on the Destination
- Migrating Departmental Data Stores to SQL Server: Design the ETL
- Migrating Departmental Data Stores to SQL Server: Design the ETL, Continued
- Migrating Departmental Data Stores to SQL Server: Attach the Front End, Test, and Monitor
- Tracking SQL Server Timed Events, Part 1
- Tracking SQL Server Timed Events, Part 2
- Patterns and Practices for the Data Professional
- Managing Vendor Databases
- Consolidation Options
- Connecting to a SQL Azure Database from Microsoft Access
- SharePoint 2007 and SQL Server, Part One
- SharePoint 2007 and SQL Server, Part Two
- SharePoint 2007 and SQL Server, Part Three
- Querying Multiple Data Sources from a Single Location (Distributed Queries)
- Importing and Exporting Data for SQL Azure
- Working on Distributed Teams
- Professional Development
- Application Architecture Assessments
- Business Intelligence
- Tips and Troubleshooting
- Additional Resources
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:
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:
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:
I click “Next” after I fill out this panel and then I get a feedback panel stating that all is well:
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.
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.
Now I have a new node underneath the SQL Server Agent | Jobs area in my “Master” server – called “Multi Server Jobs.”
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.
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.
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.
When I finish the CMS project, I’ll post it here.