Craig Freedman's SQL Server Blog : Isolation Levels

Query Failure with Read Uncommitted

craigfr — Tue, 12 Jun 2007 22:54:00 GMT

Over the past month or so, I've looked at pretty much every isolation level except for read uncommitted or nolock. Today I'm going to wrap up this series of posts with a discussion of read uncommitted. Plenty has already been written about the dangers of nolock. For example, see these excellent posts by Lubor Kollar of the SQL Server Development Customer Advisory Team and by Tony Rogerson.

I'd like to demonstrate just one additional hazard of nolock. Begin by creating two tables as follows:

create table t1 (k int, data int)
insert t1 values (0, 0)
insert t1 values (1, 1)

create table t2 (pk int primary key)
insert t2 values (0)
insert t2 values (1)

Next, in session 1 lock the first row of t2 using the following update:

begin tran
update t2 set pk = pk where pk = 0

Now, in session 2 run the following query:

select *
from t1 with (nolock)
where exists (select * from t2 where t1.k = t2.pk)

This query uses the following plan:

|--Nested Loops(Left Semi Join, WHERE:([t1].[k]=[t2].[pk]))
|--Table Scan(OBJECT:([t1]))
|--Clustered Index Scan(OBJECT:([t2].[PK__t2__71D1E811]))

The table scan fetches the first row of t1 without acquiring any locks and then tries to join this row with t2. Since we've locked the first row of t2 and since the clustered index scan of t2 runs at the default read committed isolation level, the query blocks.

Finally, in session 1 delete the first row of t1 and commit the transaction:

delete t1 where k = 0
commit tran

The query in session 2 is now free to continue. However, we deleted the row that it is trying to join while it was blocked. The query tries to retrieve more data from the deleted row and fails with the following error:

Msg 601, Level 12, State 3, Line 1
Could not continue scan with NOLOCK due to data movement.

As you can see, not only can a read uncommitted or nolock scan cause unexpected results, it can even cause a query to fail entirely!

SQL Server 2000 can also generate this error if a query plan includes a bookmark lookup and if a row is deleted after it is returned by a non-clustered index seek but before the base table row is fetched by the bookmark lookup. SQL Server 2005 does not generate an error in this case. Recall that in SQL Server 2005 a bookmark lookup is just a join. Thus, if the bookmark lookup cannot find a matching base table row, it simply discards it just like any other join.

Read Committed and Bookmark Lookup

craigfr — Fri, 08 Jun 2007 00:27:00 GMT

In my last two posts, I discussed two scenarios - one involving updates and another involving large objects - where SQL Server extends the duration of read committed locks until the end of a statement instead of releasing the locks as soon as each row is released. In this post - which I promise will be the last in this series on read committed locks - I will discuss a final scenario involving bookmark lookups where SQL Server holds read committed locks longer than expected.

As you might expect, if you've read my prior two posts, this final scenario occurs when there is a blocking operator between the non-clustered index seek and the bookmark lookup operation. There are basically three cases:

A sort on the outer side of the nested loops join.
An "OPTIMIZED" nested loops join.
A nested loops join "WITH PREFETCH."

The following example demonstrates a bookmark lookup with a nested loops join with a prefetch:

create table t (a int, b int, c char(1000))
create unique clustered index ta on t(a)

set nocount on
declare @i int
set @i = 0
while @i < 1000
begin
insert t values (@i, @i, @i)
set @i = @i + 1
end
set nocount off

create index tb on t(b)

select c from t where b < 25

Here is the query plan for the select:

|--Nested Loops(Inner Join, OUTER REFERENCES:([t].[a], [Expr1004]) WITH UNORDERED PREFETCH)
|--Index Seek(OBJECT:([t].[tb]), SEEK:([t].[b] < (25)) ORDERED FORWARD)
|--Clustered Index Seek(OBJECT:([t].[ta]), SEEK:([t].[a]=[t].[a]) LOOKUP ORDERED FORWARD)

Note the "WITH UNORDERED PREFETCH" keywords on the nested loops join.

I am not going to demontrate it , but when SQL Server executes this query, it holds S locks on the rows returned by the index seek until the query finishes executing. If you want to view these locks, you can set up an experiment similar to the ones from my prior two posts.

Why does SQL Server acquire these extra locks? Suppose that SQL Server did not hold the S locks on the index seek until the end of the statement but rather released them immediately. The prefetch results in a delay between when the index seek returns rows and when the join processes the rows and the executes the clustered index seek. During this delay, there would be no locks held on rows returned by the seek but not yet processed by the join. Another session could slip in, modify the row, and cause an inconsistency similar to the one that I demonstrated with index intersections in this post.

Before I wrap up with this topic, I want to emphasize a couple more points. First, updates can also use prefetching. So, if you have a query plan with an update that includes a prefetch (again, look for the "WITH PREFETCH" keywords), SQL Server holds locks on the source of the rows to be updated just as it does when the plan includes any other blocking operator such as a sort or spool. Second, to avoid corrupting data, updates always acquire locks even when run at read uncommitted isolation level and, if necessary due to blocking operators in the plan, hold these locks until the end of the statement. Queries that access large objects and queries with bookmark lookups do not acquire or hold locks when run at read uncommitted isolation level.

Read Committed and Large Objects

craigfr — Thu, 31 May 2007 19:00:00 GMT

In my last post, I explained that SQL Server holds read committed locks until the end of an update statement (instead of releasing the locks as soon as each row is released) if there is a blocking operator between the scan or seek of the rows to be updated and the update itself. In this post, I'll take a look at a similar result involving large objects.

Normally, when SQL Server moves data through a blocking operator such as a sort, it makes a copy of the data. Once SQL Server makes a copy, there is no need to preserve the original row or source of the data. However, since large objects (e.g., varchar(max)) can store up to 2 Gbytes, it is generally not practical to make copies of large objects. Instead, whenever possible, SQL Server uses "pointers" to the data instead of making copies of the data. To ensure that the pointers remain valid, SQL Server does not release any locks on the rows that contain the large objects until the statement completes.

Let's observe this behavior. Begin by creating the following table:

create table t (pk int primary key, i int, lob varchar(max))
insert t values (1, 1, 'abc')
insert t values (2, 2, 'def')
insert t values (3, 3, 'ghi')

In session 1 lock the third row:

begin tran
update t set i = i where pk = 3

Now, in session 2 check the spid (we'll use it later to look at the locks) and run this query which scans the table and reads each large object (using the default read committed isolation level):

select @@spid

select lob from t

This query uses a trivial plan which consists of a clustered index scan:

|--Clustered Index Scan(OBJECT:([t].[PK__t__2D27B809]))

Because session 1 has a lock on the third row of the table, the scan blocks. While it is blocked, we can check which locks it holds by running the following query in session 1:

select resource_type, request_mode, request_type, request_status
from sys.dm_tran_locks
where request_session_id = <session_2_spid>

resource_type  request_mode  request_type  request_status
-------------  ------------  ------------  ---------------
DATABASE       S             LOCK          GRANT
PAGE           IS            LOCK          GRANT
KEY            S             LOCK          WAIT
OBJECT         IS            LOCK          GRANT

We see the the scan is not holding any key locks and is waiting for the one key lock held by session 1.

Next, kill the scan in session 2 and try the following query:

select lob from t order by i

The plan for this query includes a sort:

|--Sort(ORDER BY:([t].[i] ASC))
|--Clustered Index Scan(OBJECT:([t].[PK__t__2D27B809]))

As I explained above, when we check the locks held by this query, we find that due to the large object and the blocking sort, this query holds key locks on each row it touches:

resource_type  request_mode  request_type  request_status
-------------  ------------  ------------  ---------------
DATABASE       S             LOCK          GRANT
KEY            S             LOCK          GRANT
PAGE           IS            LOCK          GRANT
KEY            S             LOCK          WAIT
OBJECT         IS            LOCK          GRANT
KEY            S             LOCK          GRANT

If you have any doubt whether the extra key locks are due to the large object, repeat this experiment with the following nearly identical query which does not return the large object:

select i from t order by i

Finally, try one more query:

select i from t where lob > 'a'

The plan for this query uses an explicit filter operator to evaluate the predicate on the large object:

|--Filter(WHERE:([t].[lob]>[@1]))
|--Clustered Index Scan(OBJECT:([t].[PK__t__2D27B809]))

The filter is not a blocking operator and the query does return the large object. Nevertheless, if you run this query, you will observe that SQL Server once again holds locks on each row touched by this query. In this example, SQL Server is overly conservative and retains the locks even though they are technically unnecessary.

Read Committed and Updates

craigfr — Wed, 23 May 2007 00:07:00 GMT

Let's try an experiment. Begin by creating the following simple schema:

create table t1 (a int, b int)
create clustered index t1a on t1(a)
insert t1 values (1, 1)
insert t1 values (2, 2)
insert t1 values (3, 3)

create table t2 (a int)
insert t2 values (9)

In session 1, lock the third row of table t1:

begin tran
update t1 set b = b where a = 3

Now, in session 2 check the spid (you'll need it later) and run the following update at the default read committed isolation level:

select @@spid

update t1 set t1.b = t1.b
where exists (select * from t2 where t2.a = t1.b)

This update uses the following plan:

|--Clustered Index Update(OBJECT:([t1].[t1a]), SET:([t1].[b] = [t1].[b]))
       |--Top(ROWCOUNT est 0)
            |--Nested Loops(Left Semi Join, WHERE:([t2].[a]=[t1].[b]))
                 |--Clustered Index Scan(OBJECT:([t1].[t1a]))
                 |--Table Scan(OBJECT:([t2]))

This plan scans table t1 and looks each row up in table t2 to see whether the row must be updated. The scan acquires U locks on each row of t1. If the row is updated, the update upgrades the lock to an X lock. If the row is not updated, the scan releases the row and the lock since we are running in read committed isolation.

Since session 1 is holding a lock on the third row of table t1, the udpate blocks when the scan of t1 reaches the third row. At this point, we can check what locks session 2 is holding by running the following query in session 1 (or any other session):

select resource_type, request_mode, request_type, request_status
from sys.dm_tran_locks
where request_session_id = <session_2_spid>

resource_type  request_mode  request_type  request_status
-------------  ------------  ------------  --------------
DATABASE       S             LOCK          GRANT
OBJECT         IS            LOCK          GRANT
KEY            U             LOCK          WAIT
PAGE           IU            LOCK          GRANT
OBJECT         IX            LOCK          GRANT

As expected, we see only one outstanding U lock request.

Next, return to session 2, abort the blocked update, and run the following statement:

update t1 set t1.a = t1.a
where exists (select * from t2 where t2.a = t1.b)

Notice that this time we are updating the clustering key of the index. Updates to the clustering key can cause rows to move within the index. To ensure that a row is not updated, encountered again by the same scan, and updated a second time (which would be incorrect), SQL Server must add a blocking operator between the scan and update of table t1. This requirement is known as "Halloween protection." Indeed, the new plan includes a sort:

|--Clustered Index Update(OBJECT:([t1].[t1a]), SET:([t1].[a] = [t1].[a]))
       |--Top(ROWCOUNT est 0)
            |--Sort(DISTINCT ORDER BY:([t1].[a] ASC, [Uniq1002] ASC))
                 |--Nested Loops(Inner Join, WHERE:([t2].[a]=[t1].[b]))
                      |--Clustered Index Scan(OBJECT:([t1].[t1a]), ORDERED FORWARD)
                      |--Table Scan(OBJECT:([t2]))

Once again this update blocks. Let's check the which locks it is holding by running the above query on the sys.dm_tran_locks DMV:

resource_type  request_mode  request_type  request_status
-------------  ------------  ------------  --------------
DATABASE       S             LOCK          GRANT
OBJECT         IS            LOCK          GRANT
KEY            U             LOCK          WAIT
KEY            U             LOCK          GRANT
KEY            U             LOCK          GRANT
PAGE           IU            LOCK          GRANT
OBJECT         IX            LOCK          GRANT

This time we see that there are two granted U locks. What's going on? Shouldn't these locks have been released since we are running a read committed scan? Not so fast! With the blocking sort operator in the plan, no rows are updated until the scan completes. If SQL Server simply released each U lock when the scan of t1 released each row, none of the rows would be locked when the update started. Without any locks, another session could slip in and modify the rows that we'd already scanned and which we were planning to update. Allowing another session to modify these rows could lead to incorrect results and data corruption. Thus, SQL Server retains these locks until the statement (not the transaction) finishes executing.

Serializable vs. Snapshot Isolation Level

craigfr — Wed, 16 May 2007 21:45:00 GMT

Both the serializable and snapshot isolation levels provide a read consistent view of the database to all transactions. In either of these isolation levels, a transaction can only read data that has been committed. Moreover, a transaction can read the same data multiple times without ever observing any concurrent transactions making changes to this data. The unexpected read committed and repeatable read results that I demonstrated in my prior few posts are not possible in serializable or snapshot isolation level.

Notice that I used the phrase "without ever observing any ... changes." This choice of words is deliberate. In serializable isolation level, SQL Server acquires key range locks and holds them until the end of the transaction. A key range lock ensures that, once a transaction reads data, no other transaction can alter that data - not even to insert phantom rows - until the transaction holding the lock completes. In snapshot isolation level, SQL Server does not acquire any locks. Thus, it is possible for a concurrent transaction to modify data that a second transaction has already read. The second transaction simply does not observe the changes and continues to read an old copy of the data.

Serializable isolation level relies on pessimistic concurrency control. It guarantees consistency by assuming that two transactions might try to update the same data and uses locks to ensure that they do not but at a cost of reduced concurrency - one transaction must wait for the other to complete and two transactions can deadlock. Snapshot isolation level relies on optimistic concurrency control. It allows transactions to proceed without locks and with maximum concurrency, but may need to fail and rollback a transaction if two transactions attempt to modify the same data at the same time.

It is clear there are differences in the level of concurrency that can be achieved and in the failures (deadlocks vs. update conflicts) that are possible with the serializable and snapshot isolation levels.

How about transaction isolation? How do serializable and snapshot differ in terms of the transaction isolation that they confer? It is simple to understand serializable. For the outcome of two transactions to be considered serializable, it must be possible to achieve this outcome by running one transaction at a time in some order.

Snapshot does not guarantee this level of isolation. A few years ago, Jim Gray shared with me the following excellent example of the difference. Imagine that we have a bag containing a mixture of white and black marbles. Suppose that we want to run two transactions. One transaction turns each of the white marbles into black marbles. The second transaction turns each of the black marbles into white marbles. If we run these transactions under serializable isolation, we must run them one at a time. The first transaction will leave a bag with marbles of only one color. After that, the second transaction will change all of these marbles to the other color. There are only two possible outcomes: a bag with only white marbles or a bag with only black marbles.

If we run these transactions under snapshot isolation, there is a third outcome that is not possible under serializable isolation. Each transaction can simultaneously take a snapshot of the bag of marbles as it exists before we make any changes. Now one transaction finds the white marbles and turns them into black marbles. At the same time, the other transactions finds the black marbles - but only those marbles that where black when we took the snapshot - not those marbles that the first transaction changed to black - and turns them into white marbles. In the end, we still have a mixed bag of marbles with some white and some black. In fact, we have precisely switched each marble.

The following graphic illustrates the difference:

We can demonstrate this outcome using SQL Server. Note that snapshot isolation is only available in SQL Server 2005 and must be explicitly enabled on your database:

alter database database_name set allow_snapshot_isolation on

Begin by creating a simple table with two rows representing two marbles:

create table marbles (id int primary key, color char(5))
insert marbles values(1, 'Black')
insert marbles values(2, 'White')

Next, in session 1 begin a snaphot transaction:

set transaction isolation level snapshot
begin tran
update marbles set color = 'White' where color = 'Black'

Now, before committing the changes, run the following in session 2:

set transaction isolation level snapshot
begin tran
update marbles set color = 'Black' where color = 'White'
commit tran

Finally, commit the transaction in session 1 and check the data in the table:

commit tran
select * from marbles

Here are the results:

id          color
----------- -----
1           White
2           Black

As you can see marble 1 which started out black is now white and marble 2 which started out white is now black. If you try this same experiment with serializable isolation, one transaction will wait for the other to complete and, depending on the order, both marbles will end up either white or black.

Repeatable Read Isolation Level

craigfr — Wed, 09 May 2007 17:57:00 GMT

In my last two posts, I showed how queries running at read committed isolation level may generate unexpected results in the presence of concurrent updates. Many but not all of these results can be avoided by running at repeatable read isolation level. In this post, I'll explore how concurrent updates may affect queries running at repeatable read.

Unlike a read committed scan, a repeatable read scan retains locks on every row it touches until the end of the transaction. Even rows that do not qualify for the query result remain locked. These locks ensure that the rows touched by the query cannot be updated or deleted by a concurrent session until the current transaction completes (whether it is committed or rolled back). These locks do not protect rows that have not yet been scanned from updates or deletes and do not prevent the insertion of new rows amid the rows that are already locked. The following graphic illustrates this point:

Note that the capability to insert new "phantom" rows between locked rows that have already been scanned is the principle difference between the repeatable read and serializable isolation levels. A serializable scan acquires a key range lock which prevents the insertion of any new rows anywhere within the range (as well as the update or deletion of any existing rows within the range).

In the remainder of this post, I'll give a couple of examples of how we can get unexpected results even while running queries at repeatable read isolation level. These examples are similar to the ones from my previous two posts.

Row Movement

First, let's see how we can move a row and cause a repeatable read scan to miss it. As with all of the other example in this series of posts, we'll need two sessions. Begin by creating this simple table:

create table t (a int primary key, b int)
insert t values (1, 1)
insert t values (2, 2)
insert t values (3, 3)

Next, in session 1 lock the second row:

begin tran
update t set b = 2 where a = 2

Now, in session 2 run a repeatable read scan of the table:

select * from t with (repeatableread)

This scan reads the first row then blocks waiting for session 1 to release the lock it holds on the second row. While the scan is blocked, in session 1 let's move the third row to the beginning of the table before committing the transaction and releasing the exclusive lock blocking session 2:

update t set a = 0 where a = 3
commit tran

As we expect, session 2 completely misses the third row and returns just two rows:

a           b           c
----------- ----------- -----------
1           1           1
2           2           2

Note that if we change the experiment so that session 1 tries to touch the first row in the table, it will cause a deadlock with session 2 which holds a lock on this row.

Phantom Rows

Let's also take a look at how phantom rows can cause unexpected results. This experiment is similar to the nested loops join experiment from my previous post. Begin by creating two tables:

create table t1 (a1 int primary key, b1 int)
insert t1 values (1, 9)
insert t1 values (2, 9)

create table t2 (a2 int primary key, b2 int)

Now, in session 1 lock the second row of table t1:

begin tran
update t1 set a1 = 2 where a1 = 2

Next, in session 2 run the following outer join at repeatable read isolation level:

set transaction isolation level repeatable read
select * from t1 left outer join t2 on b1 = a2

The query plan for this join uses a nested loops join:

|--Nested Loops(Left Outer Join, WHERE:([t1].[b1]=[t2].[a2]))
|--Clustered Index Scan(OBJECT:([t1].[PK__t1]))
|--Clustered Index Scan(OBJECT:([t2].[PK__t2]))

This plan scans the first row from t1, tries to join it with t2, finds there are no matching rows, and outputs a null extended row. It then blocks waiting for session 1 to release the lock on the second row of t1. Finally, in session 1, insert a new row into t2 and release the lock:

insert t2 values (9, 0)
commit tran

Here is the output from the outer join:

a1          b1          a2          b2
----------- ----------- ----------- -----------
1           9           NULL        NULL
2           9           9           0

Notice that we have both a null extended and a joined row for the same join key!

Summary

As I pointed out at the conclusion of my previous post, I want to emphasize that the above results are not incorrect but rather are a side effect of running at a reduced isolation level. SQL Server guarantees that the committed data is consistent at all times.

CLARIFICATION 8/26/2008: The above examples work as I originally described if they are executed in tempdb. However, the SELECT statements in session 2 may not block as described if the examples are executed in other databases due to an optimization where SQL Server avoids acquiring read committed locks when it knows that no data has changed on a page. If you encounter this problem, either run these examples in tempdb or change the UPDATE statements in session 1 so that they actually change the data in the updated row. For instance, for the first example try "update t set b = 12 where a = 2".

Query Plans and Read Committed Isolation Level

craigfr — Wed, 02 May 2007 21:48:00 GMT

Last week I looked at how concurrent updates may cause a scan running at read committed isolation level to return the same row multiple times or to miss a row entirely. This week I'm going to take a look at how concurrent updates may affect slightly more complex query plans.

Nested Loops Join

Let's begin by considering this simple query:

create table Customers (CustId int primary key, LastName varchar(30))
insert Customers values (11, 'Doe')

create table Orders (OrderId int primary key, CustId int foreign key references Customers, Discount float)
insert Orders values (1, 11, 0)
insert Orders values (2, 11, 0)

select * from Orders O join Customers C on O.CustId = C.CustId

The plan for this query uses a nested loops join:

|--Nested Loops(Inner Join, OUTER REFERENCES:([O].[CustId]))
|--Clustered Index Scan(OBJECT:([Orders].[PK__Orders] AS [O]))
|--Clustered Index Seek(OBJECT:([Customers].[PK__Customers] AS [C]), SEEK:([C].[CustId]= [O].[CustId]))

Recall that the nested loops join executes its inner input once for each row from its outer input. In this example, the Orders table is the outer table and we have two orders so we will execute two seeks of the Customers table. Moreover, both orders were placed by the same customer. What happens if we change the customer data between the two index seeks? We can setup an experiment to find out. First, lock the second order in session 1:

begin tran
update Orders set Discount = 0.1 where OrderId = 2

Now, in session 2 run the join:

select * from Orders O join Customers C on O.CustId = C.CustId

The join will scan the first order and join it with the Customers table. Then it will try to scan the second order and block waiting for the lock held by session 1. Finally, in session 1 update the customer name and commit the transaction to release the lock and allow the query in session 2 to complete:

update Customers set LastName = 'Smith' where CustId = 11
commit tran

Here are the results of the join:

OrderId     CustId      Discount               CustId      LastName
----------- ----------- ---------------------- ----------- ------------------------------
1           11          0                      11          Doe
2           11          0.1                    11          Smith

Notice that the customer data is different for the two orders even though the customer id is the same!

Full Outer Join

Next, consider the following full outer join query:

create table t1 (a1 int, b1 int)
insert t1 values (1, 1)
insert t1 values (2, 2)

create table t2 (a2 int, b2 int)
insert t2 values (1, 1)

select * from t1 full outer loop join t2 on t1.a1 = t2.a2

The nested loops join does not support full outer joins directly so this query generates a two part plan (which I described in my original nested loops join post):

Although the original query only references each table onces, this query plan includes two scans of each table. It is possible for the data to change between the two scans. Let's see what happens. Begin by locking the second row of t1 in session 1:

begin tran
update t1 set a1 = 2 where a1 = 2

Now, in session 2 run the join:

select * from t1 full outer loop join t2 on t1.a1 = t2.a2

The query plan begins by scanning the first row of t1 and joining it with t2 (where there is a matching row). It then blocks. Finally, in session 1 delete the first row from t1:

delete t1 where a1 = 1
commit tran

When the join query plan resumes it scans t2 and performs an anti-semi join with t1 to search for rows that exist in t2 and not in t1. These rows are required for the full outer join result, but cannot be generated by the left outer nested loops join. Keep in mind that by this point in the query plan we have already joined the first row of t1 with the row in t2. However, because we deleted the row from t1, the anti-semi join finds the row in t2, cannot match it with a row in t1, and generates a null extended row. Here is the result:

a1          b1          a2          b2
----------- ----------- ----------- -----------
1           1           1           1
2           2           NULL        NULL
NULL        NULL        1           1

As the above analysis suggests, the result includes both a joined and a null extended row!

CLARIFICATION 8/26/2008: The above example works as I originally described if it is executed in tempdb. However, the SELECT statement in session 2 may not block as described if the example is executed in other databases due to an optimization where SQL Server avoids acquiring read committed locks when it knows that no data has changed on a page. If you encounter this problem, either run this example in tempdb or change the UPDATE statement in session 1 so that it actually changes the value of column b1. For example, try "update t1 set b1 = 12 where a1 = 2".

Index Intersection

Finally, consider the following query:

create table t (a int primary key, b int, c int, check (b = c))
create index tb on t(b)
create index tc on t(c)

insert t values (1, 1, 1)
insert t values (2, 2, 2)

select * from t with (index(tb, tc))

I've forced an index intersection plan. The query plan scans and joins columns from both non-clustered indexes to form the final result:

|--Hash Match(Inner Join, HASH:([t].[a])=([t].[a]))
|--Index Scan(OBJECT:([t].[tb]))
|--Index Scan(OBJECT:([t].[tc]))

Recall that the hash join scans its entire build input (tb) and then scans its entire probe input (tc). What happens if the contents of the indexes change between the two scans? Once again, let's find out. Begin by locking the second row in session 1:

begin tran
update t set b = 4, c = 4 where a = 2

Now, in session 2 run the select statement:

select * from t with (index(tb, tc))

The inex scan of tb will read the first row and then block on the second row. Finally, in session 1, update the first row:

update t set b = 3, c = 3 where a = 1
commit tran

The select statement resumes, finishes the scan of index tb, scans index tc where it finds the updated first row, and returns a joined row that consists partially of a row prior to the update and partially of a row after the update:

a           b           c
----------- ----------- -----------
1           1           3
2           4           4

Notice that this result even seems to violate the check constraint!

Summary

I've demonstrated three ways that queries may behave unexpectedly when running in read committed isolation level. I want to emphasize that these results are not incorrect. SQL Server guarantees that the committed data is consistent at all times and does not permit any constraints to be violated. These results are merely a consequence of running at a relatively low isolation level. If we repeat the above experiments with snapshot read committed enabled or at a higher isolation level, we do not see these results. The benefit of read committed is higher concurrency with less blocking and fewer deadlocks. The disadvantage is lower consistency guarantees.

Read Committed Isolation Level

craigfr — Wed, 25 Apr 2007 19:59:00 GMT

SQL Server 2000 supports four different isolation levels: read uncommitted (or nolock), read committed, repeatable read, and serializable. SQL Server 2005 adds two new isolation levels: read committed snapshot and snapshot. These isolation levels determine what locks SQL Server takes when accessing data and, therefore, by extension they determine the level of concurrency and consistency that statements and transactions experience. All of these isolation levels are described in Books Online.

In this post, I'm going to take a closer look at the default isolation level of read committed. When SQL Server executes a statement at the read committed isolation level, it acquires short lived share locks on a row by row basis. The duration of these share locks is just long enough to read and process each row; the server generally releases each lock before proceeding to the next row. Thus, if you run a simple select statement under read committed and check for locks (e.g., with sys.dm_tran_locks), you will typically see at most a single row lock at a time. The sole purpose of these locks is to ensure that the statement only reads and returns committed data. The locks work because updates always acquire an exclusive lock which blocks any readers trying to acquire a share lock.

Now, let's suppose that we scan an entire table at read committed isolation level. Since the scan locks only one row at a time, there is nothing to prevent a concurrent update from moving a row before or after our scan reaches it. The following graphic illustrates this point:

Let's try an experiment to see this effect in action. We'll need two server sessions for this experiment. First, create a simple table with three rows:

create table t (a int primary key, b int)
insert t values (1, 1)
insert t values (2, 2)
insert t values (3, 3)

Next, in session 1 lock the second row:

begin tran
update t set b = 2 where a = 2

Now, in session 2 run a simple scan of the table:

select * from t

This scan will read the first row and then block waiting for session 1 to release the lock it holds on the second row. While the scan is blocked, in session 1 we can swap the first and third rows and then commit the transaction and release the exclusive lock blocking session 2:

update t set a = 4 where a = 1
update t set a = 0 where a = 3
select * from t
commit tran

Here are the new contents of the table following these updates:

a           b
----------- -----------
0           3
2           2
4           1

Finally, here is the result of the scan from session 2:

a           b
----------- -----------
1          1
2           2
4           1

Notice that in this output the first row was scanned prior to the updates while the third row was scanned following the updates. In fact, these two rows are really the same row from before and after the update. Moreover, the original third row that had the value (3, 3) is not output at all. (We could claim that changing the primary key effectively deleted one row and created a new row, but we could also achieve the same effect on a non-clustered index.)

Finally, try repeating this experiment, but add a unique column to the table:

create table t (a int primary key, b int, c int unique)
insert t values (1, 1, 1)
insert t values (2, 2, 2)
insert t values (3, 3, 3)

You'll get the same result, but you'll see "duplicates" in the unique column.

If the above results are not acceptable, you can either enable read committed snapshot for your database or you can run at a higher isolation level (albeit with somewhat lower concurrency).

CLARIFICATION 8/26/2008: The above example works as I originally described if it is executed in tempdb. However, the SELECT statement in session 2 may not block as described if the example is executed in other databases due to an optimization where SQL Server avoids acquiring read committed locks when it knows that no data has changed on a page. If you encounter this problem, either run this example in tempdb or change the UPDATE statement in session 1 so that it actually changes the value of column b. For example, try "update t set b = 12 where a = 2".