Congratulations! You are our new DBA!
Bad news: You are our new DBA!
I'm betting you got here by being really great at what you do in another part of IT. Likely you are a fantastic developer. Or data modeler. Or sysadmin. Or networking guy (okay, maybe not likely you are one of those…but that's another post). Maybe you knew a bit about databases having worked with data in them, or you knew a bit because you had to install and deploy DBMSs. Then the regular DBA left. Or he is overwhelmed with exploding databases and needs help. Or got sent to prison (true story for one of my accidental DBA roles). I like to say that the previous DBA "won the lottery" because that's more positive than LEFT THIS WONDERFUL JOB BEHIND FOR A LIFE OF CRIME. Right?
I love writing about this topic because it's a role I have to play from time to time, too. I know about designing databases, can I help with installing, managing, and supporting them? Yes. For a while.
Anyway, now you have a lot of more responsibility than just writing queries or installing Oracle a hundred times a week. So what sorts of things must a new accidental DBA know is important to being a great data professional? Most people want to get right in to finally performance tuning all those slow databases, right? Well, that's not what you should focus on first.
The Minimalist DBA
- Inventory: Know what you are supposed to be managing. Often when I step in the fill this role, I have to support more servers and instances that anyone realized were being used. I need to know what's out there to understand what I'm going to get a 3 AM call for. And I want to know that before that 3 AM call.
- Recovery: Know where the backups are, how to get to them, and how to do test restores. You don't want that 3 AM call to result in you having to call others to find out where the backups are. Or to find out that that there are no backups, really. Or that they actually are backups of the same corrupt database you are trying to fix. Test that restore process. Script it. Test the script. Often. I'd likely find one backup and attempt to restore it on my first day of the job. I want to know about any issues with backups right away.
- Monitor and Baseline: You need to know BEFORE 3 AM that a database is having problem. In fact, you just don't want any 3 AM notifications. The way you do that is by ensuring you know not only what is happening right now, but also what was happening last week and last month. You'll want to know about performance trends, downtime, deadlocks, slow queries, etc. You'll want to set up the right types of alerts, too.
- Security: Everyone knows that ROI stands for return on investment. But it also stands for risk of incarceration. I bet you think your only job is to keep that database humming. Well, your other job is to keep your CIO out of jail. And the CEO. Your job is to love and protect the data. You'll want to check to see how sensitive data is encrypted, where the keys are managed and how other security features are managed. You'll want to check to see who and what has access to the data and how that access is implemented. While you are at it, check to see how the backups are secured. Then check to see if the databases in Development and Test environments are secured as well.
- Write stuff down: I know, I know. You're thinking "but that's not AGILE!" Actually, it is. That inventory you did is something you don't want to have to repeat. Knowing how to get to backups and how to restore them is not something you want to be tackling at 3 AM. Even if your shop is a "we just wing it" shop, having just the right amount of modeling and documentation is critical to responding to a crisis. We need the blueprints more than just to build something.
- Manage expectations: If you are new to being a DBA, you have plenty to learn, plenty of things to put in place, plenty of work to do. Be certain you have communicated what things need to be done to make sure that you are spending time on the things that make the most sense. You'll want everyone to love their data and not even have to worry that it won't be accessible or that it will be wrong.
These are the minimal things one needs to do right off the bat. In my next post, I'll be talking about how to prioritize these and other tasks. I'd love to hear about what other tasks you think should be the first things to tackle when one has to jump into a an accidental DBA role.