Transacciones Transacción: colección de operaciones que forman una única unidad lógica de trabajo en una BD Control concurrencia Sistemas multiusuario: ejecución intercalada Recuperación Para cuando una transacción falla Vida de una transacción Inicio Lecturas/escrituras de elementos de la BD Final (pueden hacer falta algunas verificaciones) Confirmación (COMMIT) o anular (ROLLBACK)
Transacciones Toda transacción debe cumplir el principio ACID Atómica: se ejecuta todo (commit) o nada (rollback) Debe garantizarlo el método de recuperación del SGBD Consistente: pasa de un estado consistente a otro Debe garantizarlo el programador y el SGBD (restr. int.) aIslada: no lee resultados intermedios de otras transacciones que no han terminado Debe garantizarlo el método de control de concurrencia y el programador (ej: usando protocolo bloqueo en 2 fases). Duradera: si se termina con éxito (commit), los cambios en la BD son estables aunque luego falle otra Debe garantizarlo el método de recuperación.
Recuperación Caídas del sistema durante una transacción Errores de ejecución: overflow, división por 0… Errores lógicos que violan alguna regla de integridad (definida explícitamente o no) y que dejan inconsistente la BD -> programador/ABD Problemas de concurrencia de transacciones Fallos de lectura/escritura en disco Problemas físicos y catástrofes: fuego, robos, sabotajes, fallos “humanos”,… –> medidas de seguridad informática en la empresa.
Recuperación Para que el sistema se pueda recuperar ante fallos se necesita grabar cada operación con la BD en un fichero LOG (bitácora). Checkpoints. se escribe en el fichero LOG antes que en la BD el fichero LOG debe estar en memoria estable Por cada operación se escribe un reg. en LOG < comienza-transacción, numt> < escritura, numt, id_dato, val_viejo, val_nuevo> < lectura, numt, id_dato, valor> < termina_transacción_con_éxito, numt> < punto_comprobación, numt, numc>
Problemas de concurrencia La ejecución concurrente de transacciones puede dar lugar a problemas: Problema de la actualización perdida Problema de leer una actualización temporal (lectura sucia) Problema del resumen incorrecto Problema de la lectura no repetible
Problemas de Concurrencia Sol. trivial: cada transacción se ejecuta en exclusión mutua. ¿Cuál sería la granularidad? ¿BD? ¿Tabla? ¿Tupla? ¿Atributo? La solución trivial no es válida: muy restrictiva Se supone que las BDs se pensaron para que varios usuarios/aplicaciones accedieran a la vez Hay que intercalar acciones pero que el resultado sea como en exclusión mutua
Control de concurrencia: planes serializables Dadas las transacciones T1, T2, … Tn, T1 compuesto por operaciones O11,O12,..O1 m1 T2 compuesto por operaciones O21,O22,..O2 m2 … Tn compuesto por operaciones On1, On2..On mn Un plan de ejecución concurrente de las transacciones sería: Ej: O11, O21, On1, On2, O12, O22, …, O1 m1, O2 m2, …, On mn Una intercalación de todas las operaciones Oij donde para todo i, Oi1 se ejecuta antes que Oi2 … antes que Oi mi Un plan es serializable si su resultado es el mismo que el producido por alguno de los posibles planes seriales de T1, T2,…Tn Ej:opers. de T2, opers. T1, opers. Tn, …., opers. de T3
Serializabilidad Aparte de ACID, queremos que las transacciones sean serializables. Determinar si un determinado plan es serializable es un problema NP-completo. Solución: Imponer restricciones a la libre intercalación de operaciones entre transacciones Técnicas pesimistas: se impide realizar ciertas operaciones si son sospechosas de producir planes no serializables: BLOQUEOS (lock) y MARCAS DE TIEMPO (time-stamping) Técnicas optimistas: no imponen restricciones pero después se comprueba si ha habido interferencias
| Página siguiente |