Aislamiento (sistemas de base de datos)

Ir a: navegación, búsqueda de

En base de datos sistemas, aislamiento determina cómo es visible para otros usuarios y sistemas de integridad de la transacción. Por ejemplo, cuando un usuario crea una orden de compra y ha creado el encabezado, pero no las líneas PO, está disponible para otros sistemas y usuarios, llevar a cabo la cabecera concurrente ¿operaciones (por ejemplo, un informe sobre las órdenes de compra), a ver?

Un nivel de aislamiento bajo aumenta la capacidad de muchos usuarios de acceder a los datos al mismo tiempo, pero aumenta el número de concurrencia podrían tropezar con usuarios de efectos (como Lee sucio o actualizaciones perdidas). Por el contrario, un mayor nivel de aislamiento reduce los tipos de efectos de la concurrencia que los usuarios pueden encontrar, pero requiere más recursos del sistema y aumenta las probabilidades de que una transacción bloqueará otra.[1]

Normalmente se define a nivel de base de datos como una propiedad que define cómo/cuando los cambios realizados por una sola operación que se hacen visible al otro, pero en sistemas antiguos podrán aplicarse sistemáticamente, por ejemplo mediante el uso de tablas temporales. En sistemas de dos niveles, un gestor de TP es necesaria para mantener el aislamiento. En los sistemas de n-capas (como tratar de reservar el último asiento en un vuelo de múltiples sitios web) es necesaria una combinación de procedimientos almacenados y administración de transacciones para cometer la reserva y confirmar al cliente.[2]

El aislamiento es uno de los ÁCIDO (Atomicidad, coherencia, aislamiento, durabilidad) propiedades.

Contenido

  • 1 Control de concurrencia
  • 2 Niveles de aislamiento
    • 2.1 Serializable
    • 2.2 Lecturas repetibles
    • 2.3 Lectura comprometida
    • 2.4 Read uncommitted
  • 3 Nivel de aislamiento predeterminado
  • 4 Leer los fenómenos
    • 4.1 Lee sucio
    • 4.2 Lecturas no repetibles
    • 4.3 Fantasma Lee
  • 5 Niveles de aislamiento, fenómenos de lectura y cerraduras
    • 5.1 Niveles de aislamiento vs leer fenómenos
    • 5.2 Niveles de aislamiento vs bloqueo duración
  • 6 Véase también
  • 7 Referencias
  • 8 Enlaces externos

Control de concurrencia

Control de concurrencia comprende los mecanismos subyacentes en un DBMS que encarga de aislamiento y garantiza la corrección relacionado. Es muy utilizado por las base de datos y almacenamiento de motores (véase arriba) tanto para garantizar la correcta ejecución de transacciones concurrentes y (mecanismos diferentes) la corrección de otros procesos DBMS. Los mecanismos de transacción típicamente restringen (sincronización) de operaciones de acceso a datos de base de datoshorarios de transacción) a ciertas órdenes caracterizados como el serializabilidad y capacidad de recuperación propiedades del calendario. Restricción de ejecución de la operación de acceso de base de datos normalmente significa menor rendimiento (tasas de ejecución), y así los mecanismos de control de concurrencia están diseñados para proporcionar el mejor rendimiento posible bajo las restricciones. A menudo, cuando sea posible sin dañar la corrección, la propiedad serializabilidad está comprometida para un mejor rendimiento. Sin embargo, la capacidad de recuperación no puede ser comprometida, puesto que tales resultados típicamente en una violación de la integridad de base de datos rápida.

Bloqueo de dos fases es el método más común de control de concurrencia transacción a bases de datos, utilizado para proporcionar tanto serializabilidad y capacidad de recuperación para la corrección. Para poder acceder a un objeto de base de datos una transacción primero necesita adquirir un cerradura para este objeto. Dependiendo del tipo de operación de acceso (por ejemplo, lectura o escritura de un objeto) y el tipo de bloqueo, adquiriendo la cerradura puede bloqueado y pospuesto, si otra transacción tiene una cerradura para ese objeto.

Niveles de aislamiento

De los cuatro ÁCIDO propiedades en una DBMS (Database Management System), la propiedad de aislamiento es el que más a menudo posible relajado. Al intentar mantener el más alto nivel de aislamiento, generalmente adquiere un DBMS cerraduras en datos o implementos control de concurrencia multiversión, que puede resultar en una pérdida de simultaneidad. Esto requiere añadir lógica para el aplicación para funcionar correctamente.

La mayoría de bases de datos ofrecen una serie de niveles de aislamiento de transacción, que controlan el grado de bloqueo que se produce cuando se selecciona datos. Para muchas aplicaciones de base de datos, la mayoría de las transacciones de la base de datos puede ser construida para evitar que requieren aislamiento altos niveles (e.g. SERIALIZABLE), reduciendo así la fijación sobrecarga para el sistema. El programador debe analizar cuidadosamente código de acceso de base de datos para asegurar que cualquier relajación de aislamiento no causa errores de software que son difíciles de encontrar. Por el contrario, si se utilizan los niveles más altos de aislamiento, la posibilidad de interbloqueo se incrementa, lo cual también requiere análisis cuidadoso y técnicas de programación para evitar.

Los niveles de aislamiento definidos por el ANSI/ISO SQL estándar son las siguientes.

Serializable

Este es el más alto nivel de aislamiento.

Con un bloqueo basado en control de concurrencia Implementación de DBMS, serializabilidad requiere leer y escribir cerraduras (adquirida en datos seleccionados) ser lanzado a finales de la transacción. También gama de cerraduras deben adquirirse cuando un SELECCIONE consulta utiliza una distancia DONDE cláusula, especialmente para evitar la fantasma Lee fenómeno (véase abajo).

Cuando utilizando sin bloqueo basado en control de concurrencia, no se adquieren cerraduras; Sin embargo, si el sistema detecta un escribir colisión entre varias transacciones concurrentes, sólo uno de ellos puede cometer. Ver aislamiento de instantánea para obtener más detalles sobre este tema.

Lecturas repetibles

En este nivel de aislamiento, basada en una cerradura control de concurrencia DBMS aplicación mantiene Lee y escribe las cerraduras (adquiridas en datos seleccionados) hasta el final de la transacción. Sin embargo, gama de cerraduras No se logró, así que fantasma Lee puede ocurrir.

Lectura comprometida

En este nivel de aislamiento, basada en una cerradura control de concurrencia Implementación de DBMS mantiene en escribe las cerraduras (adquiridas en datos seleccionados) hasta el final de la transacción, pero Lee las cerraduras son liberados tan pronto como el SELECCIONE la operación se realiza (el lecturas no repetibles fenómeno puede ocurrir en este nivel de aislamiento, como se explica más abajo). Como en el nivel anterior, gama de cerraduras No se logró.

Ponerlo en palabras más simples, leer comprometido es un nivel de aislamiento que garantiza que cualquier lectura de datos se ha comprometido en este momento se lee. Simplemente restringe el lector de ver cualquier lectura intermedia, no comprometido, 'sucio'. No hace ninguna promesa alguna si la transacción emite la lectura, encontrará los mismos datos; datos están libres de cambiar después de que se lee.

Read uncommitted

Este es el más bajo nivel de aislamiento. En este nivel, Lee sucio se permite, por una sola transacción puede ocurrir No-todavía-confiado cambios realizados por otras transacciones.

Puesto que cada nivel de aislamiento es más fuerte que los menores, que no hay mayor nivel de aislamiento permite una acción prohibida por una baja, la norma permite un DBMS para ejecutar una transacción en un nivel de aislamiento más fuerte que la solicitada (por ejemplo, una transacción "Leer comprometidos" puede en realidad realizar en un nivel de aislamiento "Repeatable leer").

Nivel de aislamiento predeterminado

El nivel de aislamiento predeterminado de diferentes DBMSde varía bastante. Más bases de datos que presentan las transacciones permiten al usuario establecer algún nivel de aislamiento. Algunos DBMS también requieren sintaxis adicional cuando se realiza una instrucción SELECT para adquirir las cerraduras (ej.: SELECCIONE... PARA LA ACTUALIZACIÓN para adquirir bloqueos de escritura exclusiva en filas accesada).

Sin embargo, las definiciones anteriores han sido criticadas [3] como ambiguo y no precisa que refleja el aislamiento proporcionado por muchas bases de datos:

Este artículo presenta una serie de debilidades en el enfoque de la anomalía a la definición de los niveles de aislamiento. Los tres fenómenos de ANSI son ambiguos. Incluso sus interpretaciones más amplios no excluyen comportamiento anómalo. Esto conduce a unos resultados contraintuitivos. En particular, los niveles de aislamiento basadas en la cerradura tienen diferentes características que sus equivalentes de ANSI. Esto es desconcertante porque sistemas de base de datos comercial típicamente utilizan bloqueos. Además, los fenómenos de ANSI no distinguen entre varios niveles de aislamiento populares en sistemas comerciales.

También hay otras críticas relativas a la determinación del aislamiento de ANSI SQL, en eso anima a implementadores hacer "cosas malas":

... se basa en formas sutiles en la suposición de que un esquema de bloqueo se utiliza para el control de concurrencia, en contraposición a un esquema de concurrencia optimista o varias versiones. Esto implica que la semántica propuesta son mal definidas. [4]

Leer los fenómenos

El estándar ANSI/ISO SQL 92 se refiere a tres diferentes leer los fenómenos Cuando 1 transacción lee datos que podría haber cambiado la transacción 2.

En los ejemplos siguientes, dos transacciones ocurren. En el primero, se realiza la consulta 1. Entonces, en la segunda transacción, 2 consulta es realizada y comprometida. Finalmente, en la primera transacción, 1 consulta se realiza otra vez.

Las consultas utilizan la siguiente tabla de datos:

usuarios
id nombre edad
1 Joe 20
2 Jill 25

Lee sucio

A lectura sucia (aka dependencia no comprometido) se produce cuando una transacción puede leer datos de una fila que ha sido modificada por otra transacción corriente y no comprometidos.

Lee sucio del trabajo del mismo modo lecturas no repetibles; Sin embargo, la segunda operación no tendría que estar comprometidos para la primera consulta devolver un resultado diferente. La única cosa que puede evitarse en el nivel de aislamiento READ UNCOMMITTED es las actualizaciones que aparecen fuera de lugar en los resultados; es decir, versiones anteriores siempre aparecerán en un resultado antes de las actualizaciones posteriores.

En nuestro ejemplo, transacción 2 cambia una fila, pero no obliga a los cambios. Transacción 1 Entonces lee los datos no confirmados. Ahora si 2 transacción retrocede sus cambios (leídos por transacción 1) o actualiza diversos cambios a la base de datos, entonces la vista de los datos puede ser erróneos en los registros de transacción 1.

Transacción 1 Transacción 2
/ * Consulta 1 * /
SELECCIONE edad De usuarios DONDE ID = 1;
/ * leerá 20 * /
/ * Consulta 2 * /
ACTUALIZACIÓN usuarios CONJUNTO edad = 21 DONDE ID = 1;
/ * No cometer aquí * /
/ * Consulta 1 * /
SELECCIONE edad De usuarios DONDE ID = 1;
/ * leerá 21 * /
ROLLBACK; / * LEER sucia basada en cerradura * /

Pero en este caso no hay fila existe, que tiene un id de 1 y una edad de 21 años.

Lecturas no repetibles

A leer no repetibles se produce, cuando durante el transcurso de una transacción, se recupera una fila dos veces y los valores dentro de la fila difieren entre lecturas.

Lecturas no repetibles fenómeno puede ocurrir en un método de control de simultaneidad basado en la cerradura cuando leyó las cerraduras no se adquieren cuando se realiza un SELECCIONE, o cuando se liberan los bloqueos adquiridos en filas afectadas tan pronto como se realiza la operación de selección. Bajo el control de concurrencia multiversión método, lecturas no repetibles puede ocurrir cuando el requisito de que una transacción afectada por un conflicto de cometer debe rodar detrás es relajado.

Transacción 1 Transacción 2
/ * Consulta 1 * /
SELECCIONE * De usuarios DONDE ID = 1;
/ * Consulta 2 * /
ACTUALIZACIÓN usuarios CONJUNTO edad = 21 DONDE ID = 1;
COMMIT; / * control de concurrencia multiversión, o basados en bloqueo READ COMMITTED * /
/ * Consulta 1 * /
SELECCIONE * De usuarios DONDE ID = 1;
COMMIT; / * base de bloqueo REPEATABLE READ * /

En este ejemplo, transacción 2 se compromete con éxito, lo que significa que sus cambios a la fila con id 1 deberían ser visibles. Sin embargo, la transacción 1 ya ha visto un valor diferente para edad en esa fila. En los niveles de aislamiento SERIALIZABLE y REPEATABLE READ, el DBMS debe devolver el valor anterior para el segundo SELECT. En READ COMMITTED and READ UNCOMMITTED, el DBMS puede devolver el valor actualizado; Esto es una lectura no repetibles.

Hay dos estrategias básicas utilizadas para evitar lecturas no repetibles. La primera consiste en retrasar la ejecución de transacciones 2 hasta 1 transacción ha cometido o deshace. Este método se utiliza cuando el bloqueo se utiliza y produce la serie horario T1, T2. Exhibe una programación serial lecturas repetibles comportamiento.

En la otra estrategia, como se utiliza en control de concurrencia multiversión, Transacción 2 está permitido cometer en primer lugar, que preve mejor concurrencia. Sin embargo, debe continuar 1 transacción, que se inició antes de la operación 2 operar sobre una última versión de la base de datos — una instantánea del momento que se inició. Cuando finalmente 1 transacción intenta cometer, el DBMS comprueba si el resultado de cometer 1 transacción sería equivalente a la agenda T1, T2. Si lo es, entonces puede proceder 1 transacción. Si no puede ser visto para ser equivalente, sin embargo, 1 transacción debe hacer retroceder con un error de serialización.

Utilizando un método de control de simultaneidad basado en la cerradura, en el modo de aislamiento REPEATABLE READ, de la fila con ID = 1 estaría encerrado, bloqueando así consulta 2 hasta que la primera transacción fue comprometida o se deshacen. En modo READ COMMITTED, la segunda vez que fue ejecutado 1 consulta, habría cambiado de la edad.

Bajo control de concurrencia multiversión, en el nivel de aislamiento SERIALIZABLE, ambas consultas SELECT ver una instantánea de la base de datos tomada al comienzo de la operación 1. Por lo tanto, vuelven los mismos datos. Sin embargo, si 1 transacción luego intentó actualizar esa fila así, podría producirse un error de serialización y 1 transacción se verían obligados a retroceder.

En el nivel de aislamiento READ COMMITTED, cada consulta ve una instantánea de la base de datos tomada al comienzo de cada consulta. Por lo tanto, cada uno de ellos ve datos diferentes para la fila actualizada. Ninguna falta de serialización es posible en este modo (porque ninguna promesa de serializabilidad es hecha), y 1 transacción no tendrá que volver a intentar.

Fantasma Lee

A lectura fantasma se produce cuando, en el transcurso de una transacción, se ejecutan dos consultas idénticas, y la colección de filas devueltas por la segunda consulta es diferente desde el principio.

Esto puede ocurrir cuando cerraduras de gama No son adquiridos sobre la realización de un SELECCIONE ... DONDE operación. El fantasma Lee la anomalía es un caso especial de Lecturas no repetibles Cuando la transacción 1 repite una distancia SELECCIONE... DONDE consulta y, entre ambas operaciones, transacción 2 (es decir, crea INSERTAR) nuevas filas (en la tabla de destino) que satisfacen que DONDE cláusula.

Transacción 1 Transacción 2
/ * Consulta 1 * /
SELECCIONE * De usuarios
DONDE edad ENTRE 10 Y 30;
/ * Consulta 2 * /
INSERTAR EN usuarios VALORES ( 3, 'Bob', 27 );
COMMIT;
/ * Consulta 1 * /
SELECCIONE * De usuarios
DONDE edad ENTRE 10 Y 30;
COMMIT;

Tenga en cuenta que 1 transacción ejecutado dos veces la misma consulta. Si se mantiene el más alto nivel de aislamiento, debe devolverse el mismo conjunto de filas de ambos tiempos, y hecho es cuál es el mandato que se produzca en una base de datos de funcionamiento en el nivel de aislamiento SERIALIZABLE de SQL. Sin embargo, en los niveles de aislamiento menor, un conjunto de filas diferentes puede ser devueltos el segundo tiempo.

En el modo de aislamiento SERIALIZABLE, consulta 1 resultaría en todos los registros con la edad en el rango de 10 a 30 estar encerrado, así bloquearía consulta 2 hasta que la primera transacción se cometió. En el modo REPEATABLE READ, la gama estaría no encerrada, lo que permite el registro a insertarse y la segunda ejecución de 1 consulta para incluir la nueva fila en sus resultados.

Niveles de aislamiento, fenómenos de lectura y cerraduras

Niveles de aislamiento vs leer fenómenos

Nivel de aislamiento Lee sucio Lecturas no repetibles Fantasmas
Read Uncommitted puede ocurrir puede ocurrir puede ocurrir
Lectura comprometida - puede ocurrir puede ocurrir
REPEATABLE Read - - puede ocurrir
Serializable - - -

Anomalía Serializable no es lo mismo como Serializable. Es decir, es necesario, pero no es suficiente que un horario Serializable debe estar libre de todo tipo de tres fenómenos. Consulte a continuación [1].

"puede ocurrir" significa que el nivel de aislamiento sufre ese fenómeno, mientras que "-" significa que no lo sufren.

Niveles de aislamiento vs bloqueo duración

[citación necesitada]

En control de concurrencia basados en bloqueo, nivel de aislamiento determina la duración que se llevan a cabo bloqueos.
"C" -Denota que las cerraduras se llevan a cabo hasta que la transacción se compromete.
"S" -Denota que las cerraduras se realizan sólo durante la declaración está ejecuta actualmente. Tenga en cuenta que si los bloqueos son liberados después de una declaración, los datos subyacentes podrían cambiarse por otra transacción antes de la actual operación confía, creando así una violación.

Nivel de aislamiento Operación de escritura Operación de lectura Rango de operación (... donde...)
Read Uncommitted S S S
Lectura comprometida C S S
REPEATABLE Read C C S
Serializable C C C

Véase también

  • Atomicidad
  • Consistencia
  • Durabilidad
  • Cerradura (base de datos)
  • Control de concurrencia optimista
  • Sistema de gestión de base de datos relacional
  • Aislamiento de instantánea

Referencias

  1. ^ "Los niveles de aislamiento en el motor de base de datos", Technet, Microsoft, http://technet.Microsoft.com/en-us/library/ms189122 (v=SQL.105).aspx
  2. ^ "La arquitectura de sistemas de procesamiento de transacciones", capítulo 23, evolución de los sistemas de procesamiento, Departamento de Ciencias de la computación, Universidad de Stony Brook, obtenido el 20 de marzo de 2014, http://www.cs.sunysb.edu/~Liu/cse315/23.pdf
  3. ^ "Una crítica de los niveles de aislamiento de SQL ANSI". 29 de julio 2012.
  4. ^ Salesforce (2010-12-06). "Testimonios de clientes (SimpleGeo, CLOUDSTOCK 2010)". www.DataStax.com: DataStax. 2010-03-09. (véase arriba en unos 13:30 minutos de la transmisión por Internet!)

Enlaces externos

  • Conceptos de base de datos Oracle ®, Capítulo 13 datos de simultaneidad y consistencia, fenómenos evitables y los niveles de aislamiento de transacción
  • Referencia de SQL de base de datos Oracle ®, las sentencias SQL capítulo 19: SAVEPOINT para actualización, SET TRANSACTION
  • en JDBC: Campos constantes conexión, Connection.getTransactionIsolation(), Connection.setTransactionIsolation(int)
  • en Spring Framework: @Transactional, Aislamiento

Otras Páginas

Obtenido de"http://en.copro.org/w/index.php?title=isolation _ (database_systems) & oldid = 636176542"