10 Tips for the Minimalist DBA

Dec 3, 2013   //   by Karen Lopez   //   Blog, Data, Database, DLBlog, SQL Server  //  4 Comments

Title Slide Minimalist DBA

It seems that there’s so much to learn when you are first working as a production DBA.  What do you focus on first?  How should you prioritize your learning? What things should you automate and measure?  What skills are core to your job, no matter how long you’ve been a DBA.  These are the things that we think that all production DBAs need to know and continue to build upon.

In our DBA Fundamentals presentation on The Minimalist Guide to Database Administration, Thomas LaRock ( blog | @sqlrockstar )and I (@datachick)  discussed the core skills one should have when filling a DBA role. That presentation has been recorded (I will update here when it is posted).  I hope you were able to join us or will stop by and watch the recording.

10 Tips for the Minimalist DBA

  1. Protecting your data is your number one job.  I’m betting that no one else in the company has a to-do list to protect the company’s data.  Maybe someone at the strategic level, but not to actually ensure it’s available when it needs to be.  That means your first job is to ensure backups and recovery are working.  Test your backups, test your restores.  The first thing I do on new projects is to ask about the backup and recovery configurations.  I once found that the production system had not been backed up for more than five years, even though everyone else thought it was backed up daily.  Don’t just ask.  Go look.
  2. Don’t waste time alerting yourself of things that don’t require a reaction.  You may be tempted to set up alerts so that you get an email and a text message to notify you every time a backup successfully completes.  Or when your online monitor finds your database upright and smiling.  However, that soon leads to alert blindness.  You will miss the real alerts that you need to do something about.  Hard drive getting full? Response times approaching ice age times?  Those are things you’ll need to be ready to deal with.
  3. The best DBA is a lazy DBA.  Not a sleepy DBA, but a DBA that automates as much as you can. Think of this as a Driven, Lazy DBA (DLDBA). Do you have tasks that take 15 minutes to do, require no human decisions and that you have to do multiple times a week? Those are automation candidates.  Be lazy so that you can spend your already overscheduled time on tasks that need your awesome data professional skills.
  4. You can’t manage what you don’t measure.  If you don’t know it exists, or whether it is still up and running, you will be stuck in a perpetual firefighting mode.  Tom thinks that firefighters would make great DBAs, but that doesn’t mean that great DBAs are in 24/7 firefighting mode.  It’s also good to understand what’s the best way to measure these things. Almost all measurement consumes resources.  Do you understand what make sense for each case?
  5. You need to understand the basics of all kinds of things.  Always be learning and looking forward. Just because we picked a few things to focus on doesn’t mean you can ignore all the rest.  You need to build your basic literacy of things that aren’t your primary responsibility.  Storage basics, database design methods and practices, web services, development tools and methods…yes, there’s a lot.  Start with the things that are causing your databases the most pain and work out from there.  It’s sometimes a bit overwhelming when you attend a conference or pick up a book and realize how much you just don’t know enough about.  In fact, there’s a name for this: the Dunning-Kruger effect.  The more you know, the more realize how much you don’t know.  The only way to deal with this is to always be learning and looking forward.  Sure, there are some people making RAID-loads of money supporting COBOL and IMS systems, but overall staying afraid of new technologies like cloud, NoSQL, BI, and big data is going to keep you blissfully ignorant.
  6. You must practice everything while your database isn’t burning. It’s not enough to watch a one hour presentation on how backups and restores work.  It’s not enough to download a script.  You need to get in-depth, hands-on experience doing these things. Not just a one time in a class thing, but practice with real world situations and data.  You need to schedule that time to do this. And your boss needs to support this.  Then you need to practice with intentional errors.  What happens when the time on the server is messed up?  What happens when you don’t have the right log files?  What do you do if the SAN is down?  Where are your restore procedures and checklists documented?  You don’t want to be “learning on the job” when your PHB boss is standing beside you and there’s smoke coming out of the server.
  7. Writing stuff down is good. It’s Agile even. The Agile software method calls for the right amount of documentation.  Many read this as “no documentation”, but they are wrong. Yes, sometimes to you can just walk over and ask the person who set up the job why they did something, but on my projects that person has moved on to 6 more teams since I last saw him.  I recommend using wikis or SharePoint collaboration areas for these things, so that they are all in the same place and can be accessed with any device.  By the way, do you know if your documentation is backed up? Redundantly available?  Restores aren’t just for databases.
  8. The more you install, the more you have to manage and troubleshoot. Install only what you need.  Of course, that may mean looking a bit forward for planned uses, but there’s no need to install everything “just in case”. You might even want to look at Server Core as an option, since it has a tiny footprint, requires less management and you can still use your remote GUI tools to manage it.
  9. Don’t be the one that panics. Practice and documentation mitigate stress and panic.  This is where all your laziness, planning, testing and learning pay off.  You’ve seen the guy that sits in front of a server, rapidly pulling cables, pushing buttons, running scripts and wizards and has no idea that he’s making things worse.  Don’t be that guy.  The more calm you are, the better job you’ll do.  And the more calm everyone else will be.
  10. Empathy is a highly-valued trait. For users, for other data professionals, for everyone. Empathy isn’t sympathy or feeling bad for others.  It’s about understanding what their pain points are and why they feel the way they do.  If you can reflect that empathy, work will be easier and progress towards a common goal can be made.  If you come at all issues with a zero-sum game approach, you’re going to have issues getting in the way of doing your job.

We also listed these links as great places to find more information about these skills or to practice them:

What advice did you wish you’d had years ago?   What else should a minimalist DBA know about?


Leave a comment

Subscribe via E-mail

Use the link below to receive posts via e-mail. Unsubscribe at any time. Subscribe to www.datamodel.com by Email



UA-52726617-1 Secured By miniOrange