Respuestas:
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 conread 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
nolockcomo 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.
READ UNCOMMITTEDTambién puede hacer que leas filas dos veces o que te pierdas filas enteras . Si se produce una división de página mientras está leyendo, puede perder fragmentos enteros de datos. WITH(NOLOCK)solo debe usarse si la precisión de los resultados no es importante
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.
selectdeclaraciones no tendrían que esperar para adquirir bloqueos compartidos en los recursos que están bloqueados exclusivamente por otras transacciones.
¿Cuándo está bien usar READ UNCOMMITTED?
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 .
Ok para usarlo:
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.
NOLOCKen esas tablas para nada.read uncommittedpara aplicaciones web cuando el usuario ve alguna cuadrícula de interfaz de usuario donde la precisión de los datos no es tan importante. El usuario solo quiere una descripción rápida de los registros que podrían estar allí, y tal vez con algo de paginación, clasificación y filtrado. Solo cuando el usuario hace clic en el botón Editar, intento leer el registro más reciente con un nivel de aislamiento más estricto. ¿No debería ser mejor este enfoque en términos de rendimiento?
select item from things with (UPDLOCK). Ponga un tiempo de espera rápido allí para que si no puede adquirir el bloqueo rápidamente, le diga al usuario que está siendo editado. Eso lo mantendrá a salvo no solo de los usuarios sino también de los desarrolladores. El único problema aquí es que debes comenzar a pensar en los tiempos de espera y en cómo manejarlos en la interfaz de usuario.
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.
No use READ_UNCOMMITTED cuando sepa que la fuente puede cambiar durante la operación de recuperación.
READ UNCOMMITTED.
READ UNCOMMITTEDmayoría de las situaciones en las que sus datos se utilizan activamente y desea reducir la carga en el servidor para evitar posibles puntos muertos y reversiones de transacciones solo porque algunos usuarios abusaron descuidadamente " Actualizar "en una página web con una cuadrícula de datos. Los usuarios que ven un montón de registros al mismo tiempo, generalmente no les importa mucho si los datos están un poco desactualizados o parcialmente actualizados. Solo cuando un usuario está a punto de editar un registro, es posible que desee proporcionarle los datos más precisos.
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.
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 ...
Committedpor inserciones y actualizaciones. En cuanto a otros problemas, también demostró conocimiento de los problemas de división de página al mencionar el uso de una clave de incremento automático. Estoy de acuerdo con él en que casi todos los informes en vivo hechos para ser leídos por un humano pueden tolerar ligeras discrepancias en el último decimal. Estoy de acuerdo en que es una historia diferente para listados detallados o datos destinados a ser leídos y transformados a máquina, y Clive también.