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:
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
insert t values (@i, @i, @i)
set @i = @i + 1
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.