SQL Serve READ UNCOMMITTED Isolation level does not honor locks. Really?

Hi Friends,

We know that SQL Server READ UNCOMMITTED Isolation level allows dirty read. That is, neither does it ask for locks nor does it honor locks held by other transactions. This is true in case of reading and writing data. But the story is different if another transaction has issued a DDL statement. Let us see.

In a query window, execute the following code:

-- connection 1
   ALTER TABLE Person.Person
   ADD Address2 nvarchar(100);

In another query window, read from the table under READ UNCOMMITTED isolation level.

FROM    Person.Person
WHERE   LastName = 'BANSAL';

And you will observe that the above transaction will wait indefinitely even though it is running under READ UNCOMMITTED isolation level.

In a new query window, say connection 3, observe the locks.

SELECT   request_session_id
FROM    sys.dm_tran_locks

Following is what you will observe (your session ids might be different)



Apart from number of locks being held by session 57 (which has issued the DDL statement), it has been granted the Sch-M (Schema Modification lock). And session 56 (running under READ UNCOMMITTED) isolation level waits.

ROLLBACK both the transactions.

You can see that READ UNCOMMITTED does honor locks.




About Amit Bansal

Amit Bansal is always brainstorming around SQL Server. Despite working with SQL since 1997, he is amazed that he keeps learning new things every single day. SQL Server is AB's first love, and his wife does not mind that. He tries to share as much and spreads the SQL goodness. Internals and Performance Tuning excites him, and also gives him sleepless nights at times, simply because he is not a genius, but quite a hard worker and does not give up. It has been a long and exciting journey since 1997, you can read here: http://sqlmaestros.com/amit-bansal/ He is on Twitter: https://www.twitter.com/A_Bansal

View all posts by Amit Bansal →

Leave a Reply

Your email address will not be published.