¿Por qué utilizar un nivel de aislamiento LEER NO COMPROMETIDO?

En inglés simple, ¿cuáles son las desventajas y ventajas de usar

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

en una consulta para aplicaciones .NET y aplicaciones de servicios de informes?

Este nivel de aislamiento permite lecturas sucias. Una transacción puede ver cambios no confirmados realizados por otra transacción.

Para mantener el nivel más alto de aislamiento, un DBMS generalmente adquiere bloqueos en los datos, lo que puede resultar en una pérdida de concurrencia y una alta sobrecarga de bloqueo. Este nivel de aislamiento relaja esta propiedad.

Es posible que desee consultar el artículo de Wikipedia sobreREAD UNCOMMITTED algunos ejemplos y lecturas adicionales.

También puede estar interesado en consultar el artículo del blog de Jeff Atwood sobre cómo él y su equipo abordaron un problema de punto muerto en los primeros días de Stack Overflow. De acuerdo con Jeff:

Pero es nolockpeligroso? ¿Podría terminar leyendo datos no válidos con read uncommittedon? Si, en teoria. No encontrará escasez de astronautas de arquitectura de bases de datos que comienzan a dejar caer la ciencia de ACID sobre usted y todo, pero activan la alarma de incendio del edificio cuando les dice que desea probarnolock . Es cierto: la teoría da miedo. Pero esto es lo que pienso: "En teoría no hay diferencia entre teoría y práctica. En la práctica sí la hay".

Nunca recomendaría usar nolock como una solución general de aceite de serpiente "bueno para lo que te aflige" para cualquier problema de bloqueo de la base de datos que puedas tener. Primero debe intentar diagnosticar la fuente del problema.

Pero en la práctica, agregar nolocka consultas que usted sabe absolutamente que son asuntos simples y directos de solo lectura nunca parece generar problemas ... Siempre y cuando sepa lo que está haciendo.

Una alternativa al READ UNCOMMITTEDnivel que puede considerar es el READ COMMITTED SNAPSHOT. Citando a Jeff nuevamente:

Las instantáneas se basan en un método de seguimiento de cambio de datos completamente nuevo ... más que un simple cambio lógico, requiere que el servidor maneje los datos físicamente de manera diferente. Una vez que este nuevo método de seguimiento de cambio de datos está habilitado, crea una copia o una instantánea de cada cambio de datos. Al leer estas instantáneas en lugar de datos en vivo en momentos de contención, ya no se necesitan bloqueos compartidos en las lecturas, y el rendimiento general de la base de datos puede aumentar.

Esto puede ser útil para ver el progreso de las consultas de inserción largas, hacer estimaciones aproximadas (como COUNT(*)o aproximadas SUM(*)), etc.

En otras palabras, los resultados que devuelven las consultas de lectura sucia están bien siempre que los trate como estimaciones y no tome decisiones críticas basadas en ellos.

Mi caso de uso favorito read uncommitedes para depurar algo que sucede dentro de una transacción.

Inicie su software bajo un depurador, mientras recorre las líneas de código, abre una transacción y modifica su base de datos. Mientras se detiene el código, puede abrir un analizador de consultas, establecerlo en el nivel de aislamiento de lectura no comprometida y realizar consultas para ver qué está sucediendo.

También puede usarlo para ver si los procedimientos de ejecución prolongada están bloqueados o actualizan correctamente su base de datos.

Es excelente si a su empresa le encanta realizar procedimientos almacenados demasiado complejos.

La ventaja es que puede ser más rápido en algunas situaciones. La desventaja es que el resultado puede ser incorrecto (los datos que aún no se han confirmado podrían devolverse) y no hay garantía de que el resultado sea repetible.

Si te importa la precisión, no uses esto.

Más información está en MSDN :

Implementa la lectura sucia o el bloqueo de nivel 0 de aislamiento, lo que significa que no se emiten bloqueos compartidos y no se respetan bloqueos exclusivos. Cuando se establece esta opción, es posible leer datos no confirmados o sucios; los valores en los datos se pueden cambiar y las filas pueden aparecer o desaparecer en el conjunto de datos antes del final de la transacción. Esta opción tiene el mismo efecto que establecer NOLOCK en todas las tablas en todas las instrucciones SELECT en una transacción. Este es el menos restrictivo de los cuatro niveles de aislamiento.

¿Cuándo está bien usar READ UNCOMMITTED?

Regla de oro

Bueno : grandes informes agregados que muestran totales en constante cambio.

Arriesgado : Casi todo lo demás.

La buena noticia es que la mayoría de los informes de solo lectura entran en esa categoría Buena .

Mas detalle...

Ok para usarlo:

• Casi todos los informes agregados orientados al usuario para datos actuales y no estáticos, por ejemplo, ventas hasta la fecha. Se corre el riesgo de un margen de error (tal vez <0.1%) que es mucho más bajo que otros factores de incertidumbre como el error de entrada o simplemente la aleatoriedad de cuándo se registran exactamente los datos minuto a minuto.

Eso cubre probablemente la mayoría de lo que haría un departamento de Business Intelligence en, por ejemplo, SSRS. La excepción, por supuesto, es cualquier cosa con signos $ delante. Muchas personas representan el dinero con mucho más celo que el aplicado a las métricas centrales relacionadas requeridas para atender al cliente y generar ese dinero. (Culpo a los contadores).

Cuando arriesgado

• Cualquier informe que baje al nivel de detalle. Si se requiere ese detalle, generalmente implica que cada fila será relevante para una decisión. De hecho, si no puede extraer un pequeño subconjunto sin bloquearlo, podría ser por la buena razón de que se está editando actualmente.

• Información histórica. Rara vez hace una diferencia práctica, pero mientras que los usuarios entienden que los datos que cambian constantemente no pueden ser perfectos, no sienten lo mismo sobre los datos estáticos. Las lecturas sucias no duelen aquí, pero las lecturas dobles pueden ocasionalmente serlo. Dado que de todos modos no debería tener bloques en los datos estáticos, ¿por qué arriesgarse?

• Casi todo lo que alimenta una aplicación que también tiene capacidades de escritura.

Cuando incluso el escenario OK no está bien.

• ¿Hay aplicaciones o procesos de actualización que utilicen grandes transacciones individuales? ¿Los que eliminan y luego vuelven a insertar muchos registros sobre los que informa? En ese caso, realmente no se puede usar NOLOCKen esas tablas para nada.

Con respecto a los informes, lo usamos en todas nuestras consultas de informes para evitar que una consulta empañe las bases de datos. Podemos hacerlo porque estamos obteniendo datos históricos, no datos de hasta el microsegundo.

Use READ_UNCOMMITTED en una situación en la que es poco probable que cambie la fuente.

• Al leer datos históricos. por ejemplo, algunos registros de implementación que ocurrieron hace dos días.
• Al leer metadatos nuevamente. por ejemplo, aplicación basada en metadatos.

No use READ_UNCOMMITTED cuando sepa que la fuente puede cambiar durante la operación de recuperación.

Esto le dará lecturas sucias y le mostrará transacciones que aún no se han confirmado. Esa es la respuesta más obvia. No creo que sea una buena idea usar esto solo para acelerar sus lecturas. Hay otras formas de hacerlo si utiliza un buen diseño de base de datos.

También es interesante notar lo que no está sucediendo. READ UNCOMMITTED no solo ignora otros bloqueos de tabla. Tampoco está causando ningún bloqueo en sí mismo.

Considere que está generando un informe grande o está migrando datos de su base de datos utilizando una instrucción SELECT grande y posiblemente compleja. Esto provocará un bloqueo compartido que se puede escalar a un bloqueo de tabla compartido durante la duración de su transacción. Se pueden leer otras transacciones de la tabla, pero las actualizaciones son imposibles. Esta puede ser una mala idea si se trata de una base de datos de producción, ya que la producción puede detenerse por completo.

Si está utilizando LEER NO COMPROMETIDO, no establecerá un bloqueo compartido en la tabla. Puede obtener el resultado de algunas transacciones nuevas o puede no depender de dónde se insertaron los datos de la tabla y cuánto tiempo ha leído su transacción SELECT. También puede obtener los mismos datos dos veces si, por ejemplo, se produce una división de página (los datos se copiarán a otra ubicación en el archivo de datos).

Por lo tanto, si es muy importante para usted que los datos se puedan insertar mientras realiza su SELECCIÓN, LEER NO COMPROMETIDO puede tener sentido. Debe tener en cuenta que su informe puede contener algunos errores, pero si se basa en millones de filas y solo unas pocas se actualizan al seleccionar el resultado, esto puede ser "lo suficientemente bueno". Su transacción también puede fallar en conjunto, ya que la unicidad de una fila puede no estar garantizada.

Una mejor manera puede ser usar el NIVEL DE AISLAMIENTO INSTANTÁNEO, pero sus aplicaciones pueden necesitar algunos ajustes para usarlo. Un ejemplo de esto es si su aplicación toma un bloqueo exclusivo en una fila para evitar que otros lo lean y entren en modo de edición en la interfaz de usuario. El NIVEL DE AISLAMIENTO SNAPSHOT también viene con una considerable penalización de rendimiento (especialmente en el disco). Pero puede superar eso arrojando hardware sobre el problema. :)

También puede considerar restaurar una copia de seguridad de la base de datos para usarla para informar o cargar datos en un almacén de datos.

Se puede usar para una tabla simple, por ejemplo, en una tabla de auditoría de solo inserción, donde no hay actualización en la fila existente y no hay fk en otra tabla. El inserto es un inserto simple, que tiene poca o ninguna posibilidad de reversión.

Siempre uso READ UNCOMMITTED ahora. Es rápido con los menores problemas. Cuando use otros aislamientos, casi siempre encontrará algunos problemas de bloqueo.

Siempre que use los campos de Incremento automático y preste un poco más de atención a las inserciones, entonces está bien, y puede despedirse de los problemas de bloqueo.

Puede cometer errores con READ UNCOMMITED pero, para ser honesto, es muy fácil asegurarse de que sus insertos sean una prueba completa. Las inserciones / actualizaciones que utilizan los resultados de una selección son lo único que debe tener en cuenta. (Use READ COMMITTED aquí, o asegúrese de que las lecturas sucias no causen problemas)

Así que vaya a las lecturas sucias (especialmente para grandes informes), su software se ejecutará sin problemas ...