UNIDAD V: Transacciones en las bases de datos Objetivo: Que el alumno comprenda la importancia de garantizar las operaciones contra la base

de datos, a travs del uso de transacciones. Definicin de Transaccin Es una coleccin de operaciones que forman una nica unidad lgica de trabajo. Es una unidad de la ejecucin de un programa que accede y posiblemente actualiza varios elementos de datos. Propiedades de una transaccin: Para asegurar la integridad de los datos se necesita que el sistema de base de datos mantenga las siguientes propiedades de las transacciones: Atomicidad: una transaccin es una unidad atmica de procesamiento; o bien se realiza por completo o no se realiza en absoluto (todo o nada). Consistencia: la ejecucin aislada de la transaccin (es decir, sin otra transaccin que se ejecute concurrentemente) conserva la consistencia de la base de datos. En otras palabras, una transaccin conserva la consistencia si su ejecucin completa lleva la base de datos de un estado consistente a otro. Aislamiento: aunque se ejecuten varias transacciones concurrentemente, el sistema garantiza que cada transaccin ignore al resto de las transacciones que se ejecuten al mismo tiempo. Es decir, la ejecucin de una transaccin no debera interferir con otras transacciones que se ejecuten concurrentemente. Durabilidad: tras la finalizacin con xito de una transaccin, los cambios realizados en la base de datos deben perdurar, incluso si hay fallos en el sistema. Estas propiedades a menudo reciben el nombre de propiedades ACID; el acrnimo se obtiene de la primera letra de cada una de las cuatro propiedades en ingls (Atomicity, Consistency, Isolation y Durability, respectivamente). El alcance de una transaccin est delimitado por un comienzo y un final, es decir, Begin.End. Operacin COMMIT Indica que la transaccin ha sido realizada satisfactoriamente. Operacin ROLLBACK Indica que la finalizacin de una transaccin no satisfactoria. Estados de una transaccin 1. Activa: el estado inicial; la transaccin permanece en este estado durante su ejecucin. 2. Parcialmente comprometida: despus de ejecutarse la ltima instruccin. 3. Fallida: tras descubrir que no se puede continuar la ejecucin normal. 4. Abortada: despus de haber retrocedido la transaccin y restablecido a la base de datos a su estado anterior al comienzo de la transaccin. 5. Comprometida: tras completarse con xito.

2 1 3

Concurrencia: Es cuando se ejecutan ms de una transaccin al mismo tiempo y actualizan el mismo recurso. Seriabilidad: Se refiere a que el efecto de ejecutar transacciones concurrentemente debe ser el mismo que se producira al ejecutarlas por separado en un orden secuencial. Bloqueo: Una forma de asegurar la secuencialidad es exigir que el acceso a los elementos de datos se haga en exclusin mutua, es decir, mientras una transaccin accede a un elemento de datos, ninguna otra transaccin puede modificar dicho elemento. Bloqueo Activo (LIVE-LOCK): Una transaccin se encuentra en un estado de bloqueo activo si no puede procesarse por un perodo de tiempo indefinido mientras otras transacciones continan normalmente. Por ejemplo: si la transaccin t2 est esperando a que t1 libere el tem x, pero cuando lo libera lo bloquea t3, etc. De manera que t2 est esperando indefinidamente. La solucin a este problema es tener un algoritmo de espera adecuado (colas). De forma que las transacciones tienen acceso al bloqueo sobre un tem en el mismo orden en el que solicitan dicho bloque. Inter-bloqueo (DEAD-LOCK): Sucede cuando dos transacciones se excluyen mutuamente del acceso al siguiente registro requerido para completar cada una de sus operaciones. Esto lleva a una posponencia indefinida.
Esperando por: B T1 T2 Esperando por: A

Utilizado por T2

Utilizado por T1

Maneras de evitar el inter-bloqueo: Se puede evitar el inter-bloqueo permitiendo a los usuarios bloquear todos los recursos necesarios para sus transacciones. Detectar el DEAD-LOCK y abrirlo, destruyendo una de las transacciones, es decir, una de las transacciones ser abortada y cualquier modificacin ser deshecha. Asignar un tiempo de ejecucin a cada transaccin y si dicha transaccin no se ejecuta en el tiempo establecido se aborta. Recuperabilidad: Es la restauracin de la base de datos a un estado antes de que ocurriera el fallo (sistema, hardware, lgico, humano). En este caso se deben seguir los procedimientos de restauracin previamente establecidos. Recuperabilidad va Reprocesamiento: Si no es posible regresar al punto preciso del fallo, lo ms factible es regresar a un punto conocido y reprocesar la carga de trabajo a partir de ah. En este tipo de recuperabilidad se debe hacer lo siguiente: realizar copias peridicas de la base de datos y conservar un registro de todas las transacciones que se hayan realizado. La principal desventaja ocurre cuando el volumen de informacin es muy grande y el tiempo de reprocesamiento sea muy pesado, esto causara que el sistema nunca se pusiera al da. Por ejemplo: si un cliente A obtuvo el ltimo asiento de vuelo en el procesamiento original, el cliente B puede obtenerlo durante el reproceso.

Recuperabilidad Regresiva y Progresiva: En ambas se realiza la copia peridica y un registro de las modificaciones efectuadas en la base de datos a partir de la copia. R. Progresiva: La base de datos se restaura en la copia y todas las transacciones vlidas se vuelven a aplicar (no estamos reprocesando las transacciones, ya que los programas de aplicacin no se involucran, en lugar de ello, las modificaciones procesadas, tal y como fueron registradas en el control, se vuelven a aplicar.) R. Regresiva: Se deshacen los cambios hechos por transacciones errneas o procesadas parcialmente, deshaciendo las modificaciones efectuadas en la base de datos. Las transacciones vlidas que estaban en proceso al momento del fallo, se vuelven a aplicar.

Bitcora o Diario del Sistema Es el registro de las modificaciones de los datos en orden cronolgico. Las transacciones se escriben en la bitcora antes de su aplicacin en la base de datos. Para deshacer una transaccin, la bitcora debe tener una copia de cada registro (imgenes previas) antes de su modificacin.
BD Modif. Deshacer BD Orig.

Img. Previa

Para rehacer una transaccin, la bitcora debe tener una copia de cada registro (imgenes posteriores) despus de su modificacin.
BD Orig. Rehacer BD Modif.

Img. Post.

Estructura de una bitcora Es una tabla que contiene lo siguiente: Identificador de la transaccin Hora de modificacin Identificador del registro afectado Tipo de accin Valor anterior del registro Valor nuevo del registro Informacin adicional.

Punto de Revisin: Cuando ocurre un fallo en el sistema se debe consultar el registro histrico para determinar las transacciones que deben rehacerse y las que se deben deshacer. En principio es necesario recorrer completamente la bitcora para hallar la informacin. Desventajas: 1. El proceso de bsqueda consume tiempo. 2. La mayora de las transacciones que deben rehacerse de acuerdo al algoritmo ya tienen escritas sus actualizaciones en la base de datos. Aunque el hecho de volver a ejecutar estas transacciones no produzca resultados errneos, si repercutir en un aumento del tiempo de ejecucin del proceso de recuperacin. Para evitar este tipo de sobrecarga se introducen los puntos de revisin (o checkpoint), que se definen como un punto de sincronizacin entre la base de datos y la bitcora. Cuando se ejecuta, el SGBD rechaza nuevas peticiones, finaliza las peticiones actuales y vaca los buffers en el disco duro. El establecimiento de checkpoints implica: Grabar fsicamente el contenido de los buffers de datos a la base de datos fsica. Grabar fsicamente un registro del punto de revisin especial dentro de la bitcora. Los checkpoints permiten la recuperacin de la base de datos en caliente, es decir, despus de la cada del sistema se obtiene la direccin del registro de recuperacin ms reciente y se recorre la bitcora desde el checkpoint. Estrategias de recuperacin Existen diferentes estrategias de reinicio de transacciones y recuperacin de datos, generalmente los algoritmos ya estn implementados y son ejecutados por el SMBD. Sin embargo, para efectos de aprendizaje, a continuacin veremos un algoritmo sencillo para la recuperacin de transacciones. El procedimiento que deber realizar el sistema al reiniciarse consiste: 1. Comenzar con dos listas de transacciones, la lista de deshacer y la de rehacer. Igualar la lista de deshacer a la lista de todas las transacciones incluidas en el registro del checkpoint. Dejar vaca la lista de rehacer. 2. Examinar la bitcora hacia adelante a partir del registro de checkpoint. 3. Si se encuentra una entrada de bitcora de iniciar transaccin para la transaccin T, aadir T a la lista de deshacer. 4. Si se encuentra una entrada de bitcora de finalizar transaccin para la transaccin T, pasar esa transaccin de la lista de deshacer a la lista de rehacer.