The Art of SQL Server Database Administration, Development, and Career Skills for the Technically Minded
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.
I 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 >