Seven Tips For Solving the Accidental DBA Problem

No one sets out to become a DBA. Nobody.

Well, there was that one kid who wanted to be our summer intern, but I’m fairly certain he was just saying that to get a job at the time.

Truth be told, I did want to be a DBA. But that was only after having been a developer for a few years. I wanted to become a DBA for two reasons. First, I knew that Oracle DBAs made money. Lots of money. Like “make-it-rain” money. Second, I wanted to become a DBA because, as a developer, I found myself being forced to adapt and keep up with changing languages and architectures. DBAs never have to learn new things, right?

Um, no, not exactly.

So I wanted to become a DBA but I found my opportunities limited because I didn’t have DBA experience. I got my chance because the two DBAs at our company quit (RED FLAG!) and since I had previously done backups, restores, and reset passwords my company decided that I was the new DBA.

And that describes how a lot of people get their start as a DBA, too. Something external happens, like someone resigning, or a disaster happens, or the auditors show up one day (which also sounds like a disaster), or you were “volunteered”. Suddenly you find yourself with a new opportunity.

What do you do now?

This is the part that many new DBAs struggle with. Because they got their jobs by accident they have no idea where to start. What do you do first? Most people (AKA “managers”) have no idea what DBAs do for a job anyway, so you are left with little to no guidance on how you should structure your day. I’ve written before about this, trying to give new DBAs an idea on where they should focus their efforts daily.

Earlier this  month I did webinar with Karen López (blog | @datachick) titled “Solving the Accidental DBA problem“. In the webinar we talk about what to do if you find yourself as an accidental DBA. We discuss the following tips and tricks to help provide you the structure that is often lacking.

1. Admit you have a problem

Always the first step in any process. You simply must admit to yourself, and others, that you have no idea what you are doing. If you don’t like how that may sound then try admitting you don’t know everything. Trust me, it will be OK to admit that you know your limitations. identify whatever gaps you have and then offer a solution to help fix those gaps. Perhaps the solution is something as simple as attending training classes, or setting aside 10 hours a week dedicated to online learning.

2. Spend time in discovery

Start making a list of everything you are responsible for. Server names are the obvious items to list, but you will want to go one step further. List out names of applications. List out names of databases. List out names of business units and end users. List out names of managers. Get out of your cube and talk to people. Ask them “what’s the most important system” and take notes, Then, cross reference that feedback to understand which systems are, indeed, the most vital for your shop. If you are looking for a decent tool to use for gathering the inventory of your database servers check out SQL Power Doc over on Codeplex.

3. Test your ability to recover

This is the number one task a DBA must be able to do for their business. If you cannot recover data, then you cannot keep your job. It’s that simple. So after you have figured out which systems are most important you had better start examining the recovery plan for those systems. Check to make sure the databases are being backed up. Check to make sure the backups are being backed up, too. Test some restores. Verify that the recovery plan is working as expected. Practice, practice, practice restoring data, so that when the time comes you will be prepared. The last thing you want is to be seen as “forgetting to fly the plane“, so to speak.

4. Check your security

Now start reviewing the security of your database servers. Review how users are accessing data (windows authentication versus SQL logins), check to see what logins have administrative access to your servers and your database instances. Start learning about security options such as encryption and masking production data that is restored to test environments. Talk with your manager about the concept of “least privilege“. If you believe action steps are necessary to fix any security issues, come up with an outline of a plan and review it with your manager. Trust me, this is better than waiting for an auditor to come up with a plan for you to deploy instead. You can also purchase a copy of “Securing SQL Server” by Denny Cherry and read up on some security best practices.

5. Improve your performance tuning skills

Once you have your recovery plans in place, as well as an understanding of the security methods currently deployed, you should start thinking about performance and query tuning. That’s right…performance tuning comes AFTER you get your house in order. Learn about waits and queues. Check to see if you have any maintenance jobs in place to handle index fragmentation or updating of statistics. Find out how you are currently monitoring for low disk space. This part of a DBA role is the most outward facing, and likely how you will be judged by others. Make no mistake though, the preceding steps are vital. Don’t start out your career as a DBA focusing only on tuning queries. There is much more to the role than this.

6. Manage expectations

As a DBA you are going to find that everyone will want you to complete tasks quickly, no matter how big or small. For small shops you may find that you have no issue handling the workloads. For larger shops you are going to want to talk with managers about some service level agreements (SLAs). Without SLAs you will find your end users annoyed if any task takes longer than a few minutes. Two of the most important SLAs are recovery point objective (RPO) and recovery time objective (RTO). The RPO is the point in time for which you are able to recover data (for example, restoring to a point that is no more than 15 minutes ago).The RTO is how long it will take you to achieve that restore (for example, you can have the restore done within the next 10 minutes).

7. Develop a communication plan

I’ve often heard the phrase “the best DBA is one you never have to see”. I’d like to think that was a compliment, meaning that the only time you need to speak to a DBA is when something has gone wrong. But having met many DBAs I also recognize that we are a bit of a grumpy bunch (to say the least) so there could be other reasons for not wanting us around. The problem with not having us around is that no one knows what we are working on. That’s why it is important you develop some type of communication plan that allows for everyone to see what it is you and your team are doing, even if they don’t understand the specific tasks. Open up the lines of communication as much as possible and you are likely to find yourself invited to the right meetings.

You can watch the webinar here, and download a PDF of the slides here.

And if you take nothing else away from this post and webinar then take this message: DON’T PANIC! If you follow these seven tips you will be on the path to a successful career as a DBA.