One of my favourite things about the SQL community is the exquisite diversity of talent of it’s members. Today for the “What’s it Like To Be a DBA” post series, we’re privileged to have with us a gentleman that not only flexes his technical muscles regularly on his blog but who also encourages us to get the grey matter really working with his thought pieces and professional development posts. I really do enjoy this authors work, his content has a wonderful air of class, a distinguished style and I know many of you enjoy it too. 

Ladies and gentlemen, please welcome Mr Mike Fal (Blog|Twitter). 

True confessions: when I make small talk, I usually lead with “what do you do”. It’s a little lame, but something we all can answer. However, what’s usually a more interesting follow-up is “how did you end up doing that?” After all, whether we’re speech therapists, inside sales reps, garbage collectors, safety managers, etc….it’s usually an intriguing tale of how we got there.

What a long, strange trip it’s been

My tale is twisty enough. I went to college with a desire to be a classical bass trombonist. After 4 years of typical college hedonism at the University of Colorado in Boulder, I got my Bachelor of Music Performance (insert B.M. joke here) and ventured out into the “real world”. That’s when it got hard. I found myself working in a warehouse, trying to get to graduate school, and wondering if I had made the right choice for what I wanted to do with my life. Don’t get me wrong, I love music, but it’s a hard road without a lot of reward. Your love of the art form can be quickly burned and ground out of you.

Enter my first system administrator. I’ve always been a geek and had an interest in computers, how they worked. He noticed my interest as he fixed printers, replaced hard drives, and did the usual day to day crap. Through him, the company offered me a modest tech support job, which led to some basic work on our Access application (SQL 7 backend), which then lead to query writing and application design. Suddenly, this former musician was another I.T. geek, with an appetite to learn and a hankering to tinker with things.

What followed was the usual host of job changes, fire-hose drinking sessions, and late nights/long weeks. I toyed around with Oracle, .Net programming, Access (gah), Linux, NT Administration, and a host of other roles and responsibilities. SQL Server always was the glue holding my other work together, the path I managed to hold to throughout the changes. As the years passed, I kept on playing and experimenting. I think the biggest question I kept asking myself was “Is there a better way to do this?” Usually the answer was yes, every once in a while it was no. No matter the answer, I kept learning and building on the knowledge of all these experiences.

Better, Faster, Harder, Stronger

Now that I’ve been doing this for 10+ years, I can’t say I’ve seen a typical day. While my current job is your standard operations Database Administrator position, the actual work varies from day to day. Here’s the sort of stuff I find myself doing:

• Performance: If something is slow, it’s the database’s fault, right? I usually have to drill into the database stats and processes to see what is going on. If there’s a problem, I have to fix it. If there isn’t, I have to explain to others why the problem lies somewhere else. And I usually have to do this all RIGHT NOW. I’ve gotten used to getting pulled off task.
• Availability and Reliability: This is like being a car mechanic. I fix the broken cars and do tune ups on the ones that run. This includes making sure that we have backups done, that the database is secure, things of that nature. I think this is one of the cool parts, because it means that I’m the guardian of the company’s data, the last line of defense if something goes wrong. It’s a fairly heavy responsibility, but one I enjoy. (Also, it’s one of those things that when I get annoyed, I comfort myself by saying “I could bring the company to a grinding halt in 5 minutes”. Not that I would, but it is a bit of a power trip. )
• On-call: If you work in support, this is an aspect that you just come to accept as part of the life. You will get paged in the middle of the night, you will have to respond to alerts when everyone else is enjoying a good night’s sleep. I look at on-call as a challenge, however. What can I do to not get paged at 3 AM? Am I fixing problems that keep occurring? Am I fine tuning alerts so I don’t get false positives? This can be a rather long list, but I think the goal of every support DBA should be a regular sleep schedule.
• Technology planning: From purchasing new hardware to implementing new SQL technologies, I’m the company’s expert on where we go next with SQL Server. This means I spend time researching what’s on the horizon and identifying where in the company we can use it. It also means that when we’re planning new purchases for disk or servers, I need to have answers for what SQL Server will need.
• Documentation: Some folks hate this or don’t see it as very important. For me, this is as vital as any of my other job duties. If I don’t write down what I’ve done and how I’ve done it, this means I become the only person who can do a certain task. I hate single points of failure in my systems, so I don’t want to be one of them either. I make sure I’m spending at least part of my day putting things into writing.
• Database/Application development: So, this isn’t full on SCRUM/Agile development. What I build is utility stuff. Sometimes it’s a backup script. Other times it’s a set of scripts and tables to collect a server inventory. Maybe I’m writing stored procedures to manage my administrative tasks. Whatever the case, I have to design the database to hold my data, figure out how I’m going to get it in there, and make sure it doesn’t suck.

How much of this I do day to day varies. Sometimes I spend the whole day (and more) fighting fires. Some days are all about documentation and research. Overall, I’d say that roughly I spend 50% of my time on the maintenance aspects of my job, with the other 50% filled in with research, planning, and administration (meetings, paperwork, etc.). My week is roughly 40-45 hours, though I confess that I work on keeping it down to that level. You often hear of the horror stories of regular 60 hour work weeks. In being a DBA, I’ve learned the value of having a life outside of SQL Server and manage my time accordingly.

And I ask myself, how did I get here?

Often I’m asked, “How do you become a DBA?” As you can tell with my story, my path wasn’t well defined or particularly repeatable. I just found one day that I was doing it and liked it. Talking with others in the community (or reading about them, in the case of Mr. Swart’s excellent post), my situation is not unique. I think becoming a DBA is very much an evolution and a career that chooses you, not the other way around.

That being said, there are a few things I tell people who want the gig. The first is to make folks aware that there are actually several different flavors of DBA (I’ll avoid my rant of the broad-brush use of the term “DBA” for some other post on my own blog).

• Operations support (this is what I do), where you’re responsible for keeping systems up, running, and running well.
• Development, where you will build back ends for applications (sometimes combined with .Net programming).
• Business Intelligence, which has you think about data on a macro scale, how to aggregate data sets and help non-technical people make sense of their data.

No matter which path you want to take, some of the steps will be the same. For anyone who asks about being a DBA or wanting to learn more about SQL, I also recommend the following books:

• Database Design for Mere Mortals: All data professionals need to understand relational theory (which hasn’t changed all that much since E.F. Codd wrote it back in 1970). I always recommend this book as a first stop for people wanting to get into the database world.
• Database Survivor: Tom LaRock’s book was written as “the book I wish someone had given me on my first day as a DBA.” I’ve written a pretty extensive review of Tom’s book on my blog, so if you want the gory details, go there.

After this, get out in the blogosphere. The wonderful thing about the technical community now as opposed to when I got started is the amount of Internet resources available. The best place to start is Tom LaRock’s blogger rankings, where you’ll find an excellent listing of online bloggers focused on SQL server. From there, explore and build up your own list of blogs to follow. The clue is to satisfy your thirst for knowledge.

Also remember, not everything out there is right. Trust, yet verify.

Then, play and learn. Apply your study to gain practical experience. Unfortunately, there’s very few jobs advertised where you can go in cold and learn how to be a DBA. You will need to create your opportunities. Talk to your DBAs, see if they have anything you can help with. Look for a mentor within your own company who can guide you and give you tasks to work on. Track your accomplishments, either through a blog or some other journal. It’s these accomplishments that you can take with you wherever you go. Every interview I’ve been in, the team I’ve interviewed with has cared more about what I’ve done than the SQL trivia I can recite. Do and then show that you’ve done it.

One of my music instructors over the years (a tuba player, don’t hold it against him) said “Music is a means to an end. You never get to the end, but you gotta dig the means.” This is true of any calling, from artistry to hacking assembly code. If you love working with data, your own evolution as a data professional will grow within that. Your own path to being a DBA may not be the same as anyone else, but it will be no less worthwhile and fulfilling, so long as you dig the means.

Thanks out to John for letting me share my thoughts and experiences about being a DBA here. I look forward to other stories from the trenches, and I also want to see the common threads. The SQL Family is drawn together by our experiences and the desire to share them with each other, which is what makes our community so strong. If you liked this, consider putting your own thoughts to paper, sharing with the rest of us, enriching the SQL community.