- 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
The SQL Server Central Management System: Centralizing Agent Jobs, Events and Scripts
Last updated Jun 19, 2009.
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”:
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.