En un escenario de Data Warehouse, ¿hay alguna desventaja al usar WITH (NOLOCK)

Question

Tengo un DW de estilo Kimball (hechos y dimensiones en modelos estrella: no hay filas o columnas de hechos que lleguen tarde, no hay columnas que cambien de dimensiones, excepto la caducidad como parte de las dimensiones de tipo 2 que cambian lentamente) con un procesamiento diario pesado para insertar y actualizar filas (en nuevas fechas) y procesos de informes mensuales y diarios. Las tablas de hechos están divididas por fechas para facilitar la transferencia de datos antiguos.

Entiendo que el WITH (NOLOCK) puede hacer que se lean datos no confirmados, sin embargo, tampoco deseo crear ningún bloqueo que pueda causar que los procesos ETL fallen o se bloqueen.

En todos los casos, cuando leemos del DW, leemos de tablas de hechos para una fecha que no cambiará (las tablas de hechos están divididas por fecha) y tablas de dimensiones que no tendrán atributos que cambien para los hechos que están vinculados a.

Entonces, ¿hay alguna desventaja? - tal vez en los planes de ejecución o en la operación de tales SELECT , solo consultas que se ejecutan en paralelo en las mismas tablas.

Answer 1

Mientras se trate de datos sin actualización, no hay daño, pero me sorprendería si hay muchos beneficios. Yo diría que vale la pena intentarlo. Lo peor que sucederá es que obtendrá datos incompletos y / o inconsistentes si está en medio de una inserción por lotes, pero puede decidir si eso invalida algo útil.

Answer 2

Esto es lo que probablemente necesite:

`ALTER DATABASE AdventureWorks     SET READ_COMMITTED_SNAPSHOT ON;

ALTERAR BASE DE DATOS AdventureWorks     SET ALLOW_SNAPSHOT_ISOLATION ON; `

Luego sigue adelante y usa

ESTABLECER NIVEL DE AISLAMIENTO DE TRANSACCIÓN LEÍDO COMPROMETIDO

en sus consultas. De acuerdo con BOL:

El comportamiento de READ COMMITTED depende de la configuración de la opción de base de datos READ_COMMITTED_SNAPSHOT:

Si READ_COMMITTED_SNAPSHOT está establecido en OFF (el valor predeterminado), el Motor de base de datos usa bloqueos compartidos para evitar que otras transacciones modifiquen filas mientras la transacción actual ejecuta una operación de lectura. Los bloqueos compartidos también impiden que la instrucción lea las filas modificadas por otras transacciones hasta que se complete la otra transacción. El tipo de bloqueo compartido determina cuándo se liberará. Los bloqueos de fila se liberan antes de que se procese la siguiente fila. Los bloqueos de página se liberan cuando se lee la página siguiente, y los bloqueos de tabla se liberan cuando finaliza la declaración.

Si READ_COMMITTED_SNAPSHOT está establecido en ON, el Motor de base de datos usa el control de versiones de fila para presentar cada declaración con una instantánea transaccionalmente consistente de los datos tal como existían al comienzo de la declaración. Los bloqueos no se utilizan para proteger los datos de las actualizaciones de otras transacciones.

Espero esta ayuda. Raj

Answer 3

¿Ha considerado crear un INSTANTÁNEO DE LA BASE DE DATOS de su DW y ejecutar sus informes fuera de él?

Answer 4

Sí. Su SQL será mucho menos legible. Inevitablemente, perderá algunas sugerencias de NOLOCK porque los comandos SQL SELECT que usan la estrategia NOLOCK tienen que ponerlo por todas partes.

Puede obtener lo mismo configurando el nivel de aislamiento

ESTABLECER NIVEL DE AISLAMIENTO DE LA TRANSACCIÓN LEER NO COMPROMETIDO

Al final obtienes un 10% de aumento de rendimiento (lo siento, soy demasiado vago como para buscar el artículo, pero está disponible)

Diría que una ganancia del 10% no vale la pena reducir la legibilidad.

Answer 5

Si es posible hacer que toda la base de datos sea de solo lectura, entonces esta es una mejor opción. Obtendrá un rendimiento de lectura sin compromiso sin tener que modificar todo su código.

ALTER DATABASE adventureworks SET read_only

Answer 6

NOLOCK realiza una "lectura sucia" (indecentemente READ UNCOMMITTED hace lo mismo que NOLOCK). Si la base de datos se actualiza a medida que lee, existe el peligro de que recupere datos inconsistentes. La única opción es aceptar el bloqueo y, por lo tanto, el bloqueo, o elegir uno de los dos nuevos niveles de aislamiento ofrecidos en SQL 2005 en adelante discutido aquí .