This is a question that I get asked all the time. It’s fair enough, really. The most common assumption for people outside the field seems to be that that if you work in IT, you probably fix computers. Maybe you write code as well, but you definitely know how to fix computers. It is similar to the way many people think that any doctor can fix a person. Some doctors are psychiatrists, sure. But a psychiatrist is still a doctor, right? He should know how to handle a kidney tumor!
My husband is also in IT. His responsibilities are widely diverse, ranging from desktop support to routing, project management, and local area networking, among other things. I can more or less follow him when he explains what he does in the course of his day, and he does his best to follow me when I talk about my own. But asking me to do his job would be like asking a lung doctor to do a kidney transplant.
It can be the same way even among DBAs. I work with a guy who has a deep understanding of hardware. Thank goodness, since it is hardly my first love. Mention reporting, business intelligence, or anything analytical to me and you have my undivided attention. He will likely break out the cross and garlic. I work on being fluent enough in hardware to maintain an intelligent conversation, and he does the same with reporting. Much like the medical field has pediatric oncologists who works with kids who have cancer, and pediatric neuro-oncologists who specialize in brain tumors, we as DBAs frequently specialize or even sub-specialize.
So it begs the question: What does a DBA do (beside “work with databases”)?
It’s a big question, with a number of possible answers. Many DBAs specialize in one thing or another. Some love performance tuning, while others excel at hardware or server migration. Still others gravitate to areas like high availability, development, or security. But at its simplest definition, whatever road your career takes you to, DBAs are the guardians and facilitators of the company’s data. In other words, at the very least, your job is to ensure that the right data gets to the right person, at the right time, and as quickly as possible.
This is no small responsibility! Think for a moment about what the company’s most valuable asset is. Its building? Its money? Its contacts? Nope. The company’s most valuable asset is its data. If the data is wrong or missing, watch how quickly those other things take wings and fly. Paul Randal of SQL Skills tells the story of the unfortunate bank who had a corrupted database (which had been further plagued with an inefficient backup/restore strategy). Miraculously, all the data was restored. The bad news is that the restore process ended up taking 3 days, during which time the bank lost the confidence of its customers. The bank wound up closing.
That story wasn’t told to scare you (although to be honest, it scares me every time I think about it). I told you the story because it underlies a crucial point. As a DBA, where the data is concerned, you are the line in the sand. What you do makes all the difference to the company you work for. You are the protector of that data and you are the one who ensures that it is ready for whoever should have it. I can think of nothing more interesting or exciting than that to do with my workday.
My husband would probably say that designing the architecture for server redundancy or load balancing servers is much more fun than designing indexes. He’s wrong, of course. 😉 But I forgive him. There is room enough (and need enough) for it all.