Bill Richards recently wrote a nice article for SQL Server Central. You can read the original article here.  The article covered a checklist DBAs should follow each morning. Buck Woody in his weekly podcast, Real World DBA Episode 5 - The DBA Checklist, covered the same topic.

Routinely checking that your systems are in compliance with your guidelines/policies is a critical component of every DBA's job. Often times these simple checks are enough to prevent a bad situation from turning even worse.

Manual checklists, though, are error prone. What happens when you're late getting into the office, or have an early morning meeting, or your on vacation? Any situation that alters your morning ritual increases the likelihood the checklist is missed for that day.

This is where Policy-Based Management can help. Most of the checks listed in these articles can be turned into an automated policy check. If the system is out of compliance with one or more policies it will write to the event log. If your shop is using a system management tools (MS System Center, IBM Tivoli, HP Openview, etc) you can monitor the logs for specific messages.

If your shop doesn't use a monitoring tool PBM can be configured to send email (using DB Mail and Agent Alerts) when it detects an out of compliance situation. I recommend setting up each policy in the daily checklist to run nightly. The out of compliance emails should go to a DBA distribution list rather than an individual. This way there are multiple eyes looking at violations - redundancy should be a golden rule.

Depending on the size of your environment the manual check list could take you 15-30 minutes each morning. At 15 minutes a day, you're spending 65 hours a year, assuming you check only on week days. That's a week and a half a year spent verifying everything is what it should be. I don't mean to imply this isn't time well spent. If it avoids a disastrous situation it's worth more than that. But I know I'd love to get back a week and a half a year.

With PBM you'll get this time back which you can spend on other valuable DBA activities. This sounds like the start of a compelling reason to upgrade to SQL Server 2008. Okay, that last bit sounded too much like marketing speak. Sorry!

In a future posting we'll turn a few of these checklist items into policies.