Today, we got a service request that our customer reported that the using the following article the blocker and blocked queries haven't relation between them.
In this post we are going to explain why?. Normally, when you need to identify blocking issues we’re used to run the following query explained on this URL.
select conn.session_id as blockerSession,conn2.session_id as BlockedSession,req.wait_time as Waiting_Time_ms,cast((req.wait_time/1000.) as decimal(18,2)) as Waiting_Time_secs,
cast((req.wait_time/1000./60.) as decimal(18,2)) as Waiting_Time_mins,t.text as BlockerQuery,t2.text as BlockedQuery, req.wait_type from sys.dm_exec_requests as req
inner join sys.dm_exec_connections as conn on req.blocking_session_id=conn.session_id
inner join sys.dm_exec_connections as conn2 on req.session_id=conn2.session_id
cross apply sys.dm_exec_sql_text(conn.most_recent_sql_handle) as t
cross apply sys.dm_exec_sql_text(conn2.most_recent_sql_handle) as t2
We found a situation that the query reported could not be the query that is blocking the another one. In this specify situation is when our customer is running multiple queries in the same transaction:
- If our customer is running a bunch of query in the same execution, you could see all the details, for example, this way.
BEGIN TRANSACTION
UPDATE
INSERT
COMMIT TRANSACTION
- However, if the customer application opens a new transaction and runs a single query per execution as a single unit within this transaction, you mightn’t see the exact query that is blocking other query. In this specific situation and depending on when you run the DMV to obtain the queries/transaction blocked you may see either of these queries INSERT TABLE1 or UPDATE TABLE2 (below).
Time Operation
11:00 AM Customer open a transaction – BEGIN TRANSACTION
11:01 AM Customer runs INSERT Table1
11:02 AM Customer runs UPDATE Table 2
11:03 AM Customer commit the transaction.
Enjoy!
