Home > Articles > Data > SQL Server

SQL Server Reference Guide

Hosted by

Toggle Open Guide Table of ContentsGuide Contents

Close Table of ContentsGuide Contents

Close Table of Contents

The SQL Server Central Management System: Centralizing Agent Jobs, Events and Scripts

Last updated Mar 28, 2003.

In this tutorial I’m continuing a series on building a system that you can use to monitor and track your SQL Server systems, and in fact, any kind of system you like (The first article in this series is here). You can use the concepts you find here for lots of SQL Server applications, since in essence it uses many of the features and tools in SQL Server, specifically SQL Server 2008. Too often we look for a canned “solution” rather than learning the tools we have — which we can use to build whatever we need. Even if you’re not interested in a monitoring and management solution, you can find information in this series of articles that will help you in many aspects of your daily job with SQL Server, from problem-recovery to good coding practices.

At the bottom of this article I reference a CodePlex (Microsoft’s open-source software site) where I’m creating a solution called the SQL Central Management System, or SQLCMS. If you’re interested in participating, just post a notice there that you want to join in the solution. We’ll design it together. I’m working through that project in this series of articles.

In the solution I’m building, there are three basic “components”:

  1. Storage
  2. Execution
  3. Reporting

This tutorial covers one aspect of the execution component of the project, and in specific using this system as a central location for SQL Agent jobs, an Alert center, and a place to store your team’s scripts.

SQLCMS as a Master Job Server (MSX/TSX)

In a previous tutorial I explained the mechanics for a Master and Target Job Server system, referred to as MSX/TSX in some documentation. You can refer to that tutorial for the system setup; in this tutorial I’ll explain more about the operation of that feature as it applies to the SQL Server Central Management System (SQLCMS) I’m setting up.

As explained in that previous tutorial, a Master Job Server is a single system that you designate (using a Wizard) that stores SQL Agent Jobs, and it sends them on “Target” Servers. You can designate a system as a Target from the Master Server or on the Target, all using a Wizard.

There are a couple of thoughts that are important to keep in mind as you design your SQLCMS system as a Master Job server. First, you need to think about the versions and editions of each the systems you plan to monitor and manage in your enterprise with the SQLCMS.

You can use SQL Server 2008 (which is the version of choice for the SQLCMS) Standard Edition and higher as a Master Job server for all SQL Server 2008 and SQL Server 2005 editions other than Express, which does not use the Agent feature. You can’t use this feature against SQL Server 2000 editions — they don’t have the same Agent subsystem, so the transfer of Jobs won’t work there, or even run there.

You should also exercise care when you create the Jobs that you’ll send down to the Target servers. Keep in mind that the servers can have Jobs of their own, and that you might not own those, so you don’t want to set up something that conflicts with the Jobs someone else creates locally. Also, if you use drive letters or anything like that within the Steps of your Jobs, the drive letters, security, users, and other considerations need to be on each server, or the Job will fail there. This is one of the main reasons I tend to use a Backup Device instead of a file path for my backup jobs. I can then reference the Backup Device, which can point to any kind of path or tape drive, using a single name rather than thinking about the drive paths or tape names on each system.

The point is that you should consider the fact that your environment may not be as homogenous as you might like, and this may be a good time to clean up the differences in the systems while you’re setting up the SQLCMS. In fact, the Policy Based Management (PBM) feature in SQL Server 2008 will help you check that first – you might want to make some policies that check for the settings you want before you “adopt” a system into the SQLCMS.

SQLCMS as a Central Alert Server

A similar thought process is useful in setting up the SQLCMS as the central server where Events are forwarded. I've explained how to set that up in this article, so you can refer to that as a starting point if you are unfamiliar with that technology. Once again, you should only “trust” this process for SQL Server 2005 and higher, and once again, this isn’t as useful for a SQL Server Express Edition.

Another important consideration for this process is the way this feature works. It actually is a Windows process — the Events recorded in the Event System in Windows records the event in the “master” server — which is then read by the SQL Agent system on the “master” server. So you’ll need to ensure that the “Target” system can write to the Master’s Event logs (in Windows) and that the SQLCMS is the Default Instance — or the Agent may not pick up the event.

The job that fires in response will run on the Master server, so keep that in mind as well. You may have to parse the error text so that you can determine which server to respond to. Personally, I use this as a notification system, rather than a reaction system.

Don’t let all of these considerations and limitations scare you — just be aware of them, and work them into your plans and strategy. You may be able to completely rely on this system for all of your Job and Alert needs, or it may form only a part of the ecosystem. Once again, that’s the beauty of the SQLCMS system, it’s something that you design to suite your own needs, not something that you’re trapped into doing in a certain way.

SQLCMS as a Script Repository

Many data shops keep a single location for their administrative scripts. I’m not referring to the code that runs production programs — that should be under a source-control system that is well documented and maintained by the development team. In fact, your “DBA” scripts may be placed in that system as well, and if so, you don’t need another system for that purpose.

But perhaps that system is closed to you, or you are separated from the development team, or for some other reason you don’t have a location that you’re currently using for your administrative scripts. If that’s the case, you can use the SQLCMS to hold those scripts for you.

Understand that I’m not proposing setting up SQL Server as a Code Repository. There are far too many other options for that, software that costs money, software that is free, and lots of things in between. You won’t use this system for “checkout” and “checkin” features, or any version control. It simply serves as a central, documented location for your small DBA library of templates, scripts, functions, stored procedures and more.

You have a few options for this storage. The first is to use a schema within the MDW database and just store all of the scripts in that schema. This has the advantage of being secured, backed up and maintained along with the database. You can also use those extended properties that I showed you in the first tutorial in this series to document them or add a version to them.

If you decide to store your code this way, I recommend that you include your comment-blocks after the AS statement, like this:

CREATE PROCEDURE usp_MyTestProc
AS
/* Put the comments here about what the 
code does and who authored it. That way it 
shows up when you script the proc out.
*/
Instead of this:
/* Putting comments here only 
lasts as long as the creation of 
the stored procedure. */
CREATE PROCEDURE usp_MyTestProc
AS

Now, you might be thinking, “but I don’t create all my scripts as Stored Procedures. Some are just T-SQL, and others are even PowerShell scripts.” Well, you can “cheat” and make everything a Stored Procedure, using the block comments as the actual code. I think that’s pushing it myself, so you might want to switch to another option: use the file system in Windows and create a share. You can secure that, use folders, and all kinds of other advantages, but you need to ensure that it is backed up and maintained properly.

Still another option is to use the new FileStream option in SQL Server 2008 to store your scripts, but you’ll need to write some code to get the information in and out. Or you can use a VARCHAR(MAX) field, although I’ve had issues with special characters there, and PowerShell is full of those. So I use a file share, and then point to that in my final web page that I make for the SQLCMS – which we’ll come to shortly.

InformIT Articles and Sample Chapters

CVS is an open-source product that you can use as a Code-Control system. You can read a great intro to that product in The Best Software Configuration Management Tools for Cross-Platform Development Projects

Books and eBooks

For industrial-grade enterprise projects, I’ve come to rely on Visual Studio Team Services. Software Engineering with Microsoft Visual Studio Team System (also available as a downloadable eBook and in Safari Books Online) is a good book on that.

Online Resources

The SQL Central Management System (SQLCMS) CodePlex project is located here.