SQL Dumbass

Fighting dumbasses, one query at a time…

Shrinkage

So there I am, trying to get back in the flow of things during a short work week, when I get an email that brings a smile to my face. It would seem that a certain developer with many, many initials after their name (MCSD for example) needed some help. Apparently there was an issue with the server preventing them from running a query. The email read:


Please truncate the log file for tempdb on (server).  We’re getting an error message:


The log file for database ‘tempdb’ is full. Back up the transaction log for the database to free up some log space.


Now, my first thought is that perhaps, just perhaps, there is a chance that my query is causing this issue. But this rocket scientist has already decided that there is no way his query is the culprit, and in fact it is a problem with tempdb. Here’s an idea…why not tell us what you were doing when you got this message? Perhaps we could help you find out where the problem is? No? Okay then.

So, we respond back, tell them that tempdb is fine, there is lots of free space (naturally, since his trx was rolled back), and to try it again. It fails. Think he would make the connection yet? Unfortunately, no. So we go back and forth.

Them – “Please truncate again.”

Us – “Sure, done.” (It’s easy to get this done quickly since his trx keeps rolling back!)

Them – “Please truncate again.”

Us – “All set.”

Them – “Please try it again, the truncate does not seem to be working.”

Me – Oh, the truncate is not working? Let me get right on that for you.

Us – “Can you tell us what you are trying to run, perhaps we can figure out what it is you are doing that is filling up the log”.

Them – “My code has not changed, it must be something else. Are you certain the log is being truncated?”

Dumbass. Let’s see…your code has not changed…but you keep filling up the tempdb log file…could it be…the data has changed? Anything? Nothing? After a few more exchanges we get:

Them – “Well, we did migrate this code from a different server, so I guess you could say that something has changed.”

Brilliant. I can see how you earned all those letters after your name. Too bad none of them contain “DBA”.

Okay, so now we know that something has changed. Oh, and as it turns out, they may or may not be using the right version of the migrated code. And certainly the data is different, but why should that matter, right?

Thankfully I have no shortage of incidents like this one to keep me amused. It must be one of the reasons I come to work every day, the entertainment value here has got to be as good as anywhere else.



Turbo Button

This is an old story and one I could have repeated many times over the years.

There was an application developer who was testing one of his queries (amazing) and while he was waiting, asked if there was anything I can do to help the query run faster that he was running.  So instead of giving the usual answer of looking at the execution plan and optimizing it, I told him he should hit the turbo button.  This would help speed up his query on the server by 50%.  After a brief 30 seconds of trying to show him the fake key strokes, I said, ‘There is no turbo button smart developer (different words were used), try performance tuning your query.

It is amazing that a developer would think he could hit a button to increase the speed of their code.  It makes you really think about what they view as reality when it comes to optimizing the code.