Home/ Questions/Q 325045
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-12T09:10:48+00:00

we have a customer that’s been experiencing some blocking issues with our database application.

  • 0

we have a customer that’s been experiencing some blocking issues with our database application. We asked them to run a Blocked Process Report trace and the trace they gave us shows blocking occurring between a SELECT and UPDATE operation. The trace files show the following:

  • The same SELECT query is being executed at different isolation levels. One trace shows a Serializable IsolationLevel while a later trace shows a RepeatableRead IsolationLevel. We do not use an explicit transaction while executing the query.
  • The UPDATE query is being executed with a RepeatableRead isolation level but is being blocked by the SELECT query. This is expected as our updates are wrapped in an explicit transaction with IsolationLevel of RepeatableRead.

So basically we’re at a loss as to why the Isolation Level of the SELECT query would not be the default ReadCommitted IsolationLevel but, even more confusingly, why the IsolationLevel of the query would change over time? It is only one customer that is seeing this behaviour so we suspect it may be a database configuration issue.

Any ideas?

Thanks in advance,

Graham

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    In your scenario, I would recommend explicitly setting isolation level to snapshot – that will prevent read from getting in the way of writes (inserts and updates) by preventing locks, yet those read would still be “good” reads (i.e. not dirty data – it is not the same as a NOLOCK)

    Generally i find that where i have locking issues with my queries, i manually control the lock applied. e.g. i would do updates with row-level locks to avoid page/table level locking, and set my reads to readpast (accepting that i may miss some data, in some scenarios that might be ok)
    link|edit|delete|flag

    EDIT– Combining all the comments into the answer

    As part of the optimisation process, sql server avoids getting commited reads on a page that it know hasn’t changed, and automatically falls back to a lesser locking strategy. In your case, sql server drops from a serializable read to a repeatable read.

    Q: Thanks for that useful info regarding dropping Isolation Levels. Can you think of any reason that it would use Serializable IsolationLevel in the first place, given that we don’t use an explicit transaction for the SELECT – it was our understanding that the implicit transaction would use ReadCommitted?

    A: By default, SQL Server will use Read Commmited if that is your default isolation level BUT if you do not additionally specify a locking strategy in your query, you are basically saying to sql server “do what you think is best, but my preference is Read Commited”. Since SQL Server is free to choose, so it does in order to optimise the query. (The optimisation algorithm in sql server is very complex and i do not fully understand it myself). Not explicitly executing within a transaction does not, afaik, affect the isolation level that sql server uses.

    Q: One last thing, does it seem reasonable that SQL Server would increase the Isolation Level (and presumably the number of locks required) to optimise the query? I’m also wondering whether the reuse of a pooled connection would affect this if it inherited the last used Isolation Level?

    A: Sql server will do that as part of a process called “Lock Escalation”. From http://support.microsoft.com/kb/323630, i quote: “Microsoft SQL Server dynamically determines when to perform lock escalation. When making this decision, SQL Server takes into account the number of locks that are held on a particular scan, the number of locks that are held by the whole transaction, and the memory that is being used for locks in the system as a whole. Typically, SQL Server’s default behavior results in lock escalation occurring only at those points where it would improve performance or when you must reduce excessive system lock memory to a more reasonable level. However, some application or query designs may trigger lock escalation at a time when it is not desirable, and the escalated table lock may block other users”.

    Although lock escalation is not exactly the same thing as changing the isolation level a query runs under, this surprises me because i would not have expected sql server to take more locks than what the default isolation level permits.

    • 0