Russ Thomas – SQL Judo

The Art of SQL Server Database Administration, Development, and Career Skills for the Technically Minded

T-Sql Tue #56: Aint Nutin’ My Problem

T-SQL Tuesday

You know what happens when you assume right?  Of course you do.  That little play on words is pretty well played out.  In fact, if at least one other blog in this months tsql2sday party doesn’t spell out that old saying, I’ll buy lunch for my team.

Most of us are constantly involved in jackassery of some kind whether of our own design or through the actions of others related to the big A. Assumptions.

Hosting TSql2sday this month is Dev Nambi who asks what assumptions do you find prevalent in your environment that people may be unwilling to address. This is iteration #56 of Adam Machanics #tsql2sday baby btw.

The assumption I regularly find – one that people really don’t like pointed out to them – is really pretty common.  The assumption that it’s not your problem.

End User:  This database server seems really slow.
DBA:  That is a hosted box the business set up without us – can’t help you.
(can’t or won’t because you’re still ticked about a 2 year old turf war)

End User: I can’t connect to the database.
DBA:  Other people are connecting fine; it’s not a database problem.
(congratulations you just blew off the new hire that’ll take over your division in a few weeks)

Developer: Query has run fine for months; this morning it started getting an error.
DBA:  Well, nothing changed – so it’s not a database problem.
(what prod system on the planet doesn’t change from one moment to the next?)

The truth is that in many cases the above reactions might be accurate.  But what about that one time the query error was related to a stored proc using the temp db which was low on space and later that day brought the server down while you were at lunch?  How about the fact that the user who can’t connect was a new hire who was simply added to the wrong security group and lost a day of running around trying to find someone willing to help him?  Do you care that your professional reputation took a hit because of your unwillingness to get involved with a hosted database?  Don’t get me wrong.  This post isn’t about being a kiss-ass – it’s about being worth your paycheck.


assumeI have a little challenge for you.  When a problem comes across your desk – just for a moment – entertain the notion that it might actually be your problem.  In many cases you will likely find that it doesn’t take any more time than trying to shoo people away from your desk only to deal with the issue again when it gets escalated up the chain and finds it’s way back to you.  Even if you just point them in the right direction your hero points will go up a notch or two.


A week or so ago we had a major issue affect one of our production boxes.  Deep in my gut I knew it was related to a code release.  Their was a vocal contingent that was adamant that it was a database problem.  The problem was bad enough that the CIO got involved.  He called me into his office – Russ, what the heck is going on out there?

Put yourself in the shoes of the CIO – which answer do you like better?

Frickin’ developers did a major release last week – I doubt they tested their code very well.  They obviously broke something.


As soon as I found out about the data loss I played out every scenario in which this could be DB related.  I looked into data corruption. I verified integrity constraints were in place.  I scanned the audit logs for any un-authorized access.  I looked through our maintenance logs going back three weeks.  We haven’t pushed any maintenance, changed any processes, no corruption exists, indexes are good, data constraints are in place.  I’m trying to think of anything else other than buggy code related to the release and not coming up with anything.

In this case, it really wasn’t my problem.  Taking a few moments to proactively make sure it wasn’t however still paid dividends in the end.  With a production box down I wasn’t going to get left alone either way.  Plus my efforts motivated others to look deeper into their own areas.

I’ve been around the block a couple times.  You come back to the mustaches with answers like number 2 on a regular basis and you’ll soon gain plenty of trust and street cred for those moments when you really are pressed for time and short on patience and need to play the “not my problem” card.

The best dividend from this type of attitude however?  Once you’ve developed that type of cred, others are much less likely to play that card on you.  Yes, I’m talking to you SAN administrators and VM gals.  I’m looking right at you folks.  I know dang well that you set up that tiered SSD tray wrong.  I can’t prove it yet, but I know.

< disclaimer: I’m only kidding about the SAN / VM admin – you wish you had ours >

3 comments on “T-Sql Tue #56: Aint Nutin’ My Problem

  1. Kenneth Fisher
    July 8, 2014

    The best companies I’ve worked for had the opposite culture. Every problem was everyone’s to deal with. App is slow? Developers are tearing part their code, DBAs are frantically checking the SQL Servers & database performance statistics, server guys frantically checking each of the affected servers, network guys the network etc. We might have a minor performance problem caused by a blip in the network and get back a dozen ideas on performance gains across every department. It’s amazing what having the attitude “It’s my company so it’s my problem” can do for you.

    Great post!

    • Nice, thanks for the feedback. I probably should clarify in this post that most people at my company are pretty good to work with too. I sometimes group life experience into a post that makes it seem like it all happened within the past few days.

      • Kenneth Fisher
        July 8, 2014

        Absolutely. I think most people are pretty good at this. That particular company had one of the most amazing cultures I’ve ever seen though. We built emergency room software and any problem, no matter how small was jumped on immediately. Instead of a “Not my fault” culture it was a “My fault here’s what I can do to fix it” culture. We even took a half a week out every few months and everyone in the company (CEO down) would spend time doing coordinated testing. Was truly impressive.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


This entry was posted on July 8, 2014 by in Career Skills.
%d bloggers like this: