Showing results for 
Search instead for 
Did you mean: 

Question Everything...

Level 12


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

Level 14

Great post!

Too many groups are stammering, running and hiding when these questions are asked.  Do yo get a visual of someone squirming in a chair when these are asked?  I do.


Level 12

So surely there are more questions...which ones have you asked?

Level 18

datachick, your statement "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"." , is very important.  It sets the stage for an overall IT team which is what any shop is. 

Regarding those specific questions, not being a DBA myself, many people outside of a DBA team aren't going to ask those questions because they don't know enough about how the container for their data works.
Included in there are references to tribal knowledge which may or may not be documented for the benefit of others.  Some of those questions I do ask because I have learned to ask them.  Some are beyond the scope of my job function...and in some cases could require some tools that when turned on can impact the database environment.

Level 12

Great comments.  And I'm really focusing on the questions, not just which ones are easy to answer.  Or even possible.  Here's a secret: I'm not a DBA, either.  But as a Project Manager and Architect, I ask these sorts of questions all the time.  Mostly because I want in increase the organization's success rates for data and therefore business results.

Even "Why is this so slow" is a good starting place.

Level 18

That question gets asked a lot....the challenge is determining the answer...which is usually in that data we talked about last week.

Level 9

There is a mass of information, we try and teach our clients they do need to know everything - otherwise will just be swamped and noise. Only the essentials, this saves a lot of unnecessary data...grantallenby

Level 12

I'd want to know if the platform that the database is running on was purpose-built for a database, or was it used because it was available at the time? I've seen many database problems that are rooted in bad design at the server and storage levels. Unless you design the system specifically for a database, and even specifically for the performance requirements of the database, you're asking for trouble.

I agree that these questions are important to ask, datachick.

Level 12

I think we need to question everything.  Maybe not every day.  Maybe not with the same priority.  But being able to ask questions is how we progress.  On projects where asking questions is seen as frivolous, I see a lot of fail.

So I'm not saying we have to collect ALL THE DATA.  But asking questions leads to asking more questions.  I'll be writing about that next week.

Level 21

I am not clear on if this post is about the important process of asking questions or if the purpose is to generate a list of questions regarding database performance?

Level 12

I guess it's both.  I'm looking for specific questions, but also encouraging people to ask questions.

Level 19

How much storage space they're taking up for sure is important!

Level 12

Oh, yeah. storage questions are completely missing in my list.

Level 12

Storage as ecklerwr1 mentioned.  Along those lines also:

- Data Retention: How long does that login data need to be kept? What about the inventory change history? What about image information? How often does a cleanup need to be run (daily/weekly/monthly)?

- Data Backup: How long do backups need to be kept around? Do they need to be on-site? Has the customer been promised any restore timelines in the event of issues?

- Data Growth: Have we identified the growth for the application/data? Are we expecting 2-5GB a month? Or 2-5GB a week? How does that number change if we adjust users using it? We deployed a new application 2 weeks ago that was not supposed to use much data, and already chomped up 150GB of SAN space, and still growing.

Others that has caught us out from time to time...

- Scheduled Tasks: Do we run regular tasks against the database that'd be impacted by things like backups or indexing? Reporting needs? Read-only database copies?

- Other Systems: Which other systems will be using this data? Does application A have the same design team as application B? Will changes to the database break app B? I've seen a number of times where a stored procedure did a select * from table but the data set in .NET was looking at column counts and broke because too few/many columns came back when a team made changes.

- Data Flow Diagrams: Is the flow of data from application to database properly documented? Does everybody understand it?

- Hardware demands vs specifications: We've had several vendors insist that the software they wrote and the DB have specific hardware/RAID requirements, but under real testing those needs are un-warranted, or our hardware is more than capable of handling the configuration in a better way.

Just some of the things I can think of off the cuff.

Level 12


Just leaving this here for you all.

Level 7

How are you baselining current performance?  CPU utilization, memory utilization, disk iops et al.

What does this data really mean?  So often, different groups want to know this piece of information or that piece, but few ask for the whole picture.  So we set up a threshold on all databases or db servers, but if the data is silo'ed, a threshold passed on this server may be a sign of a bad thing, but on this one it is not, but without all of the tools or single pane of glass, one group knows the answers to these questions and another group knows the answers to those questions, but no one is sharing and both groups are running in circles for lack of a whole picture.

Level 12

Yes, that's one of the dimensions of using data - how does it relate to other data?  How doesn't it?  And who should see this data?

Level 10

Great post!  Excellent questions.

Level 10

Good read. This scales well past one It discipline (and well into real life).  It is our duty to question any and all status quo.

interroga omnia

Level 12

Thank you datachick

Level 11

Great questions.

Level 11

Thank you datachick

Level 15

Thanks for this posting.  I bookmarked it datachick to keep it as a reference item.

Level 15

Thanks for posting.

About the Author
Data Evangelist Sr. Project Manager and Architect at InfoAdvisors. I'm a consultant, frequent speaker, trainer, blogger. I love all things data. I'm an Microsoft MVP. I work with all kinds of databases in the relational and post-relational world. I'm a NASA 2016 Datanaut! I want you to love your data, too.