WITH (nolock) sugerencia es un mandamiento explícito dirigido a una determinada tabla o vista utilizada para establecer el nivel de aislamiento de transacción en la tabla o tablas en una vista para una consulta. Una vez emitidos, los bloqueos no se utilizarán contra los datos dentro de la tabla. La ventaja de esto es que no hay posibilidad de que se produzca un bloqueo contra cualquier otra consulta que se ejecute contra la tabla., La otra ventaja indirecta es que se usará menos memoria para mantener bloqueos contra esos datos.

ejemplo:

la configuración de nolock anterior es explícita para la tabla contra la que se está estableciendo.,s no se producirá contra otras consultas que se ejecutan contra los mismos datos

desventajas:

• Los datos no comprometidos se pueden leer dando lugar a lecturas sucias
• Las sugerencias explícitas contra una tabla son generalmente malas prácticas

uso

en la mayoría de los lugares en los que he trabajado, con (NOLOCK) ha sido una práctica generalmente aceptada en las áreas específicas del sistema que no son sensibles a los datos que están ligeramente fuera de sincronización., Sin embargo, es importante saber dónde podrían salir mal las cosas. La bandera roja más grande que se me ocurre por no usar NOLOCK sería un sistema que usa transacciones explícitas (BEGIN TRAN ..END TRAN) o uso intensivo de desencadenantes. Varias sentencias ejecutadas dentro de una transacción experimentan un retardo de tiempo de sus operaciones de inserción / actualización / eliminación, sin embargo, los cambios se confirman de inmediato al confirmar., Las declaraciones que consultan los datos modificados usando el nivel de aislamiento READ COMMITTED serán bloqueadas para ver estos cambios hasta la confirmación, mientras que READ UNCOMITTED (NOLOCK) verá los cambios inmediatamente independientemente de cuando ocurra la confirmación. La suposición aquí es que si su sistema utiliza transacciones explícitas o se basa en disparadores en gran medida, puede ser plausible asumir nolock no es una buena idea.,

no use con (NOLOCK) sin comprender completamente las ramificaciones de una lectura sucia

ejemplo de una lectura sucia

el siguiente ejemplo abrirá una transacción para actualizar la columna first_name en nuestra tabla temporal global: ##my_name

IF OBJECT_ID(‘tempdb..,##my_name’) no es nulo
BEGIN
DROP TABLE ##my_name;
END;

CREATE TABLE ##my_name
(
id int,
first_name varchar(20)
);

INSERT INTO ##my_name (id, first_name)
VALUES (1, ‘dexter’);

BEGIN TRAN

UPDATE ##my_name
set first_name = ‘Derek’
WHERE id = 1;

Aquí hemos dejado una transacción abierta en ##my_name para que la fila esté bloqueada exclusivamente y no pueda ser leída por ninguna transacción que utilice el nivel de aislamiento READ COMMITTED o superior.,

Aquí verá que la primera consulta mostrará el valor actualizado ‘derek’, mientras que la consulta sin el nolock se colgará esperando que la transacción se libere. Los datos que se han leído con éxito se consideran datos sucios. Esto se debe a que puede haber otras tablas que deben actualizarse que se relacionan con el registro’ derek ‘ (id=1) para mostrar una vista coherente de todos los datos relacionados con ‘derek’.

finalmente confirmemos nuestra transacción dentro de nuestra ventana original y verá que ahora puede consultar los datos sin usar (nolock).,

COMMIT TRAN
SELECT * FROM ##my_name;