SQL SERVER – 2008 – Policy-Based Management – Create, Evaluate and Fix Policies

This article will cover the most spectacular feature of SQL 2008 – Policy-based management and how the configuration of SQL Server with policy-based management architecture can make a powerful difference. Policy based management is loaded with several advantages. It can help you implement various policies for reliable configuration of the system. It also provides additional administration assistance to DBAs and helps them effortlessly manage various tasks of SQL Server across the enterprise.

1 Introduction
2 Basics of Policy Management
3 Policy Management Terms
4 Practical Example of Policy Management
4.1 Exploring of Facets
4.2 Create a Condition
4.3 Create a Policy
4.4 Evaluate a Policy
4.5 Fix Non-complying Policy
5 Summary

Read complete article here.

Practical Tips for Policy-Based Management

The easiest way to start is with a small policy that everyone agrees on. I like to begin with checks such as Auto Close and Auto Shrink being off for every user database. Both settings cause more trouble than they solve on most servers, and a policy will find every database where someone turned them on.

Each policy runs in one of four evaluation modes:

• On demand: you run it yourself when you want.
• On schedule: SQL Server Agent runs it and records the result.
• On change: log only: a change that breaks the rule is allowed but logged.
• On change: prevent: the change is rolled back.

The two on change modes work only for facets that SQL Server can watch as changes happen, so not every condition can use them. Test a prevent policy carefully, because a strict rule can stop a deployment script in the middle of a release.

Policies are stored in msdb, and you can export them as XML files. That makes it easy to keep one set of rules in source control and apply it to many servers. With a Central Management Server, you can evaluate the same policy against a whole group of servers at once.

Start with two or three rules, review the results for a few weeks, and add more only when the team trusts the first ones. A long list of failing policies that nobody reads helps no one.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.