In my last post, Data is Power, I talked about the need to bring data to decision makers to support your requests for more resources. We had a good discussion there about whether or not data is enough and what sorts of experiences people have had getting management to act.


I said that QUESTIONS lead to DATA which lead to ANSWERS.


Question Everything


This week I want to continue the discussion about what sorts of questions we should be asking ourselves and our servers.  I think great database administrators should have the minds of  3 year olds.  Well, not exactly, but in the sense of looking around and questioning everything. What is that? When? How? Why is that?


The key to a collaborative environment, though, is to question without judging.  Our attitudes should be about getting to why and therefore answers, not "whom to blame".


These, off the top of my head:


General inventory

  • How many servers is your team supporting?
  • What is the ratio of databases / instances to DBA?
  • How many instances?
  • How many databases?
  • How many tables?
  • How much data?
  • How often are backups taken?
  • How often are restores tested?
  • …I'm not going to list every database object, but you get the picture.


  • What queries run the slowest?  Why is that?
  • What queries run the most often?  The least? Why is that?
  • What databases lead to the greatest pain points? Why is that?
  • What queries have been changed the most over time? Why is that?
  • What hardware configurations have had the best performance? Why is that?
  • What query authors struggle the most with writing queries that "just work"? Why is that?
  • What applications have the worst performance? Why is that?
  • What applications and databases lead to the most on-call incidents? Why is that?
  • What applications and databases lead to the most after hours on-call incidents?

Data Integrity and Quality

  • What database design patterns have worked the best? Why is that?
  • What data has cost the organization the most? Why is that?
  • What data has the most pain points? Why is that?


As you can see, there are lots of questions and not a lot of answers here.  We'll get to that next week.  But for now, you can sort of see a pattern in the questions, right? Why is that?

What questions do you think we should be asking in managing databases?  Don't worry about whether the answers are hard to get -- asking the question is sometimes valuable enough.


Then next post in this series is about Data Time ZonesAnswers in Data: So Much Data...So Little Time...Data Time Zones