¿Qué está bloqueando "Seleccione top 1 * from TableName with (nolock)" para devolver un resultado?

Question

Actualmente estoy ejecutando la siguiente instrucción

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

Se trata de tomar una dolorosamente mucho tiempo y me gustaría ver qué tan avanzado es así que corrí esto:

select count(*) from adhoc..san_savedi with (nolock) 

Ese didn' t devuelve nada en el momento oportuno por lo que para el gusto de hacerlo lo hice:

select top 1 * from adhoc..san_savedi with (nolock) 

Aun que parece funcionar indefinidamente. Podría entender si hay millones de registros que el recuento (*) podría llevar mucho tiempo, pero no entiendo por qué seleccionar el registro de la parte superior 1 no volvería casi inmediatamente, considerando que especifique nolock.

En nombre de la divulgación completa, dps_san es una vista que extrae de una conexión odbc a través del servidor vinculado. No creo que eso afecte el por qué no puedo regresar a la fila superior, sino simplemente tirarlo por si me equivoco.

Entonces, ¿quiero saber qué es lo que impide que esta declaración se ejecute?

EDIT:

Como he mencionado anteriormente, sí dps_san..savedi_record es una vista. Esto es lo que hace:

select * from DPS_SAN..root.SAVEDI_RECORD 

No es nada más que un alias y no hace ninguna agrupación/clasificación/etc así que no creo que el problema radica aquí, pero por favor aclararme si estoy equivocado.

Answer 1

SELECT consultas con NOLOCK en realidad no tomar ninguna cerradura, todavía necesitan una cerradura SCH-S (estabilidad esquema) sobre la mesa (and as it is a heap it will also take a hobt lock).

Además, antes de que el SELECT incluso pueda comenzar SQL Server debe compilar un plan para la instrucción, que también requiere que tome un bloqueo SCH-S en la tabla.

Como su transacción de larga ejecución crea la tabla a través de SELECT ... INTO, tiene un bloqueo SCH-M incompatible hasta que finalice la instrucción.

Usted puede verificar esto buscando en sys.dm_os_waiting_tasks mientras mientras durante el período de bloqueo.

cuando intenté lo siguiente en una conexión

BEGIN TRAN 

SELECT * 
INTO NewT 
FROM master..spt_values 

/*Remember to rollback/commit this later*/ 

Y luego ejecutar (o simplemente tratando de ver el plan de ejecución estimado)

SELECT * 
FROM NewT 
WITH (NOLOCK) 

en un segundo la consulta de lectura fue bloqueado.

SELECT wait_type, 
     resource_description 
FROM sys.dm_os_waiting_tasks 
WHERE session_id = <spid_of_waiting_task> 

Muestra el tipo de espera es de hecho SCH_S y el recurso de bloqueo 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 

Answer 2

Es muy posible que no haya bloqueos ... Si dps_san..savedi_record es una vista, puede llevar mucho tiempo ejecutarla, ya que puede estar accediendo a tablas sin usar un índice, o puede estar ordenando millones de registros, o cualquier otra razón. Entonces su consulta, incluso un simple top o conteo, será solo tan rápido como se pueda ejecutar esa vista.

Answer 3

Algunos problemas a considerar aquí. ¿Es dps_san..savedi_record una vista? Si es así, podría tomar mucho tiempo obtener sus datos. La otra cosa que puedo pensar es que estás tratando de crear una tabla temporal usando la sintaxis select into, lo cual es una mala idea. La sintaxis select * into ... bloqueará el tempdb durante la duración de la selección.

Si está creando la tabla con esa sintaxis, existe una solución alternativa. En primer lugar, crear la tabla lanzando where 1=0 al final de su declaración inicial:

select * into ... from ... where 1=0 

Esto creará la tabla primero (que es rápido), que le permite a insert into porque la tabla existe ahora (sin penalización del tempdb bloqueo para la duración de la consulta).

Answer 4

Encuentra la session_id que está realizando la select into:

SELECT r.session_id, r.blocking_session_id, r.wait_type, r.wait_time 
    FROM sys.dm_exec_requests AS r 
    CROSS APPLY sys.dm_exec_sql_text(r.plan_handle) AS t 
    WHERE t.[text] LIKE '%select%into%adhoc..san_savedi%'; 

Esto debería saber si otra sesión está bloqueando la selección en o si tiene un tipo de espera que está causando un problema.

Puede repetir el proceso en otra ventana para la sesión que está intentando hacer la selección. Sospecho que Martin tiene razón y que mi comentario anterior sobre el bloqueo del esquema es relevante.