Table of Contents
- Microsoft SQL Server Defined
- Microsoft SQL Server Features
Microsoft SQL Server Administration
- The DBA Survival Guide: The 10 Minute SQL Server Overview
- Preparing (or Tuning) a Windows System for SQL Server, Part 1
- Preparing (or Tuning) a Windows System for SQL Server, Part 2
- Installing SQL Server
- Upgrading SQL Server
- SQL Server 2000 Management Tools
- SQL Server 2005 Management Tools
- SQL Server 2008 Management Tools
- SQL Azure Tools
- Automating Tasks with SQL Server Agent
- Run Operating System Commands in SQL Agent using PowerShell
- Automating Tasks Without SQL Server Agent
- Storage – SQL Server I/O
- Service Packs, Hotfixes and Cumulative Upgrades
- Tracking SQL Server Information with Error and Event Logs
- Change Management
- SQL Server Metadata, Part One
- SQL Server Meta-Data, Part Two
- Monitoring - SQL Server 2005 Dynamic Views and Functions
- Monitoring - Performance Monitor
- Unattended Performance Monitoring for SQL Server
- Monitoring - User-Defined Performance Counters
- Monitoring: SQL Server Activity Monitor
- SQL Server Instances
- DBCC Commands
- SQL Server and Mail
- Database Maintenance Checklist
- The Maintenance Wizard: SQL Server 2000 and Earlier
- The Maintenance Wizard: SQL Server 2005 (SP2) and Later
- The Web Assistant Wizard
- Creating Web Pages from SQL Server
- SQL Server Security
- Securing the SQL Server Platform, Part 1
- Securing the SQL Server Platform, Part 2
- SQL Server Security: Users and other Principals
- SQL Server Security – Roles
- SQL Server Security: Objects (Securables)
- Security: Using the Command Line
- SQL Server Security - Encrypting Connections
- SQL Server Security: Encrypting Data
- SQL Server Security Audit
- High Availability - SQL Server Clustering
- SQL Server Configuration, Part 1
- SQL Server Configuration, Part 2
- Database Configuration Options
- 32- vs 64-bit Computing for SQL Server
- SQL Server and Memory
- Performance Tuning: Introduction to Indexes
- Statistical Indexes
- Backup and Recovery
- Backup and Recovery Examples, Part One
- Backup and Recovery Examples, Part Two: Transferring Databases to Another System (Even Without Backups)
- SQL Profiler - Reverse Engineering An Application
- SQL Trace
- SQL Server Alerts
- Files and Filegroups
- Full-Text Indexes
- Read-Only Data
- SQL Server Locks
- Monitoring Locking and Deadlocking
- Controlling Locks in SQL Server
- SQL Server Policy-Based Management, Part One
- SQL Server Policy-Based Management, Part Two
- SQL Server Policy-Based Management, Part Three
- Microsoft SQL Server Programming
- Performance Tuning
- Practical Applications
- Professional Development
- Application Architecture Assessments
- Business Intelligence
- Tips and Troubleshooting
- Additional Resources
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:
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.
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.
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
- Backup Device
- Broker Priority
- Broker Service
- Cryptographic Provider
- Data File
- Database Audit Specification
- Database Ddl Trigger
- Database Maintenance
- Database Option
- Database Performance
- Database Role
- Database Security
- File Group
- Full Text Catalog
- Full Text Index
- Full Text Stop List
- Linked Server
- Log File
- Login Options
- Message Type
- Multipart Name
- Partition Function
- Partition Scheme
- Plan Guide
- Remote Service Binding
- Resource Governor
- Resource Pool
- 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
- Stored Procedure
- Surface Area
- Surface Area for AS
- Surface Area for RS
- Symmetric Key
- Table Options
- User Defined Aggregate
- User Defined Data Type
- User Defined Function
- User Defined Table Type
- User Defined Type
- User Options
- 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.
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.”
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.”
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.
The official documentation for PBM is here.