Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

Chapter 19: Playing Administrator
Policy Based Management
This is a relatively advanced feature that is new with SQL Server 2008. The idea is fairly simple: Modern
relational systems are all about proactive management of your data — why not proactively manage the
objects and rules applied to the server?
With Policy Based Management, you establish a set of rules to govern your server or even all servers in
your domain. There is a wide list of items that can have policies attached to them, for example:
❑ Object names: Want to enforce that all stored procedures begin with “sp”? No problem. You can
establish such a rule using Policy Based Management.
❑ All databases should have the ANSI ARITHABORT option set to true by default.
How exactly these are enforced is set by rule — treatment options include:
❑ On Demand: Only check for violations of policy when an administrator has specifically
requested the policy audit.
❑ Scheduled: Run an audit of policy violations according to some schedule (creating a list of violations,
but not changing anything).
❑ On Change: Prevent: This proactively prevents the policy violation from being allowed. Under
our earlier example, any stored procedure that didn’t start with sp would fail during creation.
❑ On Change – Log: This notes the violation, but simply logs it (facilitating later reporting).
Most installations will not need the power behind Policy Based Management, but it is a tremendous leap
forward in manageability for larger, multi-server environments.
Summary
584
Well, that gives you a few things to think about. It’s really easy to, as a developer, think about many
administrative tasks and establish what the increasingly inaccurately named Hitchhiker’s Guide to the
Galaxy trilogy called an “SEP” field. That’s something that makes things like administration seem invisible
because it’s “somebody else’s problem.” Don’t go there!
A project I’m familiar with from several years ago is a wonderful example of taking responsibility for
what can happen. A wonderful system was developed for a non-profit group that operates in the Northwestern
United States. After about eight months of operation, an emergency call was placed to the company
that developed the software (it was a custom job.) After some discussion, it was determined that
the database had somehow become corrupted, and it was recommended to the customer that the database
be restored from a backup. The response? “Backup?” The development company in question missed
something very important. They knew they had an inexperienced customer that would have no administration
staff — who was going to tell the customer to do backups and help set it up if the development
company didn’t? I’m happy to say that the development company in question learned from that experience,
and so should you.