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.
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:
- 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