THE SQL Server Blog Spot on the Web

Welcome to SQLblog.com - The SQL Server blog spot on the web Sign in | |
in Search

Andy Leonard

Andy Leonard is CSO of Linchpin People and SQLPeople, an SSIS Trainer, Consultant, and developer; a Business Intelligence Markup Language (Biml) developer; SQL Server database and data warehouse developer, community mentor, engineer, and farmer. He is a co-author of SQL Server 2012 Integration Services Design Patterns. His background includes web application architecture and development, VB, and ASP. Andy loves the SQL Server Community!
Note: Comments are moderated. Spam shall not pass! </GandalfVoice>

You Need a DBA

This post was inspired by a recent conversation with a DBA followed by reading The Curse of Relational Databases (especially the comments) posted at Grant Fritchey’s SQL Server Central blog.

I have two points to make:

  1. As of mid-2014 a physical person is required to properly administer a production relational database instance.
  2. The title of this post (and the second phrase of item 1) is a lie. You need two DBA’s (at least).

You need two DBA’s in case your first DBA becomes unavailable. Having a single DBA perform the work of two DBA’s is a good way to ensure your first DBA will become unavailable due to burnout.
People.
need.
breaks.
from.
work.

If your disaster recovery / business continuity plan doesn’t have a use case or scenario to cover the possibility inevitability that your DBA will be unavailable then you need to update your DR / BC plan.

For 75% of my career as a technology professional, I have seen advertisements that either state outright or allude to the belief of a software company’s marketing department that their relational database platform either reduces or eliminates the need for management by a qualified database professional. This is an inaccurate portrayal at this time.

An accurate portrayal is that automation and tools have increased the number of instances a DBA can manage if everything is running smoothly. The number of people required to manage a crisis is higher (which is another reason you need more than one DBA). The number of people required to manage a database is not zero. Will it ever? I think it will. At that time, I think we will need people to manage the automation that is managing the database. I could be wrong; it has happened before. For now, I am confident stating…

You need a DBA.

:{>

Published Tuesday, June 24, 2014 8:00 AM by andyleonard
Filed under: ,

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

Dave said:

Andy, I was one of the primary commenters on Grant's original article.  I think I didn't make my point clearly.  I absolutely agree with you that DBAs are needed.  In fact, you qualified it by saying "to properly administer a production relational database instance".  I would take out "relational".  I've worked on NoSQL solutions that were touted as not needing a DBA and I found that a DBA was even more of a requirement if you wanted DR and performance.  The DBA skill just becomes HIGHLY specialized with NoSQL.  

At the big companies where I consult (that should know better) there is a push to move relational out and NoSQL in.  When I ask why it is invariably, "we don't need DBAs then".  When I mention specific use cases where a DBA is still needed even for NoSQL then I hear (paraphrasing of course), "well, our relational guys hold us up too much by wanting every change to be reviewed in design sessions.  This means we can't put together a working POC of this new thing we are building without a DBA making us go back to the drawing board to get everything in proper 3NF.  Our NoSQL tool is schema-less so we can evolve our designs as the requirements evolve."  There you go.  Of course you know this is a lie.  There are plenty of NoSQL use cases where modifying a schema requires an entire export-and-reload.  

I don't believe any of the above comments about relational folks, but it appears to be the perception, at least sometimes.  If it wasn't, then why do NoSQL vendors state on the first few pages of their marketing tools that a)you don't need a DBA b)you don't need a rigid, structured schema?  They know how to press the right buttons with the business folks.  

I believe we, as relational practitioners, can change some of these perceptions while still maintaining our relational fidelity.  One way is by being less rigid about changing our schemas.  At some places it is common for a schema change to require 2 weeks to get approval because of those "nasty" DBAs and their process.  And the perception is this adds no business value (not my belief, but a repeated perception).  Using tooling, like Grant mentioned, we could get those changes turned around in a day or two.  

Anyway, I agree with you that DBAs are needed and important.  But sometimes the perception is that (development) DBAs get in the way.  I hope I'm wrong and the places where I consult that are pushing to move to NoSQL are the edge cases.  I hope the perceptions that I hear about regarding relational folks (not just DBAs) is wrong.  

June 24, 2014 8:56 AM
 

Robert said:

Hi,

I agree in full, but your final statement is contradictable. You say "You need a DBA", that is singular it should have been "You need at least TWO DBAs"

June 26, 2014 10:07 AM
 

Scott said:

There is a saying about the importance of having a back-up in case one fails:

two = one, and one = none

This applies in so many ways.  It could mean having an extra key to your house or car.  How about having a second somke detector somewhere in your house?  It also applies to DBAs.

July 2, 2014 2:45 PM

Leave a Comment

(required) 
(required) 
Submit

This Blog

Syndication

My Company


Other Blog

Check out my personal blog...
http://andyleonard.me

Contact Me

Twitter: @AndyLeonard
Email: andy.leonard@gmail.com

Powered by Community Server (Commercial Edition), by Telligent Systems
  Privacy Statement