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  |