Editorials

Troubleshooting Tips with a Dose of Reality

Featured Article(s)
Useful undocumented SQL Server 2008 log shipping stored procedures
In this article, Alexander Chigrik looks at six undocumented SQL Server log shipping stored procedures that shipped with SQL Server 2008.

Learning SQL Server, SharePoint, Business Intelligence…
– Register: Spring 2010 SSWUG.ORG Virtual Conference – SQL Server, Business Intelligence, SharePoint – 75 sessions, 20 speakers…
– Register: DBA School – (60% sold-out already) 15 ppl max – Apr 19, 20, 21 – In-Person class that focuses on the things you really need to know – and shows/teaches how to apply it.

Troubleshooting Tips with a Dose of Reality
I really enjoy Buck Woody’s tips and tricks – he often writes about things that we’re running into with our servers or with other work we’re doing, and it seems like more often than not, it’s very timely.

His recent posting was about troubleshooting – you can read it here. It hit home with me because so many times we forget to stop and work slowly when things are acting up. It takes huge amounts of discipline to hold yourself to only changing *one* thing before testing and moving to another thing as you troubleshoot an issue. If you change more than one thing, you’ll not know what fixed the issue, you won’t have a sure look at the root cause and fix for whatever the trouble may be.

It’s a hard lesson, to be sure. I can’t tell you how many times where I’ve been in the heat of the fight with SQL Server and ended up changing something, tweaking something else, turning off a feature and then looking to see if "that" did the trick. While it may have corrected things, there’s no way of knowing which fixed the issue and which was simply a useless hail Mary. Your first lesson here is pretty clear, then, but the second lesson – not so clear.

Read over Buck’s posting. He makes an excellent point. You need to limit your work to singular items, yes. But if something does NOT work, you need to put it back the way it was before moving on. If you don’t, not only will you not know what you did to correct the issue, but you could actually significantly compound the issue. It’s a great point and something to think about the next time something comes up that you’re faced with troubleshooting.