Opening the door doesn’t mean giving away the keys

There's a difference between letting users know what's happening in the database, and letting them get in and look for themselves.

This is one of those topics that everyone has an opinion about.  To state the thesis directly, everyone wants DBAs to have an open-door policy when it comes to their processes.  Of course to them, having an open-door means giving them the keys so they can look around for themselves.  And I understand their need to know what's going on with their app.

The problem as I see it is that Microsoft has made it too easy for people to get in and look around.  That's the problem with having a relatively rich GUI.  It solves the problem of administration so that people with very little training can get in and do work.  But it also causes the problem that people with very little training can get in and do work.  As DBAs, we need to control the flow of information coming from the DB to our business units.  So letting them in to see the inner workings of processes is a mistake.

And it's not that we're afraid someone will see something's wrong with the DB.  We're not afraid of showing people there are blocks or even deadlocks going on.  And we're not afraid to answer questions about WaitTypes or other goings on inside the engine.  Nothing could be further from the truth.  What we don't need though is amateurs coming in and being able to see anything they want and going off on tangents about what a problem may or may not be.  That's the hardest thing to deal with on a day to day basis and it's even worse in a crisis.  In every day practice it diverts the DBAs from their jobs to answer needless questions about normal occurrences in the DB.  Somebody gets on and sees blocking coming and going and next thing you know he start firing off emails to the business unit telling them there's a DB problem.  So now the DBA has to take time out of his day to stop and explain why the blocking isn't abnormal.  The problem is that not only is it a different guy poking around every time, but even the same guys never seem to learn.  So the DBA is constantly having to fight that battle. 

Having these people in the DB during a crisis is even worse though.  These guys don't have the experience it takes to know what to look for really, so they tend to take the first thing they see and announce to everyone on a conference bridge or in email that they've found the problem.  Then everyone starts down that path and no matter what the DBA says, they insist that he deal with this one thing before moving on.  I've lived this so many times it's not even funny.  And no matter what I say to the end users, they always believe what they heard first.  So the biggest part of my job often tends to be teaching users 2 things.  First, what to look for when certain conditions arise so they better know how to diagnose DB issue.  And second, to keep their mouths shut to the public so they don't derail the job the DBAs are trying to do.  I often end up making a deal with them.  I'll show them some things on how to diagnose SQL issues if you promise to only announce your findings to me.  It has mixed results but it's better than not having any at all.

And all this is because the tools are so easy to navigate and easy to get.  It makes end users think they're automatically entitled to have elevated permissions in the DB.  You don't see that with anything else.  You don't see end users insisting that they read a blog so they want admin rights to the firewall or the router do you?  Of course not.  And you don't see users insisting on being able to get in and have admin rights to Exchange, or to the SAN do you?  Of course not, that would be ridiculous and you'd never allow such a thing.  But DBAs have to put up with end users, devs, managers, PMs, and even vendors having admin rights on their servers because they took a T-SQL class or bought a book on report writing. 

So it's not that we're afraid to let people see what's going on, or that we're protecting our jobs by keeping the info a secret.  We just don't need the headache of having amateurs poking around and giving armchair DBA advice to business people who don't know any better.

Copyright © 2011 IDG Communications, Inc.

The 10 most powerful companies in enterprise networking 2022