SQL Server Reference Guide

SQL Server Policy-Based Management, Part One

Last updated Mar 28, 2003.

In most database platforms, you set up the environment to allow access to various database objects and server and platform settings, but you don’t have a great deal of control after the rights to those objects and system settings are granted. And in many cases you have to work in a reactive mode, where you monitor for changes and then react to them once they have occurred.

Policy-Based Management, a new feature starting with SQL Server 2008, is a new way of managing your SQL Server systems. Using a series of new settings, you can prescribe the way you want your server settings and database objects to be, and the system will take the responsibility to make things stay that way. In a sense, you’re defining your intent for the system, and the system maintains that intent.

You do all this using various Policies that you can define or import to your system. In this tutorial I’ll explain the parts of this new feature, and I’ll demonstrate a simple Policy that you can follow in the next tutorial.

Policy-Based Management Components

I’ll begin with a definition of all the new terms you’ll need to learn to use Policy-Based Management. These are new terms in some cases and in others it’s a word that has been “re-used.” Understanding these terms is the first thing you need to learn.

I’ll include a rather busy graphic here, but you can refer back to it as you read the following sections. This represents not only the components of Policy-Based Management, but also the flow of the Policy checking and enforcement:

Policy

A SQL Server 2008 “Policy” is the outermost container of all of the rest of the elements. It is actually an XML document, but in a moment I’ll show you how to create the Policy with the graphical tools that you can find in SQL Server Management Studio (SSMS). This document can be stored on the server in the msdb database, or on the file system. By storing them in the database, you provide a central, secure location where you can run them. By storing them on the file system, you can copy them and send them around wherever you like. You can also export a Policy to a file, or import a Policy file into the msdb database.

Microsoft includes several Policies in the initial installation, as files on the hard drive. Many of these are based on the SQL Server “Best Practices Analyze,” or BPA. You can find them here: C:\Program Files\microsoft sql server\100\Tools\Policies.

A Policy also can be enabled or disabled — meaning that you can make a Policy but not have it available to run if you wish.

Target

Each Policy can be applied to one or more databases and database objects. Interestingly, you can “filter” which databases or database objects you want to exclude by using a “Condition” that I’ll explain in a moment.

Facet

A Policy-Based Management “Facet” is one or more database objects, or in fact the database or a server Instance. On each Facet is a set of “Properties” or “Fields.” For instance, one of the Facets is “Database.” On that Facet is a Property called @Name, which is the name of the database.

Now you might think that this is redundant — after all, a Database object already has a “Name” Property that you can read programmatically and with Transact-SQL commands. But Facets go further — they are not only single objects like Databases but other, well, Facets of database objects or even combinations of objects.

Microsoft has included many Facets in SQL Server 2008, and plans to include more in future releases. You can find most of the Facets by right-clicking any database object in SSMS and selecting “Facets” from the menu that appears. Here’s a partial list:

• Application Role
• Asymmetric Key
• Audit
• Backup Device
• Broker Priority
• Broker Service
• Certificate
• Credential
• Cryptographic Provider
• Data File
• Database
• Database Audit Specification
• Database Ddl Trigger
• Database Maintenance
• Database Option
• Database Performance
• Database Role
• Database Security
• Default
• Endpoint
• File Group
• Full Text Catalog
• Full Text Index
• Full Text Stop List
• Index
• Linked Server
• Log File
• Login
• Login Options
• Message Type
• Multipart Name
• Name
• Partition Function
• Partition Scheme
• Plan Guide
• Remote Service Binding
• Resource Governor
• Resource Pool
• Rule
• Schema
• Server
• Server Audit
• Server Audit Specification
• Server Configuration
• Server Ddl Trigger
• Server Information
• Server Performance
• Server Security
• Server Settings
• Server Setup
• Service Contract
• Service Queue
• Service Route
• Statistic
• Stored Procedure
• Surface Area
• Surface Area for AS
• Surface Area for RS
• Symmetric Key
• Synonym
• Table
• Table Options
• Trigger
• User
• User Defined Aggregate
• User Defined Data Type
• User Defined Function
• User Defined Table Type
• User Defined Type
• User Options
• View
• View Options
• Workload Group
• Xml Schema Collection

You can only add one Facet to a Policy at a time, but you can have multiple Policies on a given set of targets.

Condition

Conditions are where the real power comes in for Policy-Based Management. A Condition is one or more comparisons of a Facet property to a value. For instance, one condition you might create could involve the Database Facet and its @LastBackupDate field. You could compare that using an equality (=) or a greater or lesser than, or even an inequality (!=) to a date you select. This particular condition would show if the date that the database was last backed up was equal (or some other comparison) to a specific date. I use this Condition frequently to check that the database has been backed up in today’s date, using a value of “GetDate().”

That brings up an interesting point. You could hard-code a value that you want to compare, and this is what you’ll do quite often — perhaps you’re comparing the @RecoverModel value to “Simple.” But if the value can be checked against a function (like GETDATE()) then you can create a very flexible set of conditions to work with.

You can have multiple conditions against a single Facet. So you could check that a Database Facet is in @RecoveryModel=”Simple” and @LastBackupDate = GetDate(). This lets you set up the exact status you want your databases to be in, and then you can check all your databases at once to match against these settings.

Breaking out the Facets and Conditions like this means that they can be re-used — in fact, the “Targets” I mentioned earlier are just Conditions against Facets. So you could apply the settings you just created against the Database Facet on Targets that are based on only user databases — not system ones.

It’s a bit like a chess game — it’s simple to explain, but as you start combining the possible choices, it can become very complex. I’ll demonstrate a few practical examples in the next tutorial so that this makes a little more sense.

Policy-Based Management Evaluation Modes

Once the Policy is defined against a set of Targets, you’ll notice several “Evaluation Modes” as a selection. I’ll explain each one in turn, and then I’ll show you how they work in the next tutorial.

One Change: Prevent

This mode is only available for SQL Server version 2008 and higher, and only for events that happen within a transaction. Don’t worry — if you can’t run the Policy in this mode, the system will prevent you from choosing it.

What happens during this mode is that when a user or process attempts to complete the action, the Policy-Based Management (PBM) Engine detects the attempt as violating the Policy and then it issues a rollback command. That’s why this mode is available only in SQL Server 2008 Targets — the older versions of SQL Server don’t have this engine.

One Change: log only

This mode is also only available for SQL Server version 2008 and higher. In this case the event is not rolled back, but it is recorded in the SQL Server Error Logs. It’s also recorded in a set of tables in the msdb database, and you’ll get a visual signal on the objects that are “out of Policy.”

On schedule

This mode is also only available for SQL Server version 2008 and higher. With this mode, you set a schedule which will run across all of the servers you designate and check the Policy. If the Policy is violated, it is logged just as in “log only.”

On demand

This mode is available for SQL Server version 2000 and higher. All you do is right-click the Policy and “evaluate” it against the servers you select. The results of the evaluation are once again stored in tables in the msdb database and shown on the screen.

I’ve mentioned PowerShell before here at InformIT, and you can use that to evaluate a Policy as well. In fact, you can schedule a PowerShell script, and you can evaluate a Policy in PowerShell, and you can use the “On demand” mode in a Policy, so using this method you can indeed schedule a Policy against SQL Server 2000 and 2005 systems! I’ll show you how to do that in the next installment as well.

InformIT Articles and Sample Chapters

There’s a lot more about PowerShell starting in this series of updates here in the SQL Server Reference Guide. You can read up on that before you move on to the next tutorial.

Books and eBooks

Ross Mistry has a great book, SQL Server 2005 Management and Administration, that will help you understand the general settings that you can use as Facet choices.

Online Resources

The official documentation for PBM is here.