7. Control de la concurrencia

7. Control de la concurrencia
Objetivos Conocer la problemática asociada a la concurrencia de transacciones en los sistemas de bases de datos Entender el significado de la serializabilidad y su aplicación al control de la concurrencia Comprender algunas técnicas para el control de la concurrencia empleadas por los sistemas gestores de bases de datos Tema 7. Control de la concurrencia

Contenidos 1. Introducción y problemas de la concurrencia 2. Serializabilidad 3. Técnicas de control de la concurrencia 4. Granularidad de datos Tema 7. Control de la concurrencia

Bibliografía [CB 2005] Connolly, T.; Begg C.: Sistemas de bases de datos. 4ª Edición. Pearson Educación. Addison Wesley. (Cap. 20) [EN 2002] Elmasri, R.; Navathe, S.B.: Fundamentos de Sistemas de Bases de Datos. 3ª Edición. Addison-Wesley. (Cap. 19 y 20) [EN 1997] Elmasri, R.; Navathe, S.B.: Sistemas de bases de datos. Conceptos fundamentales. 2ª Edición. Addison-Wesley Iberoamericana. (Cap. 17 y 18) [SKS 2002] Capítulos 15 y 16 Tema 7. Control de la concurrencia

7.1 Introducción… Los sistemas de bases de datos, según el número de usuarios que pueden utilizarlos de forma concurrente, se clasifican en sistemas monousuario y multiusuario Varios usuarios pueden usar un mismo equipo a la vez gracias a la multiprogramación: el computador puede procesar al mismo tiempo varias transacciones Si el equipo tiene varias CPU, es posible el procesamiento simultáneo (paralelo) de transacciones Si sólo hay una CPU, el SO de multiprogramación reparte el tiempo de CPU entre las transacciones: ejecución concurrente intercalada modelo que supondremos Simultáneo = Paralelo Razones para permitir la concurrencia: Aumentar la productividad: número de transacciones ejecutadas por minuto. Aumentar la utilización de la CPU (menos tiempo ociosa) y Control del disco. Reducir el tiempo medio de respuesta de transacciones (las ‘pequeñas’ no esperan a las ‘grandes’). Tema 7. Control de la concurrencia

7.1 Introducción… Varias transacciones introducidas por usuarios, que se ejecutan de manera concurrente, pueden leer/modificar los mismos elementos almacenados en la base de datos Razones para permitir la concurrencia: Aumentar la productividad: número de transacciones ejecutadas por minuto. Aumentar la utilización de la CPU (menos tiempo ociosa) y Control del disco. Reducir el tiempo medio de respuesta de transacciones (las ‘pequeñas’ no esperan a las ‘grandes’). Simultáneo = Paralelo Razones para permitir la concurrencia: Aumentar la productividad: número de transacciones ejecutadas por minuto. Aumentar la utilización de la CPU (menos tiempo ociosa) y Control del disco. Reducir el tiempo medio de respuesta de transacciones (las ‘pequeñas’ no esperan a las ‘grandes’). Tema 7. Control de la concurrencia

7.1 … y problemas de la concurrencia
¿Por qué es necesario el control de la concurrencia? ... porque pueden surgir problemas si las transacciones concurrentes se ejecutan de manera no controlada Ejemplo sencillo: sistema de bases de datos que permite hacer y anular reservas de plazas en vuelos de diferentes compañías aéreas. Se almacena un registro por cada vuelo, que incluye, entre otras cosas, el número de asientos reservados en el vuelo Sean dos transacciones T1 y T2 concurrentes: T1 transfiere N reservas realizadas en un vuelo X a otro vuelo Y T2 reserva M plazas en el vuelo X En este sistema de bases de datos, un programa para la reserva (o cancelación) de plazas en ciertos vuelos tendrá como parámetros de entrada los siguientes: número de los vuelos, sus fechas y el número de plazas que reservar (o cancelar). Así que un mismo programa puede usarse para ejecutar muchas transacciones: la ejecución específica de un programa  transacción. Tema 7. Control de la concurrencia

Problemas potenciales provocados por la concurrencia Transacción T1 leer_elemento(X); X:= X-N; escribir_elemento(X); leer_elemento(Y); Y:=Y+N; escribir_elemento(Y); Transacción T2 leer_elemento(X); X:= X+M; escribir_elemento(X); Aunque las transacciones pueden ser perfectamente correctas en sí mismas, la ejecución concurrente de T1 y T2 puede producir un resultado incorrecto, debido a la intercalación de sus operaciones, poniendo en cuestión la integridad y la coherencia de la base de datos Por ello, es necesario controlar la concurrencia para evitar problemas que veremos a continuación, ilustrados mediante un sencillo ejemplo. ... Los mecanismos de control de la concurrencia y recuperación se ocupan principalmente de las órdenes de acceso a la base de datos incluidas en una transacción. A la vista del código de las transacciones: En este punto es importante recordar cómo accede una transacción T a un elemento de información X: LEER(X), o leer_elemento(X), implica: - localizar el bloque en el que está almacenado X en la BD (si no está ya en el búfer de RAM intermedio) - copiar el bloque en el búfer de memoria RAM intermedio (si no estaba ya allí) - copiar el valor de X en una variable de programa (espacio RAM privado de la transacción T) ESCRIBIR(X), o escribir_elemento(X), supone: - copiar el valor de la variable X (RAM local a T) en el lugar correcto dentro del búfer - transferir el bloque desde el búfer al disco (ya sea de inmediato o en algún momento posterior; el mecanismo de recuperación o el SO se encargarán de ello) Pues bien, consideraremos que, una vez que se escribe un elemento de datos X en el búfer de BD, ya está accesible por el resto de transacciones que se ejecutan de forma concurrente con T (independientemente de que dicho cambio haya sido llevado al disco o no, puesto que al realizar una operación LEER(X) primero se acude a buscar X al búfer –que es global a todas las transacciones– y, si no está allí, entonces se accede a la BD en disco). Tema 7. Control de la concurrencia

Problemas potenciales provocados por la concurrencia La actualización perdida T1 y T2 que acceden a los mismos datos, tienen sus operaciones intercaladas de modo que hacen incorrecto el valor de algún dato T1 leer_elemento(X); X:= X-N; escribir_elemento(X); leer_elemento(Y); Y:=Y+N; escribir_elemento(Y); T2 leer_elemento(X); X:= X+M; escribir_elemento(X); Con el propósito de ilustrar la necesidad de establecer mecanismos de control de los accesos concurrentes a los datos por parte de varias transacciones, se exponen los diferentes problemas que pueden surgir si no se controla la concurrencia. El elemento X tiene un valor incorrecto porque su actualización por T1 se ‘perdió’ (se sobreescribió) Tema 7. Control de la concurrencia

Problemas potenciales provocados por la concurrencia La actualización temporal (o lectura sucia) T1 actualiza un elemento X de la BD y luego falla, pero antes de que se restaure el valor original de X, T2 tiene acceso al «valor temporal» de X T1 leer_elemento(X); X:= X-N; escribir_elemento(X); leer_elemento(Y); … T2 leer_elemento(X); X:= X+M; escribir_elemento(X); En relación con la Actualización temporal, T2 ha leído un dato sucio. Un dato sucio es aquel que ha sido modificado (o creado) por una transacción que todavía no se ha completado ni confirmado. También se le conoce como problema de la dependencia no confirmada. T1 falla y debe devolver a X su antiguo valor; pero mientras, T2 ha leído el valor ‘temporal’ incorrecto de X (dato sucio) Tema 7. Control de la concurrencia

Problemas potenciales provocados por la concurrencia El resumen incorrecto Otra transacción T3 calcula una función agregada de resumen sobre varios registros (suma las plazas reservadas para todos los vuelos), mientras otras transacciones, como T1, actualizan dichos registros: puede que T3 considere unos registros antes de ser actualizados y otros después T1 leer_elemento(X); X:= X-N; escribir_elemento(X); leer_elemento(Y); Y:=Y+N; escribir_elemento(Y); T3 suma:=0; leer_elemento(A); suma:= suma+A; … leer_elemento(X); suma:= suma+X; leer_elemento(Y); suma:= suma+Y; T3 lee X después de restar N, pero lee Y antes de sumar N, así que el resultado es un resumen incorrecto (discrepancia de N) Tema 7. Control de la concurrencia

T4 lee X después de restar N
7.1 … y problemas de la concurrencia Problemas potenciales provocados por la concurrencia La lectura no repetible T4 lee un elemento X dos veces y otra transacción, como T1, modifica dicho X entre las dos lecturas: T4 recibe diferentes valores para el mismo elemento T1 leer_elemento(X); X:= X-N; escribir_elemento(X); leer_elemento(Y); Y:=Y+N; escribir_elemento(Y); T4 leer_elemento(X); … T4 lee X antes de restar N Ejemplo de Lectura no repetible: Durante una transacción de reserva de plazas, un cliente pregunta sobre la disponibilidad de asientos en varios vuelos. Cuando el cliente se decide por un vuelo concreto, antes de completar la reserva, la transacción lee por segunda vez el número de asientos libres de dicho vuelo, que puede haber cambiado si, mientras tanto, alguien reservó plazas en él. T4 lee X después de restar N Tema 7. Control de la concurrencia

7.2 Serializabilidad Motivación
Objetivo de un protocolo de control de concurrencia: Planificar las transacciones de forma que no ocurran interferencias entre ellas, y así evitar la aparición de los problemas mencionados Solución obvia: no permitir intercalación de operaciones de varias transacciones Planificación A T1 leer_elemento(X); X:= X-N; escribir_elemento(X); leer_elemento(Y); Y:=Y+N; escribir_elemento(Y); T2 X:= X+M; Planificación B T1 leer_elemento(X); X:= X-N; escribir_elemento(X); leer_elemento(Y); Y:=Y+N; escribir_elemento(Y); T2 X:= X+M; En general, el número de planes posibles con n transacciones, si no se permite intercalación, es n! (número de permutaciones posibles de n elementos). Tema 7. Control de la concurrencia

Teoría de la Serializabilidad
Motivación Pero el objetivo de un SGBD multiusuario también es maximizar el grado de concurrencia del sistema Si se permite la intercalación de operaciones, existen muchos órdenes posibles de ejecución de las transacciones Planificación C: actualización perdida! T1 leer_elemento(X); X:= X-N; escribir_elemento(X); leer_elemento(Y); Y:=Y+N; escribir_elemento(Y); T2 X:= X+M; Planificación D: correcta! T1 leer_elemento(X); X:= X-N; escribir_elemento(X); leer_elemento(Y); Y:=Y+N; escribir_elemento(Y); T2 X:= X+M; Definiremos ahora el concepto de planificación de transacciones, y presentaremos la serializabilidad como un medio de ayuda para identificar planificaciones correctas, es decir, aquellas que garantizan la consistencia de la base de datos tras su ejecución. ¿Existe algún modo de identificar las ejecuciones que está garantizado que protegen la consistencia de la base de datos? Teoría de la Serializabilidad Tema 7. Control de la concurrencia

7.2 Serializabilidad Planificación de transacciones
Cada transacción comprende una secuencia de operaciones que incluyen acciones de lectura y escritura en la BD, que finaliza con una confirmación (commit) o anulación (rollback) Una planificación P de n transacciones concurrentes T1, T2 ... Tn es una secuencia de las operaciones realizadas por dichas transacciones, sujeta a la restricción de que para cada transacción Ti que participa en P, sus operaciones aparecen en P en el mismo orden en el que ocurren en Ti Nomenclatura: Planificación = Plan Serializabilidad = Seriabilidad = Secuencialidad Planificación Serializable = Planificación Seriable = Planificación Secuenciable Tema 7. Control de la concurrencia

7.2 Serializabilidad Planificación de transacciones
Para el control de la concurrencia (y recuperación de fallos) interesa prestar mayor atención a estas operaciones: Ejemplos de planificaciones de transacciones El subíndice de cada operación indica la transacción que la realiza PA: l1(X) ; e1(X) ; l1(Y) ; e1(Y) ; c1 ; l2(X) ; e2(X) ; c2 ; PB: l2(X) ; e2(X) ; c2 ; l1(X) ; e1(X) ; l1(Y) ; e1(Y) ; c1 ; PC: l1(X) ; l2(X) ; e1(X) ; l1(Y) ; e2(X) ; c2 ; e1(Y) ; c1 ; PD: l1(X) ; e1(X) ; l2(X) ; e2(X) ; c2 ; l1(Y) ; e1(Y) ; c1 ; PE: l1(X) ; e1(X) ; l2(X) ; e2(X) ; c2 ; l1(Y) ; r1 ; operación abreviatura leer_elemento l escribir_elemento e commit c rollback r Las operaciones en una planificación tienen como subíndice un número indicativo de la transacción a la que pertenecen. Por ejemplo, con l2(X) nos referimos a una operación de lectura del elemento X realizado por la transacción T2. Tema 7. Control de la concurrencia

7.2 Serializabilidad Planificación serie
Una planificación serie P es aquella en la que las operaciones de cada transacción se ejecutan consecutivamente sin que se intercalen operaciones de otras transacciones PA: l1(X) ; e1(X) ; l1(Y) ; e1(Y) ; c1 ; l2(X) ; e2(X) ; c2 ; PB: l2(X) ; e2(X) ; c2 ; l1(X) ; e1(X) ; l1(Y) ; e1(Y) ; c1 ; Toda planificación serie es correcta BD consistente Pero no se garantiza que los resultados de todas las ejecuciones en serie de las mismas transacciones sean idénticos Ejemplo: cálculo del interés de una cuenta bancaria antes o después de realizar un ingreso considerable en general, son inaceptables en la práctica (ineficiencia) El razonamiento que nos lleva a afirmar que todo plan en serie es correcto es el siguiente: Toda T es correcta si se ejecuta por sí sola, es decir, sin interferencias de otras transacciones, por la propiedad de Conservación de la Consistencia que dice que una ejecución de una transacción lleva la BD de un estado consistente a otro. Las transacciones son independientes entre sí, es decir, ninguna transacción necesita de otra para poder ejecutarse correctamente. De este modo, no importa qué transacción se ejecute antes que otra. Siempre que toda T se ejecute de principio a fin sin que otras operaciones de otras transacciones se intercalen, se obtendrá un resultado final correcto en la BD. Lo anterior no significa que se obtenga idéntico resultado con cualquier orden de ejecución. Por ejemplo: Si el saldo inicial de una cuenta es 2000€, la transacción T3: «Reintegrar 100€» y T4: «Ingresar los intereses al 2%». Si se ejecutan con un plan T3,T4 entonces saldo= =1900; 2%1900=38; saldo=1938€. Si se ejecutan con un plan T4,T3, entonces 2%2000=40; saldo=2040;saldo= =1940€. Importante: para las transacciones del ejemplo ambos planes en serie (T1,T2) y (T2,T1) dan el mismo resultado final. Pero en general los diferentes planes serie de n transacciones pueden obtener diferentes resultados. Ejemplo: T1 T2 l(Y) l(X) l(X) l(Y) X=X+Y Y=Y+X e(X) e(Y) Si X=20 e Y=30, entonces el plan (T1,T2) obtiene X=50 e Y=80, mientras que (T2,T1) obtiene X=70 e Y=50. Ambos son estados correctos de la base de datos. Las planificaciones serie impiden la concurrencia de las transacciones, por lo que en general resultan inaceptables en la práctica por su ineficiencia: es necesario permitir la intercalación o entrelazado de las operaciones. Tema 7. Control de la concurrencia

Este es el objetivo de la Serializabilidad
Planificación no serie Una planificación no serie P es aquella en la que las operaciones de un conjunto de transacciones concurrentes se ejecutan intercaladas PC: l1(X) ; l2(X) ; e1(X) ; l1(Y) ; e2(X) ; c2 ; e1(Y) ; c1 ; PD: l1(X) ; e1(X) ; l2(X) ; e2(X) ; c2 ; l1(Y) ; e1(Y) ; c1 ; Hemos de determinar qué planificaciones no serie permiten llevar la BD a un estado al que pueda llegarse mediante una ejecución en serie KO La planificación C no es correcta, por el problema de actualización perdida La planificación D sí es correcta Nos interesa, por tanto, saber cómo detectar las planificaciones no serie que SIEMPRE dan un resultado correcto. Este es el objetivo de la Serializabilidad Tema 7. Control de la concurrencia

7.2 Serializabilidad Planificación serializable
Una planificación P (no serie) es serializable si es equivalente a alguna planificación serie de las mismas n transacciones Una planificación que no es equivalente a ninguna ejecución en serie, es una planificación no serializable Toda planificación serializable es correcta Produce los mismos resultados que alguna ejecución en serie Dos maneras de definir la equivalencia entre planificaciones: Equivalencia por conflictos Equivalencia de vistas Una planificación no serie pero serializable es correcta por ser equivalente a una planificación serie (que se considera correcta) Para definir la EQUIVALENCIA entre dos planificaciones, mejor no suponer nada acerca del tipo de operaciones que se ejecutan, sino forzar a que dichas operaciones, sean las que sean, se apliquen en el mismo orden en ambas planificaciones. Pero entonces ¿Cuándo son equivalentes dos planificaciones? Si las operaciones sobre cada elemento de datos se aplican en el mismo orden en ambas Así, el resultado de las dos planificaciones será el mismo La equivalencia por conflictos es la más utilizada. Tema 7. Control de la concurrencia

7.2 Serializabilidad Equivalencia por conflictos
Si dos transacciones únicamente leen un determinado elemento de datos, no entran en conflicto entre sí y el orden de las operaciones no es importante Si hay dos transacciones que leen o escriben elementos de datos independientes, no entran en conflicto entre sí y el orden de las operaciones no es importante Si una de las transacciones escribe un elemento de datos y la otra lee o escribe el mismo elemento, entran en conflicto y el orden de las operaciones sí es importante Introducción… Tema 7. Control de la concurrencia

7.2 Serializabilidad Equivalencia por conflictos
En una planificación, 2 operaciones están en conflicto si pertenecen a diferentes transacciones, tienen acceso al mismo elemento X, y al menos una de ellas es escribir_elemento(X) Operaciones en conflicto en las planificaciones PC y PD: PC: l1(X) ; l2(X) ; e1(X) ; l1(Y) ; e2(X) ; c2 ; e1(Y) ; c1; PD: l1(X) ; e1(X) ; l2(X) ; e2(X) ; c2 ; l1(Y) ; e1(Y) ; c1 ; Dos planes son equivalentes por conflictos si el orden de cualesquiera dos operaciones en conflicto es el mismo en ambos planes Es interesante remarcar que una planificación no serie es correcta si se ejecuta de forma equivalente a ALGUNA planificación serie (a cualquiera de las posibles). Esto está asegurado si el orden de las operaciones en conflicto en la planificación no serie coincide con el orden en que se ejecutarían en alguna planificación serie. Nótese que las operaciones en conflicto entre Ti son las que pueden afectar al resultado pues consisten en escrituras/lecturas de los mismos elementos por parte de transacciones diferentes. Si dos operaciones en conflicto se aplican en orden diferente en dos planificaciones, el efecto de dichas planificaciones puede ser distinto (sobre las transacciones o sobre la BD) así que estas planificaciones NO serían equivalentes por conflictos. Tema 7. Control de la concurrencia

¡Es una planificación serie!
7.2 Serializabilidad Planificación serializable por conflictos Una planificación P es serializable por conflictos si equivale por conflictos a alguna planificación serie S Podremos intercambiar cada dos operaciones de P consecutivas de transacciones distintas y sin conflicto, hasta obtener la planificación serie equivalente PD : l1(X) ; e1(X) ; l2(X) ; e2(X) ; c2 ; l1(Y) ; e1(Y) ; c1 ; PD1: l1(X) ; e1(X) ; l2(X) ; e2(X) ; l1(Y) ; c2 ; e1(Y) ; c1 ; PD2: l1(X) ; e1(X) ; l2(X) ; e2(X) ; l1(Y) ; e1(Y) ; c2 ; c1 ; PD3: l1(X) ; e1(X) ; l2(X) ; e2(X) ; l1(Y) ; e1(Y) ; c1 ; c2 ; PD4: l1(X) ; e1(X) ; l2(X) ; l1(Y) ; e2(X) ; e1(Y) ; c1 ; c2 ; PD5: l1(X) ; e1(X) ; l2(X) ; l1(Y) ; e1(Y) ; e2(X) ; c1 ; c2 ; PD6: l1(X) ; e1(X) ; l2(X) ; l1(Y) ; e1(Y) ; c1 ; e2(X) ; c2 ; PD7: l1(X) ; e1(X) ; l1(Y) ; l2(X) ; e1(Y) ; c1 ; e2(X) ; c2 ; PD8: l1(X) ; e1(X) ; l1(Y) ; e1(Y) ; l2(X) ; c1 ; e2(X) ; c2 ; PD9: l1(X) ; e1(X) ; l1(Y) ; e1(Y) ; c1 ; l2(X) ; e2(X) ; c2 ; La demostración de que un plan no en serie P es equivalente a otro plan en serie S es que podríamos reordenar las operaciones del plan P que no están en conflicto (nótese que éstas son las únicas que podemos ejecutar en cualquier orden) hasta llegar a ponerlas en el mismo orden en que se ejecutan en el plan S. Cada dos operaciones (consecutivas y de distintas transacciones) que no están en conflicto pueden intercambiar su orden, de forma que, poco a poco, se llega a la planificación serie equivalente ¡Es una planificación serie! PD es serializable Tema 7. Control de la concurrencia

7.2 Serializabilidad Ti Tj Tk
Detección de la serializabilidad por conflictos Construcción del grafo de precedencia (o de serialización) Es un grafo dirigido G = ( N, A ) N es un conjunto de nodos y A es un conjunto de aristas dirigidas Algoritmo: Crear un nodo por cada transacción Ti en P Crear una arista Tj Tk si Tk lee el valor de un elemento después de que Tj lo haya escrito Crear una arista Tj Tk si Tk escribe el valor de un elemento después de que Tj lo haya leído Crear una arista Tj Tk si Tk escribe el valor de un elemento después de que Tj lo haya escrito Ti Sólo se consideran las operaciones leer_elemento y escribir_elemento. Si una operación de Tj aparece en la planificación antes que alguna operación en conflicto de Tk, en el grafo aparecerá la arista desde Tj a Tk. El grafo de precedencia es un reflejo (representación gráfica) de los conflictos existentes entre las transacciones. Las aristas dirigidas pueden ir etiquetadas con los nombres de los elementos de información que originan los conflictos. Tj Tk Tema 7. Control de la concurrencia

7.2 Serializabilidad T1 T2 T1 T2 T1 T2 T1 T2
Detección de la serializabilidad por conflictos (y 2) Una arista Tj  Tk indica que Tj debe aparecer antes que Tk en una planificación serie equivalente a P, pues dos operaciones en conflicto aparecen en dicho orden en P Si el grafo contiene un ciclo, P no es serializable por conflictos Un ciclo es una secuencia de aristas C=((Tj Tk), (Tk Tp),... (Ti Tj)) Si no hay ciclos en el grafo, P es serializable Es posible obtener una planificación serie S equivalente a P, mediante una ordenación topológica de los nodos Ordenación (topológica): Siempre que en el grafo haya una arista desde Tj a Tk, significa que Tj deberá aparecer antes que Tk en cualquier planificación serie equivalente. [Según el DRAE: topología. 1. f. Rama de las matemáticas que trata especialmente de la continuidad y de otros conceptos más generales originados de ella, como las propiedades de las figuras con independencia de su tamaño o forma.] En general, puede haber VARIAS planificaciones serie equivalentes a una planificación P serializable. T1 T2 PA T1 T2 PB T1 T2 PC T1 T2 PD Tema 7. Control de la concurrencia

7.2 Serializabilidad Ejemplo de planificación no serializable T1 T2 T3
Transacción T1 leer_elemento(X); escribir_elemento(X); leer_elemento(Y); escribir_elemento(Y); Transacción T2 leer_elemento(Z); leer_elemento(Y); escribir_elemento(Y); leer_elemento(X); escribir_elemento(X); Transacción T3 leer_elemento(Y); leer_elemento(Z); escribir_elemento(Y); escribir_elemento(Z); T1 T2 Y X T3 Y,Z Planificación E T1 leer_elemento(X); escribir_elemento(X); leer_elemento(Y); escribir_elemento(Y); T2 leer_elemento(Z); leer_elemento(Y); escribir_elemento(Y); leer_elemento(X); escribir_elemento(X); T3 leer_elemento(Y); leer_elemento(Z); escribir_elemento(Y); escribir_elemento(Z); No existe ninguna planificación serie equivalente a PE porque existen dos ciclos en el grafo de precedencia T1 → T2 → T1 y T1 → T2 → T3 → T1. Hay dos ciclos: T1→T2→T1 y T1→T2→T3→T1 Tema 7. Control de la concurrencia

La planificación serie equivalente es T3 → T1 → T2
7.2 Serializabilidad Ejemplo de planificación serializable Transacción T1 leer_elemento(X); escribir_elemento(X); leer_elemento(Y); escribir_elemento(Y); Transacción T2 leer_elemento(Z); leer_elemento(Y); escribir_elemento(Y); leer_elemento(X); escribir_elemento(X); Transacción T3 leer_elemento(Y); leer_elemento(Z); escribir_elemento(Y); escribir_elemento(Z); Planificación F T1 leer_elemento(X); escribir_elemento(X); leer_elemento(Y); escribir_elemento(Y); T2 leer_elemento(Z); leer_elemento(Y); escribir_elemento(Y); leer_elemento(X); escribir_elemento(X); T3 leer_elemento(Y); leer_elemento(Z); escribir_elemento(Y); escribir_elemento(Z); T1 T2 X,Y T3 Y,Z Y Existe una planificación serie equivalente a PF porque NO existen ciclos en el grafo de precedencia: T3 → T1 → T2. La planificación serie equivalente es T3 → T1 → T2 Tema 7. Control de la concurrencia

7.2 Serializabilidad Aplicaciones de la serializabilidad
Es el SO el que distribuye los recursos para los procesos, y determina la intercalación de las operaciones de las transacciones concurrentes (ejecutadas como procesos del SO) Planificación P (ordenamiento de las operaciones) Carga del sistema Momento de introducción de las transacciones Prioridades de los procesos ... Planificador de Tareas del SO Parece, pues, que habría que comprobar si P es serializable una vez ejecutadas las transacciones incluidas en P... Ejecución de Transacciones NO SI OK Cancelar el efecto de P reintentar ¿P serializable? [En adelante con el término ‘serializable’ nos referiremos a ‘serializable por conflictos’.] Una planificación serie resulta ineficiente, puesto que no permite la intercalación y el aprovechamiento de la CPU es bajo. Sin embargo, una planificación serializable, además de ser correcta (como un plan en serie) permite la concurrencia, puesto que aprovecha mucho más la CPU, al permitir que una transacción se ejecute mientras otra está realizando operaciones de E/S, por ejemplo. Pero ¿Cómo se puede conseguir que las planificaciones siempre sean serializables? Y es que es el planificador del SO el que distribuye los recursos para los procesos, y determina la intercalación de operaciones de transacciones concurrentes (ejecutadas como procesos del SO). Es realmente complicado saber por anticipado cómo se intercalarán las operaciones dentro de una planificación. Parece, por tanto, que sólo podríamos comprobar o verificar la serializabilidad de una planificación una vez ejecutada ésta… ¡¡enfoque muy poco práctico!! Es necesario encontrar técnicas que garanticen la serializabilidad, sin tener que verificar a posteriori Tema 7. Control de la concurrencia

7.3 Técnicas de control de concurrencia
Métodos basados en la teoría de la serializabilidad, que definen un conjunto de reglas (o protocolo) tal que... si todas las transacciones las cumplen, o el subsistema de control de concurrencia del SGBD las impone (automáticamente) ... se asegura la serializabilidad de toda planificación de transacciones Clasificación Métodos de bloqueo Métodos de marca de tiempo Técnicas de multiversión Métodos optimistas La frase “...todas las transacciones las cumplen” significa que los programadores definen o programan dichas transacciones siguiendo determinadas reglas (normas o protocolo). Las reglas garantizan el aislamiento (no interferencia destructiva) de transacciones concurrentes. [Extractos del Capítulo 20 de [EN 2002] y 18 de [EN 1997] ]: Protocolos basados en Marcas de Tiempo: Una marca de tiempo es un identificador único generado por el sistema para cada transacción Se garantiza que operaciones cualesquiera en conflicto se ejecutarán en el orden de las marcas de tiempo de las transacciones Técnicas de Multiversión Uso de múltiples versiones de los elementos de información (empleado por Oracle, junto con los bloqueos) Protocolos Optimistas Uso del concepto de validación o certificación de una transacción. Comprueban las posibles violaciones de la serializabilidad una vez que las transacciones han terminado, pero antes de que sean confirmadas. [CB 2005, pág. 535] Basados en la premisa de que los conflictos son raros, por lo que se permite que las transacciones continúen de manera no sincronizada y sólo comprueban los conflictos al final, cuando una transacción se confirma. Tema 7. Control de la concurrencia

Métodos de bloqueo Uso de bloqueos para controlar el acceso concurrente a los elementos de datos almacenados en la base de datos Reglas básicas del bloqueo: Bloqueo compartido: si una transacción tiene un bloqueo compartido sobre un elemento de datos, puede leer el elemento, pero no actualizarlo (escribir) Varias transacciones pueden mantener a la vez bloqueos compartidos sobre el mismo elemento Bloqueo exclusivo: si una transacción tiene un bloqueo exclusivo sobre un elemento de datos, puede leer y actualizar (escribir) el elemento Un bloqueo exclusivo proporciona acceso exclusivo al elemento Es la técnica más ampliamente utilizada para garantizar la serializabilidad de las transacciones concurrentes. Una transacción debe reclamar un bloqueo sobre un elemento de datos antes de ejecutar una operación de lectura o escritura en la base de datos. Tema 7. Control de la concurrencia

Métodos de bloqueo Reglas de uso de los bloqueos 1. T debe emitir bloquear_lectura(X) o bloquear_escritura(X) antes de ejecutar una operación leer_elemento(X) 2. T debe emitir bloquear_escritura(X) antes de realizar una operación escribir_elemento(X) en T 3. T debe emitir desbloquear(X) una vez completadas todas las operaciones leer_elemento(X) y escribir_elemento(X) 4. Si T ya posee un bloqueo, compartido o exclusivo, sobre X no emitirá bloquear_lectura(X) ni bloquear_escritura(X) *esta regla puede permitir excepciones: mejora y reducción de bloqueos* 5. T no emitirá desbloquear(X) salvo si posee un bloqueo, compartido o exclusivo, sobre X Estas reglas deben obedecerlas todas las T afectadas, es decir, deben ser codificadas incluyendo las operaciones bloquear_lectura, bloquear_escritura y desbloquear tal y como se describe en las reglas anteriores. El SGBD puede imponer estas reglas. La implementacion consistiría en: 1. Tabla de bloqueos que contiene registros de tres campos (4 si se permite promoción/degradación); un registro por cada elemento bloqueado. 2. Cada registro contiene <nombre-elemento-informacion, bloqueo, numero-lecturas> 3. La tabla de bloqueos sólo debe almacenar los registros correspondientes a los elementos bloqueados. Una vez liberados, desaparece el registro de la tabla. 4. bloqueo puede tomar dos valores, por ejemplo: 1 (bloqueo compartido, para lectura) y 2 (bloqueo exclusivo, para escritura) 5. Cola para cada registro que almacena los identificadores de las T en espera de conseguir X (que está bloqueado en exclusiva) 6. Para permitir la Degradación y Promoción de candados es necesario guardar, para cada registro (correspondiente al elemento de datos X): Transacciones que están leyendo X (si el bloqueo(X)=1, bloqueado para lectura) Transacción (sólo una) que está escribiendo X (si el bloqueo(X)=2, bloqueado para escritura) Tema 7. Control de la concurrencia

Métodos de bloqueo Cuando una transacción T solicita un bloqueo… Si el elemento no ha sido ya bloqueado por otra transacción, se le concede el bloqueo Si el elemento sí está bloqueado, el SGBD determina si la solicitud es compatible con el bloqueo existente: Si se pide un bloqueo compartido sobre un elemento que ya tiene un bloqueo compartido, el bloqueo será concedido a T En otro caso, T debe esperar hasta que se libere el bloqueo existente Una transacción que obtiene un bloqueo lo mantiene hasta que lo libera explícitamente o termina (commit o rollback) Sólo cuando se libera un bloqueo exclusivo los efectos de la escritura serán visibles para las demás transacciones Tema 7. Control de la concurrencia

Métodos de bloqueo Algunos sistemas permiten la mejora (o promoción) y la reducción (o degradación) de bloqueos Aumenta el nivel de concurrencia del sistema Si T emitió bloquear_lectura(X), más tarde puede mejorarlo a bloqueo exclusivo emitiendo bloquear_escritura(X) Si T es la única que tiene un bloqueo compartido sobre X, se le concede la solicitud En otro caso, T debe esperar Si T emitió bloquear_escritura(X), más tarde puede reducirlo a un bloqueo compartido emitiendo bloquear_lectura(X) Así permite que otras transacciones lean X Conversión de bloqueos: mejora o promoción y reducción o degradación de bloqueos. Tema 7. Control de la concurrencia

Métodos de bloqueo El uso de bloqueos para la programación de transacciones no garantiza la serializabilidad de las planificaciones Planificación G T4 bloquear_lectura(Y); leer_elemento(Y); desbloquear(Y); bloquear_escritura(X); leer_elemento(X); X:=X+Y; escribir_elemento(X); desbloquear(X); T5 bloquear_lectura(X); bloquear_escritura(Y); leer_elemento(Y); Y:=X+Y; escribir_elemento(Y); Transacción T4 bloquear_lectura(Y); leer_elemento(Y); desbloquear(Y); bloquear_escritura(X); leer_elemento(X); X:=X+Y; escribir_elemento(X); desbloquear(X); Transacción T5 bloquear_lectura(X); leer_elemento(X); desbloquear(X); bloquear_escritura(Y); leer_elemento(Y); Y:=X+Y; escribir_elemento(Y); desbloquear(Y); Valores iniciales: X=20, Y=30 Resultados de las planificaciones serie: T4→T5: X=50, Y=80 T5→T4: X=70, Y=50 Ejemplo de una planificación no serie y no serializable, a pesar de que usa bloqueos. T4 modifica X usando Y y T5 modifica Y usando el valor de X. Si una lee Y, la otra modifica Y y la 1ª modifica X usando el valor ‘antiguo’ de Y, entonces ocurre el error. Esto sucede porque los elementos Y en T4 y X en T5 se desbloquean antes de tiempo; aunque pueda parecer que esto permite una mayor concurrencia, en realidad permite que las transacciones interfieran entre sí, lo que provoca una pérdida de la atomicidad y el aislamiento. Nota: se puede observar que las dos ejecuciones en serie no dan el mismo resultado, pero ambas son correctas. Resultado de la planificación G: X=50, Y=50 (No serializable!) Tema 7. Control de la concurrencia

Métodos de bloqueo: Bloqueo en dos fases Es necesario seguir un protocolo adicional que indique dónde colocar las operaciones de bloqueo y desbloqueo dentro de las transacciones El más conocido es el Bloqueo en Dos Fases (B2F) Una transacción T sigue el protocolo de bloqueo en dos fases si todas las operaciones de bloqueo preceden a la primera operación de desbloqueo De este modo, podemos ver T dividida en dos fases: Fase de expansión (o crecimiento) T puede adquirir bloqueos T no puede liberar ningún bloqueo Fase de contracción T puede liberar bloqueos existentes T no puede adquirir ningún bloqueo Usar bloqueos no es suficiente para evitar planes incorrectos. Hay que usarlos ‘bien’… El protocolo más conocido, que permite emitir de forma adecuada las operaciones de bloqueo y desbloqueo, es el Protocolo de Bloqueo en Dos Fases (Two-phase locking, 2PL). Tema 7. Control de la concurrencia

Bloqueo en dos fases Si el sistema permite mejorar y reducir bloqueos… La mejora sólo puede tener lugar en la fase de expansión La reducción sólo puede realizarse en la fase de contracción En el código de T, un bloquear_lectura(X) puede aparecer en la fase de contracción de T sólo si reduce un bloqueo exclusivo a uno compartido Transacción T4’ bloquear_lectura(Y); leer_elemento(Y); bloquear_escritura(X); desbloquear(Y); leer_elemento(X); X:=X+Y; escribir_elemento(X); desbloquear(X); Transacción T5’ bloquear_lectura(X); leer_elemento(X); bloquear_escritura(Y); desbloquear(X); leer_elemento(Y); Y:=X+Y; escribir_elemento(Y); desbloquear(Y); Son las mismas transacciones de hace dos diapositivas, pero siguiendo el protocolo de bloqueo en dos fases. Tema 7. Control de la concurrencia

Bloqueo en dos fases Si toda transacción de una planificación sigue el protocolo de bloqueo en dos fases, entonces la planificación es serializable Ventaja Ya no es necesario comprobar la serializabilidad de las planificaciones Inconvenientes El B2F puede limitar el grado de concurrencia en un plan Emplear bloqueos puede provocar problemas de ... Interbloqueo (bloqueo mortal o abrazo mortal) Bloqueo indefinido (o espera indefinida) Al imponer las reglas de bloqueo, también se impone la serializabilidad. El inferior nivel de concurrencia cuando se usa B2F es el precio que hay que pagar por garantizar la serializabilidad de todas las planificaciones, sin tener que examinarlas. Tema 7. Control de la concurrencia

Bloqueo en dos fases conservador o estático T debe bloquear todos los elementos a los que tendrá acceso (lectura o escritura) antes de comenzar a ejecutarse Si no es posible bloquear algún elemento, T no bloqueará ninguno y esperará para reintentarlo más tarde Protocolo libre de interbloqueo Bloqueo en dos fases estricto el más utilizado T no libera ningún bloqueo exclusivo hasta terminar (con COMMIT o ROLLBACK) Ninguna transacción lee o escribe un elemento modificado por T, salvo si T se ha completadoplanificación estricta Puede sufrir interbloqueo (salvo si se combina con B2F conservador) Los protocolos B2F estricto y riguroso aseguran planificaciones estrictas. La definición de una planificación estricta la estudiaremos en el tema siguiente, de Recuperación de Fallos. En una planificación estricta, una transacción T nunca lee/escribe elementos modificados por otras transacciones no completadas (confirmadas/abortadas). Una planificación estricta es una planificación recuperable y sin reversión en cascada. Diferencia entre el B2F conservador y el riguroso: En el B2F conservador, una T ya iniciada ya está en fase de contracción. En el B2F riguroso, una T está en fase de expansión durante toda su ejecución, hasta que libera todos sus bloqueos al finalizar. Bloqueo en dos fases riguroso más restrictivo que el B2F estricto T no libera ningún bloqueo compartido ni exclusivo hasta terminar (con COMMIT o ROLLBACK) planificación estricta Tema 7. Control de la concurrencia

El problema del interbloqueo Situación en la que cada una de dos (o más) transacciones está esperando a que se libere un bloqueo establecido por la otra transacción T6 bloquear_escritura(X); leer_elemento(X); X:=X-10; escribir_elemento(X); bloquear_escritura(Y); [… en espera …] T7 bloquear_escritura(Y); leer_elemento(Y); Y:=Y+100; escribir_elemento(Y); bloquear_escritura(Y); [… en espera …] El SGBD ha de reconocer un interbloqueo y romperlo: Abortar una o más transacciones Se deshacen sus escrituras y se liberan sus bloqueos Así, el resto de transacciones podrá continuar su ejecución Reiniciar automáticamente las transacciones abortadas Bloqueo mortal o Dead Lock. La gestión de interbloqueos resulta transparente al usuario, por ello, el SGBD reinicia automáticamente las transacciones abortadas para romper el interbloqueo. Tema 7. Control de la concurrencia

El problema del interbloqueo Hay 3 técnicas generales para gestionar los interbloqueos Temporizaciones de bloqueos Prevención de interbloqueos Detección de interbloqueos Conviene detectar interbloqueos cuando se sabe que hay poca interferencia entre transacciones, es decir si... Las transacciones son cortas y bloquean pocos elementos, o La carga de transacciones es pequeña En otro caso, conviene usar temporizaciones o técnicas de prevención Es más difícil prevenir que utilizar temporizaciones o que detectarlos y romperlos, por lo que en la práctica los sistemas no suelen emplear las técnicas de prevención En la práctica, se utiliza la detección. No suelen emplearse los protocolos de prevención, por utilizar suposiciones poco realistas o implicar posibles sobrecargas del sistema. Salvo el uso de tiempos predefinidos, que sí resultan más prácticos. A continuación veremos cada uno de estos enfoques con detalle. Tema 7. Control de la concurrencia

Temporizaciones de bloqueos Una transacción que solicita un bloqueo sólo esperará durante un período de tiempo predefinido por el sistema Si no se concede el bloqueo durante ese tiempo, se producirá un ‘fin de temporización’: el SGBD asumirá que la transacción está interbloqueada (aunque puede que no), la abortará y la reiniciará automáticamente Es una solución muy sencilla y práctica Pero puede hacer que sean abortadas y reiniciadas transacciones que en realidad no están en un interbloqueo Tema 7. Control de la concurrencia

Prevención de interbloqueos Ordenar las transacciones usando marcas temporales de transacción MT(T): Identificador único para T Las MT se ordenan según se inician las transacciones La T más antigua tiene la MT(T) menor Sea Tj que intenta bloquear el elemento de datos X , pero X ya está bloqueado por Tk con un candado en conflicto Algoritmo Esperar - Morir si MT(Tj) < MT(Tk) entonces Tj puede esperar si no, se aborta Tj (Tj muere) y se reinicia después con la misma marca de tiempo Una Tj más antigua espera a que termine otra Tk más reciente Una Tj más reciente que solicita un elemento bloqueado por una Tk más antigua, es abortada (muere) y reiniciada Los dos algoritmos fueron propuestos por Rosenkrantz et al., en 1978. Si T1 se inicia antes que T2, entonces MT(T1) < MT(T2). Es análoga a una fecha de nacimiento. El concepto de marca de tiempo es el mismo que el usado en los Protocolos basados en Marcas de Tiempo (OMT Básico, OMT estricto y Regla de Thomas), pero estos usan dicho concepto para ordenar las transacciones, de forma que aun intercalándose, las operaciones en conflicto se ejecuten en el orden específico del (único) plan en serie con iguales marcas de tiempo para las transacciones [EN ]. Aquí se emplea este concepto como complemento al uso de bloqueos (implementando esquemas de espera justos). Tema 7. Control de la concurrencia

Prevención de interbloqueos Algoritmo Herir - Esperar si MT(Tj) < MT(Tk) entonces se aborta Tk (Tj hiere a Tk) y se reinicia después con la misma MT si no, Tj puede esperar Una Tj más reciente espera a que termine una Tk más antigua Una Tj más antigua que solicita un elemento bloqueado por una Tk más reciente, hace que la más reciente sea abortada (es herida) y reiniciada Inconvenientes Ambos algoritmos hacen que sean abortadas y reiniciadas transacciones que podrían provocar un bloqueo mortal, aunque tal cosa nunca ocurriera! En el algoritmo Esperar-Morir, una Tj podría abortar y reiniciarse varias veces seguidas si Tk más antigua sigue bloqueando el X que Tj solicita Los algoritmos son opuestos entre sí, pero la transacción abortada siempre es la más joven. Ambos están libres del bloqueo mortal (interbloqueo) pues … En el Esperar-Morir, Tj sólo espera a Tk si Tk es más reciente. En el Morir-Esperar, Tj sólo espera a Tk si Tk es más antigua. Es imposible que haya ciclos. El hecho de que se aborte la transacción más reciente es ventajoso porque será la que, en teoría, menos operaciones haya realizado y, por tanto, el coste de la reversión es menor. Tema 7. Control de la concurrencia

¿está en un bloqueo mortal?
7.3 Técnicas de control de concurrencia Detección de interbloqueos Verificación periódica del estado del sistema ¿está en un bloqueo mortal? Creación de un grafo de espera que muestra las dependencias entre transacciones Crear un nodo por cada transacción en ejecución, etiquetado con el identificador de la transacción, T Si Tj espera para bloquear el elemento X, ya bloqueado por Tk, crear una arista dirigida desde Tj a Tk Cuando Tk libera el candado sobre X, borrar la arista correspondiente Si existe un ciclo en el grafo de espera, entonces se ha detectado un interbloqueo entre las transacciones Tj Tk X Tj Tk Grafo de espera (WFG, wait-for graph) Tema 7. Control de la concurrencia

Detección de interbloqueos Pero... ¿cuándo hay que verificar el estado del sistema (ejecutar el algoritmo que genera el grafo de espera)? A intervalos uniformes de tiempo, o A intervalos de tiempo desiguales : Iniciar algoritmo de detección con un tamaño de intervalo inicial Cada vez que no se detecta interbloqueo, incrementar el intervalo Por ejemplo, al doble del anterior Cada vez que se detecta interbloqueo, reducir el intervalo Por ejemplo a la mitad Existirán límites superior e inferior del tamaño del intervalo Verificar = Construir el grafo de espera. La selección del intervalo temporal uniforme entre ejecuciones del algoritmo de detección de interbloqueos es importante: si se elige un intervalo demasiado pequeño, el mecanismo de detección de interbloqueos representará un gasto adicional considerable; si el intervalo es demasiado grande, puede que los interbloqueos no se detecten durante un largo período de tiempo. Tema 7. Control de la concurrencia

Detección de interbloqueos Si el sistema está en un estado de interbloqueo, el SGBD necesita abortar algunas transacciones... ¿Cuáles?  Selección de víctimas Es mejor abortar transacciones que lleven poco tiempo en ejecución Es mejor abortar una transacción que haya hecho pocos cambios en la base de datos Es mejor abortar una transacción que todavía debe hacer muchos cambios en la base de datos Puede que el SGBD no conozca esta información Se trata de abortar las transacciones que supongan el mínimo coste Es necesario evitar la inanición Tema 7. Control de la concurrencia

Detección de interbloqueos: el problema de la inanición Una transacción sufre inanición cuando es seleccionada para ser abortada (víctima) sucesivamente: nunca termina su ejecución Es similar al bloqueo indefinido La solución es asignar prioridades más altas a las transacciones abortadas varias veces, para no ser siempre las víctimas T es abortada, se reinicia y cae en otro bloqueo mortal, y vuelve a ser seleccionada como víctima... T sufre de inanición: es una espera indefinida por el reinicio cíclico. Esperar-Morir y Herir-Esperar evitan la espera indefinida, porque cuando una T es abortada, se reinicia con la misma marca de tiempo, por lo que alguna vez se ejecutará. Tema 7. Control de la concurrencia

El problema del bloqueo indefinido El protocolo de control de concurrencia nunca selecciona a una transacción que está esperando para establecer un bloqueo, mientras otras transacciones continúan ejecutándose con normalidad Ocurre si el esquema de espera da más prioridad a unas transacciones que a otras  esquema de espera injusto Dos algoritmos de prevención de bloqueo indefinido Consiguen un esquema de espera justo El primero que llega, es el primero en ser atendido Las transacciones puede bloquear el elemento X en el orden en que solicitaron su bloqueo Aumento de prioridad en la espera Cuanto más espera T, mayor es su prioridad Cuando T tiene la prioridad más alta de todas, obtiene el bloqueo y continúa su ejecución Esquema de espera: método o técnica de gestión de la lista de transacciones en espera de elementos bloqueados. El protocolo de “Aumento de prioridad…” se usa, por ejemplo, en los protocolos de prevención del bloqueo mortal que utilizan marcas de tiempo (Herir-Esperar y Esperar-Morir). Tema 7. Control de la concurrencia

7.4 Granularidad de datos Elementos de bases de datos y granularidad
Toda técnica de control de concurrencia supone que la base de datos está constituida por un conjunto de elementos de datos con nombre Normalmente, un elemento de datos será uno de estos: un valor de campo de un registro de la BD un registro de la BD una página (uno o varios bloques de disco) un fichero la BD completa Granularidad = tamaño del elemento de información Granularidad fina  elementos de tamaño pequeño Granularidad gruesa elementos grandes En Oracle un elemento puede ser una fila (registro) en una tabla o una tabla completa (un segmento). Así, se permite el bloqueo de filas (automático) o de tablas completas (manual). Tema 7. Control de la concurrencia

7.4 Granularidad de datos Elección del tamaño adecuado del elemento de datos En el contexto de los métodos de bloqueo, el tamaño del elemento de datos afecta al grado de concurrencia:  tamaño(elemento)   Grado de concurrencia Y también...   número de elementos en la BD   carga de trabajo para la gestión de bloqueos, y   espacio ocupado por la información de bloqueo Pero... ¿Cuál es el tamaño adecuado para los elementos? Pues depende de la naturaleza de las transacciones: Si una T representativa accede a pocos registros elegir granularidad de registro Si T accede a muchos registros de un mismo fichero elegir granularidad de página o de fichero Una transacción representativa es una típica, un ‘modelo’ de las transacciones más comunes o habituales. Se han propuesto algunas técnicas que tienen un tamaño dinámico del elemento de datos. Con éstas, dependiendo de los tipos de transacción que se están ejecutando en cada momento, puede cambiarse el tamaño del elemento de datos para asignarle la granularidad que resulte más apropiada para cada transacción. Idealmente, el SGBD debe soportar un sistema de granularidad mixta, con bloqueos en el nivel de registro, página y fichero. Algunos sistemas mejoran automáticamente los bloqueos de nivel de registro o de página para asignarles nivel de fichero en aquellos casos en que la transacción está bloqueando más de un cierto porcentaje de los registros o páginas del fichero. Tema 7. Control de la concurrencia

Aclaración ... NIVEL DE ABSTRACCIÓN LÓGICO O CONCEPTUAL:
Definición del nivel de aislamiento de cada transacción (por parte del usuario o, por omisión, el propio SGBD) Control explícito de bloqueos (operación LOCK) por parte del usuario, si se permiten niveles de aislamiento inferiores a SERIALIZABLE NIVEL DE ABSTRACCIÓN FÍSICO O INTERNO: El SGBD implementa los niveles de aislamiento definidos por el usuario para las transacciones siguiendo una o varias técnicas o protocolos Por ejemplo el SGBD Oracle usa dos: Bloqueos Multiversión En SQL-92 se puede establecer el nivel de aislamiento de cada transacción que se introduce en el sistema, indicando el grado de interacción permitido con otras transacciones. Así, el SGBD controla de forma automática la concurrencia de esta transacción con las demás. Los posibles niveles de aislamiento son los siguientes: READ UNCOMMITED: permite ‘lectura sucia’, ‘actualización perdida’, ‘lectura no repetible’ y ‘lectura fantasma’. READ COMMITED: asegura que nunca ocurrirá una ‘lectura sucia’ ni ‘actualización perdida’, pero permite ‘lectura no repetible’ y ‘lectura fantasma’. REPEATABLE READ: asegura que nunca ocurrirá una ‘lectura sucia’, ‘actualización perdida’ ni ‘lectura no repetible’, pero permite ‘lectura fantasma’. SERIALIZABLE: asegura que nunca ocurrirá una ‘lectura sucia’, ‘actualización perdida’, ‘lectura no repetible’ ni ‘lectura fantasma’. Este es el único nivel seguro, es decir, si todas las transacciones están en este nivel, siempre se generan planes serializables. Un ejemplo que define el problema de la ‘lectura fantasma’: T1 recupera un conjunto de filas que cumplen cierta condición Luego, T2 inserta una nueva fila que cumple la condición. Si T1 repite su consulta, verá una nueva fila que antes no estaba (una fila fantasma). Estos conceptos se tratan en el anexo de este tema Estos conceptos se han estudiado en la teoría de este tema Tema 7. Control de la concurrencia

Aspectos de concurrencia en SQL-92 y Oracle
Niveles de aislamiento de transacción Oracle Técnica multiversión Bloqueos (candados) Tema 7. Control de la concurrencia

SQL-92 Definición de características de la transacción que se inicia
SET TRANSACTION modoacceso aislamiento Modos de acceso READ ONLY Prohíbe actualizaciones READ WRITE (por defecto) Nivel de aislamiento Grado de interferencia que una transacción tolera cuando se ejecuta concurrentemente con otras READ UNCOMMITED READ COMMITED REPEATABLE READ SERIALIZABLE (por defecto) Tema 7. Control de la concurrencia

SQL-92 Si alguna transacción se ejecuta en algún nivel menor al SERIALIZABLE, la seriabilidad puede ser incumplida: Nivel de aislamiento Lectura sucia Lectura no repetible Lectura fantasma READ UNCOMMITED Sí READ COMMITED No REPEATABLE READ SERIALIZABLE Si el sistema soporta niveles distintos a SERIALIZABLE, debería proporcionar facilidades de control explícito de la concurrencia (sentencias LOCK y UNLOCK…) Tema 7. Control de la concurrencia

Oracle Características de la transacción
SET TRANSACTION {READ ONLY | READ WRITE} aislamiento Nivel de aislamiento SERIALIZABLE Si T2 serializable intenta ejecutar una sentencia LMD que actualiza un dato que puede haber sido modificado por T1 no confirmada en el momento de comenzar T2, entonces dicha sentencia LMD falla Una T serializable sólo ve los cambios confirmados en el instante en que se inicia, más los cambios realizados por la propia transacción mediante INSERT, UPDATE, DELETE Nivel de aislamiento READ COMMITED (defecto) Si T2 read-commited intenta ejecutar una sentencia LMD que necesita filas bloqueadas por T1, entonces espera hasta que se liberen los bloqueos de las filas Cada consulta ejecutada por una transacción sólo ve los datos confirmados antes de comenzar la consulta (no la transacción) Tema 7. Control de la concurrencia

Oracle Consistencia de lectura
Garantiza que el conjunto de datos visto por una sentencia es consistente con respecto del instante en el que comenzó, y que no cambia durante la ejecución de la sentencia Asegura que los lectores no esperan a escritores ni a otros lectores de los mismos datos Asegura que los escritores no esperan a los lectores de los mismos datos Asegura que los escritores sólo esperan a otros escritores si intentan modificar las mismas filas en transacciones concurrentes Tema 7. Control de la concurrencia

Oracle Implementación de consistencia de lectura
Se asemeja a que cada usuario trabaja con una copia privada de la BD (multiversión) Cuando ocurre una actualización, los valores originales de los datos afectados, se copian en otra zona del disco (segmentos de rollback) Mientras la transacción T que actualiza no se confirma, cualquier usuario que consulte los datos modificados ve los valores originales Los cambios hechos por T sólo quedan permanentes cuando T es confirmada Las sentencias (de otras transacciones) que comienzan después de que T se confirme ya ven los cambios hechos por T Nunca ocurren lecturas sucias Tema 7. Control de la concurrencia

Oracle Bloqueos Gestión Automática de los bloqueos Gestión Manual
Bloqueos exclusivos y compartidos Permiten a otras transacciones leer los datos bloqueados, pero no modificarlos Bloqueos de tabla o de fila (una o más) Los bloqueos sólo se liberan la finalizar la transacción (COMMIT o ROLLBACK) Gestión Manual Se superpone al bloqueo automático Sentencia LOCK TABLE (no existe UNLOCK) Tema 7. Control de la concurrencia

7. Control de la concurrencia

Presentaciones similares

Presentación del tema: "7. Control de la concurrencia"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

7. Control de la concurrencia

Presentaciones similares

Presentación del tema: "7. Control de la concurrencia"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback