Gestión de Transacciones

Transcripción

1 Gestión de Transacciones y su relación con el gestor de concurrencia (planificador) y el gestor de recuperación 1 Sistema Monousuario vs. Multiusuario. concurrencia Transacciones Estado de las transacciones. 2 Sist. Monousuario vs Multiusuario Clasificación BD según el numero de usuarios: Monousuario: Un usuario a la vez Multiusuario: Acceso simultaneo a la BD Multiprogramación (intercambio de proceso) proceso A Definición de transacción Unidad lógica de procesamiento de la BD que incluye una o más operaciones de acceso a la BD que pueden ser de inserción, eliminación, modificación o recuperación. proceso B Cjto. de lecturas/escrituras sobre la BD Procesamiento Paralelo. Mas de una CPU 3 4 Limites de la transacción Begin Transaction (set_transaction) End Transaction (commit, rollback) Todas las operaciones entre los límites se considera que forman parte de la transacción. Una aplicación puede contener más de una transacción (si contiene varios límites) Fin de una transacción COMMIT. Con éxito. Las actualizaciones que realiza la transacción se graban ROLLBACK. Con fracaso. Las actualizaciones que realiza la transacción deben deshacerse. 5 6 ABD

2 Ejemplo de transacción (2) % Sean las tablas: PASAJERO(Nombre...) VUELO(Codigo...) PAS_VUE(Nombre,Codigo) con dos restricciones rest1: todo pasajero debe estar en un vuelo rest2: todo vuelo tiene al menos un pasajero Transacción: asignar el primer pasajero a un avión set_transaction insert into VUELO values (123...); insert into PASAJERO values ( aitor,...); insert into PAS_VUE values ( aitor,123); Commit Durante la transacción puede NO cumplirse las rest. de integridad Al finalizar la transacción, todas las restricciones deben ser satisfechas La transacción es una unidad de consistencia 7 Ejemplo de transacción (1) % transferencia de 1000 entre dos cuentas corrientes set_transaction leer(c1.saldo); c1.saldo = c1.saldo ; escribir(c1.saldo); leer(c2.saldo); c2.saldo = c2.saldo ; escribir(c2.saldo); Commit Transacción: unidad de interacción con la BD. No puede quedarse a medias a riesgo de dejar la BD en un estado inconsistente. Es la aplicación (y no el SGBD) el que define que cjto. de acciones constituyen una transacción. Si se quiere asegurar un orden entre las acciones, englobarlas dentro de una misma transacción o poner condiciones 8 Sistema Monousuario vs. Multiusuario concurrencia Transacciones Estado de las transacciones 9 Concurrencia: Necesidad Premisa: cada transacción ejecutada individualmente preserve la consistencia de la BD 10 Ejecución en serie Concurrencia: Necesidad Premisa: cada transacción ejecutada individualmente preserve la consistencia de la BD Pero la ejecución concurrente de las transacciones no nos lleva necesariamente a un estado consistente , , A 11 B ABD

3 Ejecución concurrente Concurrencia: Problemas Premisa: cada transacción ejecutada individualmente preserve la consistencia de la BD Pero la ejecución concurrente de las transacciones no nos lleva necesariamente a un estado consistente Problemas: pérdida de actualizaciones actualizaciones asumidas lecturas inconsistentes , , A 13 B Problema. La actualización perdida x:= x - 100; escribir(x); leer(y); y := y + 100; escribir(y) x := x + 33; escribir(x); x tiene un valor incorrecto porque su actualización por se sobre-escribió 15 Problema. La actualización sucia (Modificación Temporal) x:= x - 100; escribir(x); leer(y); error-abortar x := x +50; escribir(x); ha leído un valor temporal incorrecto de x (valor sucio) 16 Problema. El resumen incorrecto Concurrencia: Solución x:= x - 100; escribir(x); leer(y); y := y + 100; escribir(y); suma := 0; leer(a); suma := suma + A;.. suma := suma + x; leer(y); suma := suma + y; ha leído el valor de x después de restar n, y el valor de y antes de sumar n. El valor suma no será correcto. 17 Conclusión: se necesita un mecanismo de control de la concurrencia que asegure que la ejecución concurrente de las transacciones preserve la consistencia. 18 ABD

4 Sistema Monousuario vs. Multiusuario concurrencia Transacciones Estado de las transacciones 19 recuperación: Necesidad El SGBD debe asegurar que toda transacción confirmada quede registrada en el sistema y que la misma no tenga efecto sobre la BD o sobre otra transacción. Esto puede suceder si una transacción falla después de ejecutar alguna operaciones. 20 recuperación: Problema Fallo del ordenador (caída del sistema) Error de la transacción (ej. Overflow, violación restricción) Errores de los usuarios (ej. el usuario borra accidentalmente una tabla) Imposición de control de concurrencia (ej. estado de bloqueo mortal) Fallo disco Recuperación. Solución Deben existir algoritmos que garanticen la consistencia de la BD y la atomicidad de las transacciones a pesar de los fallos. Solución: Mecanismos de control de concurrencia Mecanismos de recuperación Catástrofes físicas (Ej. inundación) Sistema Monousuario vs. Multiusuario concurrencia Transacciones Estado de las transacciones 23 Estados de las transacciones Una transacción es una unidad atómica que se realiza por completo o no, pasando por: leer/escribir begin_of_tra ACTIVA end_of_tra abortar PARCIALMENTE CONFIRMADA abortar FALLIDA confirmar Parcialmente Confirmada: el SGBD verifica que no hay interferencias dañinas con otras transacciones. CONFIRMADA TERMINADA 24 ABD

5 El diario del sistema Las entradas del diario del sistema son: [start_transaction, T ] T es el identificador [commit, T] [abort, T] [read_item, T, dato, <valorleido>] [write_item, T, dato, <valorantigüo>, <valornuevo>] Operaciones: REDO: se escriben los <valornuevo> en la BD UNDO: se repone los <valorantigüo> en la BD Principio ACID (I) Su cumplimiento debe estar asegurado por el SGBD Se ejecuta como unidad (Atomicity) Preserva la consistencia(consistency) Una transacción no muestra los cambios que produce hasta que finaliza (Isolation) Si termina correctamente, sus cambios permanecen (Durability) Principio ACID (II) Principio ACID (III) Transacciones Buffer Planificador Concurrencia Recuperación Se ejecuta como unidad (Atomicity) transacciones, recuperación Preserva la consistencia(consistency) Gestor de Rest. de integridad Una transacción no muestra los cambios que produce hasta que finaliza (Isolation) Control de Concurrencia 27 Si termina correctamente, sus cambios permanecen (Durability) Recuperaciones 28 Sistema Monousuario vs. Multiusuario concurrencia Transacciones Estado de las transacciones 29 Planificador Hay que regular el orden en el que se ejecutan las acciones de las diferentes transacciones. Encargado de la función de control: Planificador (Scheduler) 30 ABD

6 El planificador (scheduler) transacciones peticiones READ/WRITE o.k/wait/abort Planificador Buffer le llegan peticiones de lectura/escritura, y bien las ejecuta en los buffers o bien las retrasa Cuándo es problemática la ejecución concurrente? Cómo controlar que estos problemas no se dan? 31 Operaciones básicas memoria volátil read/write buffer local buffer local buffer local buffer local Las operaciones básicas de acceso a una BD que una transacción puede incluir son: leer-elemento (READ) escribir-elemento (WRITE) INPUT OUTPUT buffer global input/output bloque Área de trabajo privada para cada transacción memoria estable BD 32 Planificación (Plan) Definición: serie intercalada de acciones de distintas transacciones donde se respeta el orden relativo de la acción dentro de cada transacción. Las acciones que nos interesan son únicamente lecturas/escrituras sobre la base de datos = {a11,a12,a13} ; = {a21,a22} ; T3 = {a31,a32,a33} Planif(,,T3) = {a11,a21,a12,a31,a22,a13,a32,a33} Planificación en SERIE es aquella donde NO se solapan las transacciones con n transacciones tenemos n! planificaciones en serie no hay concurrencia poco eficientes 33 obviamente, no existen los problemas de la ejecución concurrente Principio de corrección Cualquier transacción ejecutada de forma aislada transforma un estado consistente en otro estado consistente. Pero!!!!!!!!!!! Las transacciones se ejecutan concurrentemente 34 Planificación serializable Definición: planificación que no siendo en serie, produce un resultado equivalente a una planificación en serie Condición para asegurar que una planificación sea serializable? Noción de conflicto Conflicto: par de acciones de una planificación tal que si se altera su orden, el resultado de al menos una de las transacciones involucradas puede cambiar. Los conflictos sólo se dan al trabajar sobre un mismo gránulo G. Acción 1 Acción 2 conflicto? READ(G,t) READ(G,t) NO READ(G,t) WRITE(G,t) SI WRITE(G,t) READ(G,t) SI WRITE(G,t) WRITE(G,t) SI 35 Gránulo: unidad de reserva 36 ABD

7 Conflicto Dos acciones de dos transacciones diferentes NO se pueden intercambiar (están en conflicto) si: Trabajan con el mismo elemento de la BD Al menos una de ellas es una operación de escritura Planificaciones equivalentes en conflictos Dos planificaciones son equivalentes en conflictos si se puede convertir una en otra siguiendo una secuencia de intercambios no conflictivos (es decir, sin cambiar el resultado final) entre acciones adyacentes Se cumple que el orden de dos acciones cualesquiera en conflicto es el mismo en ambas planificaciones. Nota: La equivalencia por resultados no sirve para definir la equivalencia entre planificaciones Planificación serializable en conflictos Una planificación es serializable en conflicto si es equivalente en conflicto a una planificación en serie 39 Cuál es su planif. en serie equivalente? planif. en serie:, No es serializable en conflictos 40 Condición de serializable en conflictos De cara a garantizar la serializabilidad, esta condición (la de serializable en conflictos ) es suficiente. Lo imponen los sistemas comerciales planificaciones serializables planificaciones serializables en conflictos Grafo de precedencia de una planif. (Grafo de serialización) Nodo: para cada una de las transacciones de la planificación Arco de a si existe una acción a1 de y una acción a2 de tal que: a1 se encuentra antes que a2 en la planif. a1 y a2 actuan sobre el mismo gránulo bien a1 ó a2 es una escritura El grafo precedencia de una planif. en serie NO tiene ciclos El grafo de precedencia de una planifserializable en conflicto NO puede tener ciclos 41 Nota: Existe un algoritmo para construir grafos de precedencia 42 ABD

8 Serializabilidad de Vistas Definición menos restrictiva de la equivalencia entre planificaciones que la serializabilidad de conflictos. Una planificación es serializable en términos de vistas si es equivalente en términos de vistas a una planificación serie. Toda planificación serializable en términos de conflictos es serializable en términos de vistas, aunque la inversa no es cierta. 43 Serializabilidad de Vistas Dos planificaciones S1 y S2 compuestas por las mismas operaciones tomadas de n transacciones,, Tn son equivalentes en términos de vistas si se cumplen las tres siguientes condiciones: Para cada elemento de datos x, si la transacción T i lee el valor inicial de x en la planificación S1, entonces la transacción T i también debe leer el valor inicial de x en la planificación S2. Para cada operación de lectura sobre el elemento de datos x por parte de la transacción Ti en la planificación S1, si el valor leído de x ha sido escrito por la transacción Tj, entonces la transacción Ti también debe leer el valor de x producido por la transacción Tj en la planificación S2. Para cada elemento de datos x, si la última operación de escritura sobre x fue realizada por la transacción T i en la planificación S1, la misma transacción debe realizar la escritura final del elemento de datos x en la planificación S2. 44 Ejemplo. Planificación serializable en términos de vistas Tiempo t1 t2 t3 t4 t5 t6 t7 t8 t9 READ(A,X) WRITE(A,X) WRITE(A,X) WRITE(A,X) Planificación serializable En la práctica es difícil comprobar la serializabilidad de una planificación. Por ello la estrategia que se sigue en casi todos los sistemas prácticos es encontrar métodos que garanticen la serializabilidad sin tener que verificar las planificaciones Protocolos de concurrencia Bibliografía Para asegurar que las transacciones se enreden de forma serializable, el SGBD impone unas reglas en el momento de utilizar los gránulos: el protocolo Tres protocolos: el de reserva, de Bloqueo (locks) el de la marca de (time stamping) el de validación 47 Database System Implementation H. García Molina, J.D. Ullman, J. Widom Prentice Hall 2000 Fundamentals of Database Systems (4. edición 2004) Fundamentos de Sistemas de Bases de Datos (3. Edición 2002). R.A. Elmasri, S. B. Navathe. Addison Wesley Sistemas de Bases de Datos. Un enfoque práctico para diseño, implementación y gestión. (4. edición, 2005) T. Connolly, C. Begg Addison-Wesley 48 ABD