The DBA Ethos

I am a DBA. No matter what title my company gives me, my primary job is designing, engineering, and supporting DB2 databases. DBAs sometimes have a bad reputation. I was a bit surprised the first time my engineering colleagues told me how lucky we were to have such great involved DBAs. Don’t get me wrong – I know I am good at my job, but the part that surprises me is the general negative reputation that DBAs sometimes have.

There seem to be two major DBA stereotypes:

The all-knowing uncaring consultant

This DBA knows his database stuff, and won’t compromise on a best practice for anything. He’s so busy that his time is precious, and he will only attend that part of a meeting that directly requires his involvement. When he solves a problem, you get a 10-second version of what he did and why it was really the application’s or the System Administrator’s or the SAN’s or the Network’s fault. Off-shift you can get ahold of him after going through a junior dba. But when you do get ahold of him the problem is identified or solved quickly.

The half-absent obstructing idiot

This guy thinks he’s the other guy. So he says “No”, a lot. But he doesn’t actually understand the problem or why he’s saying it. He misses meetings that he really should have been at. He answers his phone only when he feels like it. He doesn’t communicate very clearly, so doesn’t always do what you asked him to, and isn’t capable of giving you the explanations for things. He sometimes has an in or a family relationship with an executive. Some of the problems he solves are the ones he creates himself.

Challenges that lead to these stereotypes

Where I work, a developer is on one or two clients at a time. An engineer is on two or three clients at a time. A DBA is a specialized member of the engineering team, and most of the time is on six clients at a time. If I was on every technical meeting for every client, I’d get nothing done. But I’m the kind of DBA that would rather sit in a meeting I don’t need to be in than miss that important 5 minutes where I could have stepped in and made a difference.

DBAs can be a fairly highly paid specialty. This means that management wants them to spend less time on projects.

Not everyone understands what we do. Many technologists think of databases as just another piece of software that requires no special expertise. Most of the time the directives for DBAs are something like “keep databases available and recoverable”. Details of how that is accomplished most people don’t care about.

Databases get a lot of blame. They tend to be more of a single point of failure than some other components. A logical failure within a database cannot be gotten around by a failover. If the SAN or the network is down or slow, often the application gets database errors. If the application vendor is not very database-aware, there are a lot of ways that the application can do something wrong and get database errors.

How to Avoid the Stereotypes

Deeply care about your databases. Personally, I think of my databases as an extension of me. Believe me, it HURTS when I do something to cause them to go down. It hurts when something else takes them down. I mean almost literally, physically. A database of mine was unavailable for an hour last week due to a mistake I made. It didn’t hurt because I was worried about getting fired or worried about getting yelled at or worried about my reputation. It hurt because I messed up, and I shouldn’t have. Everyone gets an ego-check every now and then and even the best dbas can use their mistakes to be better.

Leave the blame behind. It doesn’t really matter if an error is really a database error or if it’s just a network or SAN or application error manifesting in the database. A DBA’s help is required in any case. I try to first MAKE any problem a database problem. How could the database be causing this issue? Approaching it that way avoids the knee-jerk “this isn’t a database error” that pisses off other technologists. Then if it isn’t in the database, you can help the appropriate team identify what query or what LUN or whatever is the problem. At the same time, don’t be afraid to identify the problem when it really is the database’s fault and there was something you could have done to prevent it. There is no surer way to get a bad reputation or to get fired than trying to cover up mistakes.

Constantly learn. Learn from mistakes, for sure. Read blogs, read articles, read books, get certified, crave knowledge not just in your specialty areas, but learn from your System Administrators, SAN Administrators, anyone around you. There is no one out there who knows everything about DB2. Research most answers you give to verify their truth and to learn a little bit more. Turn around and share that knowledge. Do “lunch and learn” presentations at work for people who are or are not DBAs. Write articles, blogs, present and speak in podcasts, webcasts, users’ groups, conferences.

Communicate. Every client I work with requires a different level of communication. Figure out who you should be communicating with and do it. Train others on what you know. Describe a problem in as much detail as you can make your audience understand, sometimes more. Be on those meetings, even if you’re joining remotely and working on other stuff – you might hear something sooner that you can correct or assist with. Make sure your availability is clear, and your estimates of completion are accurate or a bit pessimistic. Under-promise and over-deliver.

Say both ‘yes’ and ‘no’ as appropriate. Anyone who says yes all the time or no all the time will not be the ideal DBA. Either one gets you in trouble. There are some principles that should never be compromised and sometimes the client really is right, but most things fall into judgement calls. You have to be flexible to meet your clients needs, but also make sure that what they’re asking for is really what they need.

Do what you love and love what you do. A lot of technologists give being a DBA a try and it’s just not for them. There is a lot to know and it is a very detail oriented job. If it’s not for you, go find something that is. Life is too short to be doing something you hate. For me, I have to love my job – it is not worth the time away from my kids if I don’t. If I didn’t love what I do, I would find something else. That doesn’t mean I love every aspect and every second, but it does mean that I take joy in most of what I do. I’m not saying I wouldn’t rather be on a beach in Hawaii, either, but we all have to work or contribute in some way, and this is my way.

Be available. Off-shift, answer your phone. If you know you won’t be able to, set expectations properly. Be available in the office for discussions, or on IM or via email. Respond to everything, even if it’s with “Busy until 2pm, can we talk then?”

If you are a DBA looking to take your career to the next level, it is these things that will get you there. If you just sit in front of your computer doing the basics, you’re not going to advance your career or enjoy it. Help me raise the reputation of DBAs everywhere.