DBAs are often the last to be involved in planning but the first to be called when things go wrong.
Name: Gary J. Rue
Job: Database administrator
Employer: Commonwealth of Kentucky
Years in IT: 32
Years in current specialty: 31
What is a database administrator?
Someone who maintains and supports the database engine. In database administration, there are the people on the design and architecting of the database — the logical side — and then there’s the physical component, where we take the logical and make it into the physical and administer the database after it’s up and running. The area that I manage is more on the production and physical side of database support.
What is the most important contribution you make, and how do you make it?
Our most important contribution is to keep the database running. It’s an on-call function; you never know what might happen. Half the branch was up all night last night restoring a database because of a failure. Data recovery is very important, and so is performance tuning and problem solving. In IT, you tend to start at the back end and work out to see where the problem lies, so generally, we’re one of the first areas that will be contacted when a problem occurs.
What is the most important IT skill or aptitude you need to do your job?
We need to understand how the database engine works. We need to understand the technical components of the application environment, the processes within the environment and the relationships of all the people surrounding the environment. There’s science, but there’s art as well.
What is the most important “soft” skill or personality characteristic you need to do your job?
We have to be good sounding boards. We have to help others identify and solve their own problems. They tell us what they think is wrong, but we have to get them to see outside of where they think the problem is, because if they really knew, they wouldn’t be talking to us in the first place. A good database administrator has to see the relationships among the technology pieces, the people, the systems. We have to see the bigger picture and relate it. Sometimes we have to take a very technical piece and translate it to people at all levels of technical knowledge. That’s hard to do.
What is the biggest misconception about what you do?
We’re a very tactical group — we have to be. But there’s a strategic part of what we do so we can apply the tactical parts appropriately. For example, a developer says, “Create these tables.” But for us to really do a good job, we need to know why. We need to know how and when those tables are going to be accessed. We need to understand the system so we can apply appropriate security. We also have to understand what type of data recovery scenarios we need to address, how and when to do the backups and where they will be stored. And we need to go through all types of scenarios to adequately recover that database.
What do you like best about your job?
The people we work with. The systems people, developers — they’re all problem solvers. They’re all smart, creative IT people. And being in support, a crisis is always just around the corner. I like the thrill of the crisis. I like being put on the spot to find a way to solve a problem.
What do you like least?
I don’t like to take care of problems that, if I’d gotten enough information upfront or the right information, we could have dealt with it then. I don’t like to put something in production and then have to fix it because future possibilities hadn’t been considered.
What should IT people know about your role?
Today’s developers have databases on their desktops, so they think they’re mini-DBAs. When we get involved, it’s always after the implementation. Lots of issues could have been addressed if we had been involved earlier in the development process. Also, we do have a recovery role, and we should be asked about the recovery possibilities when a database goes down. IT people sometimes think they know how to recover, so generally we get brought into it because they have recovered incorrectly.
What should business people know about your role?
Business people think IT can do anything, but they need to know that there is a cost associated, and sometimes the cost is too high to implement certain features. There are still priorities you have to set.
What would enable you to do your job better?
Having more database tools and early interaction during the development process.
If you were not a data architect, what would you be?
A detective. Trying to dig information out of people, the ability to look at disparate pieces of information and apply them appropriately to determine how an event happened — you have to be a little bit of a detective as a DBA.
How does the future look for your role?
I think of us as the hub. The business user, the developer, the operations person, the systems person — they all relate to the database in some way. Our job changes slightly with new technology, but I think a DBA will be a very, very important role for years to come. And besides, everybody needs someone to point the finger at.
Rue can be contacted at [email protected].
