T-SQL Tuesday: Why are DBA skills necessary? I pick the most important one...

T-SQL Tuesday Hosted by Paul Randal

What are DBA skills in the first place? There are so many skills which are generally useful in IT and particularly in the position that DBAs find themselves in.

I am not a DBA. I have done part of the DBA job before. I have been a developer and also an IT department director. I currently view myself as a systems architect - since I cover the gamut of knowledge necessary from infrastructure to building blocks to programming to database design to human factors and business (re-)engineering. Over the last 17 years, I have done a lot of OLTP database work and several years of OLAP work.

If you look at the ability to understand and organize complex systems, or the ability to understand a particular platform well, or to communicate well with business stakeholders, IT management and development staff there are a lot of skills which a good DBA is expected to have. I've decided to pick a single particular technical skill which I think it is very important for many people in IT to have, but extremely important for DBAs and network administration staff to have. It's needed in a situation where developers and business analysts will come for help, and a need which can never be outsourced or automated out of a job (don't we all look to put ourselves out of a job anyway?). When you're in the hot seat, that single skill is one that I think I value most in a DBA.

It's really a composite skill which combines a variety of traits and skills, but when I tell you the name, I'm sure you will all agree that it is a well-defined skill that you will recognize as such: troubleshooting.

When you are troubleshooting, you're in a particular mindset. Everything is up for debate. Is the hardware even working right? Is the network even connected? Is the cable bad? Did something change? It often starts as a controlled panic.

It takes a combination of knowing the platform itself thoroughly, and knowing not only how it should be behaving, and how it is actually behaving, and knowing how to find out how it is behaving. Being able to pull out network analysis, database and OS tools to monitor queries and the results. Being able to profile, being able to test ad hoc versions of queries and test data. Knowing the expected data profiles. Knowing what to throwaway completely to avoid wasting time and what to keep in the back of your mind as the next likely candidate to try. And never dismissing anything too soon, lest it come back - because the problem is always in the last place you look.

This all happens quickly in some environments. Even if time is not of the essence because the system is down, all the time used is some opportunity cost. There is nothing better as an IT director than knowing that you have a good troubleshooter working the problem, that he/she is going to come back to you with an answer (even if it's "I don't know yet, but we're going to find out"), that they are going to know the problem inside and out and own it and eventually come back with not only a solution, but with a plan to mitigate it in the near term and long term, perhaps including monitoring in some kind of proactive way.

It requires tenacity, a capacity for absorbing the system operations fully and synthesizing the interactions causing the problem. It generally requires experience and exposure in general systems work, as well as an understanding of the particular system being worked on. And in the end, it may require humility and forthrightness if you are troubleshooting your own work. Troubleshooting a developer's work lets the DBA know what's coming, lets them help to guide the developer away from dangerous areas and shows developers that DBAs can be a useful force, not just an impediment or obstacle. But no matter what, being good at troubleshooting is tremendously valuable.

Having good troubleshooters on your team is vital. It's a skill which is vital for DBAs to cultivate and improve and it's a reason you have DBAs in the first place, whether you call them that or not, the people with those DBA skills are necessary. That's why I want someone with DBA skills on the team and out of all those skills, the one I value most highly is troubleshooting.