Did you ever stop to think that you need to manage your database management data* just as well as you do your "regular" organizational data? That means you should be practicing what you preach.  There's a heap of clichés I can use here…and I probably will.

We've talked about Questions, Data and Getting to Answers in this series.  Now let's talk about how we need to administer all that data and answers.  We give our IT customers all kinds of advice on just how to do that…and yet way too many of us show them that we want them to do as we say, not as we do.

How do you collect all your database and systems data?  Do you use dozens of custom scripts and store your administration data in spreadsheets, XML files, CSVs and random tables across various servers and systems?  How do you protect that data?  Do you know if it contains sensitive data? Do your corporate attorneys?  Do you know where your most up-to-date copy of your resume is, right now? You might need it in a hurry.

1. Follow your own security advice. That means not running monitoring and other data collection solutions as SA or Admin.  Using role-based, LDAP, or other more professional approaches to security.  It means securing all the data, especially when your database administration data includes sensitive data.  This is especially true when you are capturing queries and parameters.
2. Don't spread data all around.  You need a well-managed, perhaps centralized point to track where and what your database admin data is.  If it is stuck in spreadsheets, random tables, proprietary data stores, XML files, CSVx, etc. you are going to have a very costly and difficult time getting answers. 
3. Collect what you need, only when you need it. Just because you CAN collect some data, doesn't mean you need to collect it, nor does it mean you need to collect it many times over.  Barring legislative mandates to collect data, are you sure you need to collect it? An example is using a Profiler trace for every single event, all the time, instead of the ones need when you need it. Which leads us to the next tip…. 
4. Know what is worth collecting. This means you need to understand what each systems meta data item represents. Is it all the statistics since the service last restarted? Since it was turned on? Just for the last 2 weeks? 2 Hours?  Does it really represent what the name says it does? Understanding the data requires training and learning.
5. Set a good archiving strategy.  Sure, storage is free.  Except when it is not.  And collected data brings all kinds of expenses - security, archiving, backups, restoring, administering.
6. Don't alert for every single event. Alert burn out is dangerous.  If you are getting too many alerts, you learn to snooze them or dismiss them without giving the serious ones the attention they deserve.  We've all done that. Don't be that guy whose phone is buzzing every 2 minutes with a new alert. 
7. Change control/Configuration.  I see this one all the time.  IT staff that need change control and configuration control on customer systems seem to think they can manage their own data in a free-for-all-devil-may-care attitude.  And then they fail their customers by missing something important.  Or having bad data.  The saying that sends chills through my spine is "I only changed one simple thing, so I just promoted it into production."  And then for some weird reason ten systems went down in flames.
8. Versioning. Trust me on this.  Your scripts are no different than other code. Some day you are going to want to roll back. Or you want to know why you are getting different data.  Or you'll want to know why the ten systems are going down in flames.
9. Backups/Restores. Yes, the physics of data mean that sometimes hardware fails.  Or scripts. Or that "one small change" happens.  You'll want to have a backup handy for your database data, too.  It's not overkill; It's doing the right thing.
10. Governance. All of these tips really come down to data governance for database data.  I know not everyone likes that term. You've told management you need certain rules in place for managing "real" data.  This is now your chance to dogfood your own rules.  And if tastes bad for you, it tastes bad for everyone else.  Nothing inspires IT teams to resist governance like governors who think they are above doing things they way they want everyone else to do their work.  Database management governance really just means administering your database data the same way you'd administer all your organization's other data.

So I'll leave you with this: Love your Database Data.  It's just as imporant as all the other corporate data you manage. You'll find your Answers there.  So you'll want to ensure your data is there when you need it.  The right data, at the right time.  Your boss needs to understand that.  And fund it. Trust me.

Questions for You

So what else do we need to do with metadata about databases and systems?  Do you think these are all really obvious things? Then why don't we see more shops managing their data this way?

*Yes, I used manage- there twice and data twice.  It's meta times two.  You are welcome.