What's blocking “Select top 1 * from TableName with (nolock)” from returning a result?

Question

I\'m currently running the following statement

select * into adhoc..san_savedi from dps_san..savedi_record

It\'s taking a painfully long time a

Answer 1

SELECT queries with NOLOCK don't actually take no locks, they still need a SCH-S (schema stability) lock on the table (and as it is a heap it will also take a hobt lock).

Additionally before the SELECT can even begin SQL Server must compile a plan for the statement, which also requires it to take a SCH-S lock out on the table.

As your long running transaction creates the table via SELECT ... INTO it holds an incompatible SCH-M lock on it until the statement completes.

You can verify this by looking in sys.dm_os_waiting_tasks whilst while during the period of blocking.

When I tried the following in one connection

BEGIN TRAN

SELECT *
INTO NewT
FROM master..spt_values

/*Remember to rollback/commit this later*/

And then executing (or just simply trying to view the estimated execution plan)

SELECT *
FROM NewT
WITH (NOLOCK)

in a second the reading query was blocked.

SELECT wait_type,
       resource_description
FROM sys.dm_os_waiting_tasks
WHERE session_id = 

Shows the wait type is indeed SCH_S and the blocking resource SCH-M

wait_type        resource_description
---------------- -------------------------------------------------------------------------------------------------------------------------------
LCK_M_SCH_S      objectlock lockPartition=0 objid=461960722 subresource=FULL dbid=1 id=lock4a8a540 mode=Sch-M associatedObjectId=461960722