October 21, 2007 at 11:29 am
On 9/26 and 10/20 one of our SQL Servers became unresponsive to the point where the server needed to be restarted. The server is running SQL 2000 EE - SP4 on Windows Server 2003 - SP2. At the point when SQL Server hangs, the server itself appears to be accessible at an OS level for up to a couple of hours.
I have a script which runs every 10 minutes logging any SQL Server activity. On both occasions the last thing it reports was the execution of some process that we know has performance issues. The problem is that since SQL Server does not respond to any new or existing connections I have no way of verifying if this process is the cause of the problem or simply the straw that broke the camels back.
The first link below sounds more like the problem we are facing, although it is not a 100% match. In either case I would like to know if anyone has any suggestions on how to troubleshoot a server that hangs without any apparent pattern.
http://support.microsoft.com/kb/931303
http://support.microsoft.com/kb/925419
Thanks, Dave
October 21, 2007 at 12:43 pm
Hi Dave,
Man, I feel for ya... been there my own self...
Just curious, though... even if the code were just "the straw that broke the camel's back", if it has known performance issues, why wouldn't folks fix it so that never happens with that chunk of code ever again? In every instance of a similar situation we've had at work, that was the only way to keep it from ever happening again. Takes some time, but it may allow the next performance problem to bubble to the top where it too can be fixed.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 22, 2007 at 6:50 am
As a DBA all I can do is make a recommendation to the development area that their code be fixed. I can even point them to the exact line(s) of code needing modification, but if they don't want to make it a priority there is nothing I can do to force the issue. This particular process is on their list, but since the application still functions it's not considered a high priority. Unfortunately sometimes it takes a large problem to occur that impacts $$$$ before someone takes the time to fix a known issue.
Dave
October 22, 2007 at 7:08 am
Heh, yep... I've been there as well... puts the DBA between a rock and a hard spot.
I guess all you can do is wait, then. When it gets bad enough, they'll finally take your recommendations...
I know you already know this, but I gotta say it... you should have a small database somewhere as a log where you document these kinds of problems and the proc or whatever name. Also document who you told about it and when. Two reasons for that... The obvious purpose is to protect yourself when they come to you and say you're not doing a good job... the not so obvious is so you can present a summary of problems in, say, a weekly report... send it to all the managers that own code and their bosses... makes people pay attention and things get done. As well you know, you have to be careful how you do that, too... some people have too much pride.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply