Blocking cause SQL Server down. Help!

Question

Blocking cause SQL Server down. Help!

Blue Mancunian

SSC Eights!

Points: 809
More actions
November 5, 2009 at 3:42 pm

#213427

Our SQL server recently suffered a problem which cause the whole
database is not accessible. After checking SQL Server log, I found
2009-11-05 00:29:35.27 spid4 Process ID 60:289 owns resources
that are blocking processes on Scheduler 0.
I have run a Profiler trace on the database and caught the process
appears in the error message. The process is a select query which is
specified in a read uncommited transaction. So I assume there is no
lock to the database when running the query. When the error happens,
the whole sql server is not accessible and no activities running at
all according to profiler trace.
I have checked MS knowledge base. there is article about this error.
But it says there are many causes to the problem, which is not really
that helpful 🙁
Is the process id sepcified the in the error message is the process
causing the problem? Can someone point out any other possible causes and
solutions? We are running SQL Server 2000 sp4, standard edition.
Many thanks!
Frank

Viewing 3 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic. Login to reply

Jeff Moden SSC Guru Points: 1004406 More actions · Answer 1

Chances are... it's not the SELECT that's causing the problem. It's some user or developer that began an explicit transaction, did a SELECT (which explains the read uncommited thing) to make sure that what (s)he wanted to happen did actually happen, and then forgot to commit the transaction. Find that user and, as part of their database awareness training, feed him/her some pork chops... with a slingshot at point blank range. 😉

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Blue Mancunian SSC Eights! Points: 809 More actions · Answer 2

Hi Jeff,

Thank you for your reply. our application terminates any queries running over 15 minutes. I assume once the query is cancelled, doesn't matter if the transaction is committed or uncommitted. It will all be rolled back. Plus this is read uncommitted transaction, so it shouldn't cause any blocking.

Am I correct?

Frank