Comments on: SQL SERVER – Quickest Way to Identify Blocking Query and Resolution – Dirty Solution

By: Appuraj

Appuraj — Mon, 22 Apr 2013 01:53:37 +0000

But deepkt if any job running for above spid56 then if u kill means
that job will fail and create problems..so before killing any process just look at what it is doing and decide which one to kill either 52 or 56..

thanks

By: Siva

Siva — Sat, 02 Feb 2013 09:41:03 +0000

Hi Pinal,
In our organization we are running an ERP Software. This software was developed using ASP.NET as Front End and SQL Server 2005 as Back end… When more number of users accessing at the same time means we are facing slowness in Execution… Some times SQL server gets Hang… What we have to do to overcome this problem… Pls do the needful

By: Gowtham

Gowtham — Thu, 04 Oct 2012 07:48:40 +0000

Please let me know the what are all the tables need to be checked during the long execution of SQL jobs

By: Gowtham

Gowtham — Thu, 04 Oct 2012 07:47:43 +0000

Hi Pinal,

Good Morning !!!

i am supporting SQL server 2005 .There are around 100 SQL jobs which used to be scheduled to run at its time on daily, weekly, weekday and Monthly basis.

But, i would like to bring to your notice that there are some SQL jobs which are taking more time to execute than expected.

we would like to fix this issue asap to ensure that all the SQL jobs will be running on its schedule timings without long execution.

By: Karthik Kulkarni

Karthik Kulkarni — Thu, 16 Aug 2012 06:25:53 +0000

Hi Pinal,

The above query for identifying blocking is working but this information is dynamic, but what if we are getting block somewhere around midnight and get a mail in the morning saying there was a blocking at midnight please check.
How can we record blocking history is my question.

Thanks
Karthik

By: Christos

Christos — Fri, 20 Jul 2012 07:31:48 +0000

Can you tell; us how to reproduce it and test it?

By: Rupesh Mishra

Rupesh Mishra — Mon, 25 Jun 2012 08:14:35 +0000

Try this…
sp_who2 active>>> will result with the spids, and other details and has a column showing the blocking process if any.
then use DBCC inputbuffer ()
if not a dml (to prevent data inconsistency, we should avoid killing a insert, update or delete), use kill
This will kill the blocking process and the resource/object will be realeased hence resolving the blocking

By: Nirmal

Nirmal — Fri, 11 May 2012 20:08:32 +0000

This is awesome! Thank you!

By: Jhobany Peña

Jhobany Peña — Mon, 09 Apr 2012 21:33:55 +0000

Wow…. thank’s!!!!

By: deepkt

deepkt — Mon, 26 Mar 2012 11:50:10 +0000

Hi,
I am using following method for finding the blocked processes.

SELECT spid FROM master..SYSPROCESSES WHERE blocked0
Let’s say 56 is the spid blocking

DBCC INPUTBUFFER(56) — Will give you the Event Info

KILL 56

By: Ram

Ram — Wed, 21 Mar 2012 09:51:34 +0000

This will gives us the full text (Eg,. For an SP it will show us the full code) is there any way to get the only statement causing blocking along with the SP name?…

By: Ashwin Menon

Ashwin Menon — Fri, 14 Oct 2011 12:02:19 +0000

Hi Pinal,

I was testing your query and found that it didnt give me the results that I was expecting.
To reproduce, I start a transaction and did an insert. Now in another query window i go and do a select on the same table.
Now if I run the query I am not able to see any results,
Due to the fact that in sys.dm_os_waiting_tasks we dont see the spid which is actually blocking. It is the same case even if you do query sys.dm_exec_requests.

By: Garry

Garry — Sat, 16 Jul 2011 19:44:40 +0000

Thanks a bunch, that saved me a fair bit of time. How many years have you spent learning Microsoft SQL? You so are an internet high-and-mighty at it!

Thanks again, Garry.

By: Maddy

Maddy — Thu, 26 May 2011 06:45:30 +0000

i get the session blocking because one Procedure is blocking to other Procedure.
After looking into the procedures we found that the select query in both the procedures uses the same function and the joins are on same tables in both procedures.
These two procedures were executing at same time and hence the blocking issue occurred.
Can u tell me the possible solution on this issue ?

By: Jason

Jason — Tue, 22 Mar 2011 19:53:27 +0000

If this is once a blue moon blocking, you might kill it and call victory. However, I suggest readers first understand the implications.

1) If this is a web app, when you kill it, the user on the other end of the world might re-submit again after seeing execution unsuccessful. Blocking occurs again. You are tracing tail.

2) If the code has fundamental issues, you need to identify the code issue and point out to developers to fix. Kill it in reaal-time won’t do anything good in the long-run.

Please visit my SQLSaturday#57 presentation which covers blocking.

If you are killing the same job, same code execution, you better stop and find out what is wrong with that code.

By: Dant

Dant — Sat, 09 Oct 2010 18:21:31 +0000

@bandit

check the compatibility on the database, should be 90 or higher

By: EstebanD

EstebanD — Thu, 07 Oct 2010 15:40:23 +0000

Thanks.

Not sure if I got this from you too, but our dirty solution for the same problem is finding which connection has been running for long time.

Probably this only works well with small, simple and low traffic implementations.

SELECT sqltext.TEXT,
req.session_id,
req.status,
req.command,
req.cpu_time,
req.total_elapsed_time
FROM sys.dm_exec_requests req
CROSS APPLY sys.dm_exec_sql_text(sql_handle) AS sqltext

By: bandit

bandit — Wed, 06 Oct 2010 18:08:00 +0000

I’m trying to run the query on SQL Server 2008 and it is breakingon the CROSS APPLY line in the predicate – not sure what this is

By: Tim C

Tim C — Wed, 06 Oct 2010 14:33:56 +0000

I am confused, would not DBCC OPENTRAN get him the same results?

By: amns

amns — Wed, 06 Oct 2010 09:23:04 +0000

Pinal, thanks for this helpfull post.