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.

[sql]

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. [/sql]

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.