Possibly random thoughts of a oddly organized dba with a very short attention span


What makes a good DBA?

This question is asked frequently on multiple lists and there are always a wide range of answers. I've been asked directly by individuals who would like to become DBA's and by managers who want to evaluate people for DBA potential. In some cases, there is just a sense that someone would be really good at the job, and sometimes, the opposite is true. In the past, it's been hard to specify exactly what I like to see in a candidate, but I think I can summarize it into three characteristics:

1. The ability to approach a problem systematically

2. A desire to understand the depth of an issue

3. An insatiable curiosity

Tanel Poder's blog posts and presentations, 'A Systematic Approach Will Do', describe the importance of item 1 perfectly. If a candidate has the ability to research and test methodically, they can troubleshoot any problem. They are also more likely to design and configure a system to be sustainable, preventing future problems. The answer to most problems a DBA will encounter have already been solved. If you can define the problem clearly, locating the solution quickly is easier. If you solve a problem methodically and document the process, you will have the information at hand next time the problem occurs. And if you're really good, you will find the fix that prevents the problem from reoccurring.

Many IT folks have knowledge that is 80 miles wide and a half an inch deep. We are expected to adapt quickly to new technologies and many of us are motivated to learn new things, so this shouldn't be surprising at this stage of the game. However, in order to be really good at something, you've got to have a desire to understand how it works and be willing to dig into the guts of a system, a process or a mound of data. A few years ago, a relatively new DBA came to me and said he wanted to move into management because after 3 years, DBA work was really 'boring'. My jaw literally dropped - I was stunned. This guy was reasonably bright and had been the team member mostly likely to implement the newer technologies. He'd been a developer for a few years before earning his OCP, but all I could think was 'You have no idea what you don't know yet.' He'd only learned the high level stuff and worked almost exclusively from the OEM gui. He didn't know about running a 10046 trace, much less using the results, and had never fixed a performance problem that went beyond adding an index. When certain types of problems came up, he was likely to hand them off to me because I could 'do it faster', but never showed any desire to figure out how I did it faster. There are many DBA tasks that can become repetitive and 'boring' - that what automation is all about. But if you don't have the desire to understand and leverage the full range of the database - both the data and the software - you'll never get the opportunity to solve the really challenging, interesting problems.

Insatiable curiosity is sort of a subset of the 'desire to understand the guts' thing, with a bit of twist. The difference in the level of curiosity makes or breaks a good developer, the same is true for DBA's. I've worked with some who brought me problems and wanted me to figure out all the details for them. Others come for help but want to learn how the problem gets solved and they don't let go of the issue until they fully understand it. Once they have the knowledge, they take it and run, finding ways to apply it over and over again.

The first time I worked with Oracle, I was charged with implementing an off the shelf application. A short time into the implementation, it was clear that that the product was not going to meet our needs so I built something new that did. A few months later, management requested additional functionality; I found a way to meet the new requirements but under the covers, it was an awkward, ugly thing. Although the problem had been 'solved', I knew there had to be a more elegant approach and it nagged at the back of my mind. I had dreams about this problem, and when I finally figured out the solution, I was writing the code in the steam on my shower door. Obsessive, I know, but when you're truly curious, there will be times when a problem grabs you and won't let go. Maybe it's unfair measure, but I like to see a little obsessive curiosity in a DBA.

One way to evaluate these three traits is how a DBA handles a really tough problem on a critical system. How quickly to they open a service request? What do they do while their waiting for an answer? A DBA that opens a request for every problem and waits for Oracle to provide all the answers doesn't rate very highly on the systematic, dig deep, curiosity scale. I like to see someone try to research and resolve the problem on their own first. Open the case once your initial research indicates the problem warrants it and use what you've learned so far to provide documentation to the support analyst. Keep searching for the answers while you wait on the response from support. 9 times out of 10, you'll find the answer before they do and if not, you'll be prepared with better questions when they call back. Most important, you'll learn something from the process that will help you with the next issue.

Some people are born with these three traits while others develop them with practice, but when you talk to someone that has them, it shines through loud and clear. It's also difficult to fake this kind of desire for understanding and the ability to logically work through a process which is why it's the best litmus test for a good developer or DBA that I know.

1 comment:

Allen said...

Boy, you hit the nail on the head! I look at myself and this post would be how I would describe myself if I were so eloquent. I rarely submit a support request because I usually find the answer by googling on the internet or on Metalink. On the flip side, I work with a DBA who I would not consider to embody the three points you note. We had a problem recently (I'll post about it on my blog) where the server was rebooting without warning. I eventually figured the problem out by doing research for about an hour, starting with "Solaris Oracle RAC reboot". The DBA in question just threw up his hands and asked the Sys Admins to look into the issue. Argh! Guess that's why he is being moved off the project and I am staying.

The kicker is, I interviewed him and have been kicking myself for bringing him on board. I have mentioned since that I find it hard to interview DBA candidates and determine if they are a "good DBA" as you describe. Now, I have a little more guidance to help me the next time. Thanks!

- Allen

Search This Blog


My Blog List

disclaimer ...

The views expressed on this page are mine and do not reflect the opinions of my employer, former employers, other associates or the opinions I may hold 3 days from now.