The escalation engineers in the SQL Server Product Support Services (PSS) group have a complex job. Of course, they help callers solve specific problems. But one of their primary jobs is to help customers learn how to prevent problems in the first place. Over the past few weeks, I've shared advice I got from Bob Ward, an escalation engineer for SQL Server PSS. Ward explained that, although most customers know about the best practices that will prevent problems in their systems, many don't adhere to those best practices. Our readers have confirmed Ward's observation. The past three Instant Polls on the SQL Server Magazine Web site have asked readers if they follow these best practices, and most respondents have acknowledged that they don't. This result reveals that many customers are leaving their systems vulnerable to problems.
In the past two issues of SQL Server Magazine UPDATE, I discussed two of the three best practices that Ward recommends: establishing and testing a recovery plan and creating a performance baseline for your system. This week, I close the best-practices discussion by looking at Ward's third recommendation: tracking configuration changes and settings within the servers and databases you support.
Have you or a colleague ever said, "Wow! That database setting doesn't seem right. I wonder how long it's been like that?" If so, Ward's advice applies to you. Ward says that a surprising number of support calls revolve around the lack of a solid configuration-management plan. Too many customers simply don't track how and when changes are made to their server environments—and this lack of ongoing awareness can create many support problems. When you don't track your system's configuration, you might
- inconsistently apply service packs and security patches
- drop or add an index on a production box for testing purposes, then forget to add the index again when testing is finished
- change the database recovery model setting for bulk load tasks, then forget to reset it when the tasks are complete
- purposely or accidentally make a poor database configuration choice such as turning on auto shrink for production databases that experience widely ranging volumes of data in the course of a standard usage cycle
- be unable to reset a production database to its original configuration after a complete rebuild because no one knows for sure what the original server and database settings were
The list of possible problems is almost infinite. But focusing on the list misses the point. Support calls—and the daily management of our database systems—would be much simpler if we tracked metadata-level changes to our database environments more rigorously.
I've spent the past few weeks establishing that a problem with best-practice compliance exists. But so far, I haven't tried to offer advice about how customers can do a better job of adhering to the best practices we've discussed, nor have I queried Microsoft for ideas about what the company can do to make best practices easier for customers. I have some thoughts about both sides of the equation, and 'll share them with you over the coming weeks. But I'd also like your input. Do you or your colleagues successfully implement these best practices? Send me an email describing your techniques. Do you have ideas about how Microsoft can make avoiding problems easier for us? Tell me your ideas. I'll share the best advice with your fellow SQL Server Magazine UPDATE readers.