Lesson Learned #152: When the transaction context matters in a blocking issue!

This post has been republished via RSS; it originally appeared at: Azure Database Support Blog articles.

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!

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.