THE SQL Server Blog Spot on the Web

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

Andy Leonard

Andy Leonard is an author and engineer who enjoys building and automating data integration solutions. Andy is co-host of the Data Driven podcast. Andy is no longer updating this blog. His current blog is

The Perfect Trap

Warning: I am about to express an opinion.*

Introducing disruptive database technology is the perfect trap for database administrators.

<…freak out here…>

<… done? Good. Let’s continue…>

Way back in 2007 – when Adam first emailed me about writing at SQLBlog – I wrote a post that asked “Which ‘flavor’ DBA are you?” I had three flavors in mind:

  1. System, Operations, or Production support
  2. Application support
  3. Database developer

I think that list has grown since 2007 but I am not going to expand it here. I am going state, as I did at the top of this post, my opinion that System, Operations, or Production support DBAs are resistant to change. I believe with all my heart this is a good thing. In fact, when someone approaches me for help finding a good Production DBA, I tell them I am going to try to find someone who resists change with all their being. When I have had input on hiring Operations DBAs and been allowed to interview candidates, I have asked questions specifically designed to isolate whether this person even likes changes.

For me, this needs to be a personality trait in a front-line DBA. Why? I’m glad you asked.

How do things get messed up in a Production environment? It starts with a change. Every time. I’m not going to judge the change. I won’t say it was a bad change. Not me. I may say it wasn’t thoroughly tested, or that a good use case was left out when it was tested.

You test every change, don’t you? I mean… before deploying to Production and on a different server. Right? Or do you save time by not bothering to test all changes? You will get away with it… for a while. But when you get caught with your britches down – and it will happen – I want you to remember this blog post and hear Dr. Phil asking “How’s that working for you?” in your head (you are welcome).

Remember: All software is tested. Some, intentionally.

I Have Changed

I used to ding DBAs for being resistant to change. I didn’t like it. Especially when I was an application developer. In fact, before I got my first job as an application DBA I was asked if I could do the job of DBA. My response (and I wish I was making this up): “Sure. How hard can it be to tell developers ‘No.’”

I wasn’t a good DBA. Why? I like change. I embrace change. I seek change. Heck, I make changes! And that made me a lousy DBA. Good DBAs question every change. They understand their job is to serve and protect the data of the enterprise. They can’t do that and let every willy-nilly change someone wants to make get into Production. And the changes that do get deployed have to first do no harm, be absolutely necessary, and done in a manner that respects the balance that exists in the current system. In other words, changes not thoroughly and systematically tested do not belong in Production.

Sometimes that means telling the developer “No.”

The Trap Springs Eternal

So what happens when a disruptive technology shows up? I hear you thinking, “What is a disruptive technology, Andy?” Great question! SQL Server 7.0 was disruptive. It was so awesome companies didn’t need to hire a DBA (not really, but that came up…). SQL Server 7.0 did change things, though. SQL Server 2005 was disruptive. We had new tools and toys: SSMS, BIDS, and DMVs. Azure is disruptive – both Windows Azure and SQL Azure.

I believe SQL Server 2012 will be disruptive as well. Like SQL Server 2005, SQL Server 2012 comes with cool, new stuff. SSDT replaces BIDS, SSMS gets a facelift, the SSIS Catalog, Column-Store Indexes, Windowing functions. There’s a lot of Change in this new version. That should mean one thing to most DBAs: a lot of testing.


* I express opinions all the time.

Published Monday, March 5, 2012 8:00 AM by andyleonard

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



K. Brian Kelley said:

Welcome to the light, my friend. ;-)

March 5, 2012 1:31 PM

Mike Adkins said:

Working for a "little" company in Jacksonville where I ran into you the first time, I admit this post irked me a bit; but only because it's mostly true.  As a developer in an aggressive culture, I am constantly asked, hounded, beat with wet noodles, etc., as management constantly wants this-or-that change yesterday.  If I don't get it done right away I don't get a raise.  Meanwhile, I beg, plead, and bribe the DBAs to get something done, and I have to spend an hour in a meeting that they call where they explain why it can't or shouldn't be done.  And then the devs take the heat for not getting it done.  So I concur: "how hard can it be to tell developers 'No'?"

Pardon the rant.  I'm done...

March 6, 2012 2:02 PM

RichB said:


Would you be the one spending the rest of the night and the next day fixing up the database after some kneejerk developer implemented something a little... incomplete?

Would you be the one who had to tell the CEO that you've lost 12 hours of customer data because a change went through that effectively serialised all the connections into a single open transaction that someone then rolled back.

Oh, and no he can't have his database back because the rollback will take another 10 hours or so, resulting in at least 24 hours effective downtime for a sloppy piece of error handling on a slightly weak piece of database design that just had to be done in a hurry?

If so, go ahead.  Make the change.


March 7, 2012 6:32 AM

Leave a Comment


This Blog



My Latest Book:

Community Awards

Friend of Red Gate

Contact Me


Privacy Statement