See www.db-book.comfor conditions on re-use Transacciones Silberschatz, Korth and Sudarshan 15.2 Database System Concepts - 5 th Edition, Sep 10, 2005. Transacciones Concepto de transaccin Estado de una transaccin Ejecuciones concurrentes Secuencialidad Recuperabilidad Implementacin de aislamiento Silberschatz, Korth and Sudarshan 15.3 Database System Concepts - 5 th Edition, Sep 10, 2005. Concepto de transaccin Una transaccin es una unidad de la ejecucin de un programa que accede y posiblemente actualiza varios elementos de datos. Una transaccin se inicia por la ejecucin de un programa de usuario escrito en un lenguaje de manipulacin de datos de alto nivel, y est delimitado por instrucciones (o llamadas a funcin) de la forma inicio transaccin y fin transaccin. La transaccin consiste en todas las operaciones que se ejecutan entre inicio transaccin y el fin transaccin. Silberschatz, Korth and Sudarshan 15.4 Database System Concepts - 5 th Edition, Sep 10, 2005. Propiedades ACID Atomicidad. O bien todas las operaciones de la transaccin se realizan adecuadamente en la base de datos o ninguna de ellas. Consistencia. La ejecucin aislada de la transaccin (es decir, sin otra transaccin que se ejecute concurrentemente) conserva la consistencia de la base de datos. Aislamiento. Aunque se ejecuten varias transacciones concurrentemente, el sistema garantiza que para cada par de transacciones T i y T j , se cumple que para los efectos de T i , o bien T j ha terminado su ejecucin antes de que comience T i , o bien que T j ha comenzado su ejecucin despus de que T i termine. De este modo, cada transaccin ignora al resto de las transacciones que se ejecuten concurrentemente en el sistema. Durabilidad. Tras la finalizacin con xito de una transaccin, los cambios realizados en la base de datos permanecen, incluso si hay fallos en el sistema. Para asegurar la integridad de los datos se necesita que el sistema de base de datos mantenga las siguientes propiedades de las transacciones: Silberschatz, Korth and Sudarshan 15.5 Database System Concepts - 5 th Edition, Sep 10, 2005. Ejemplo de transferencia de fondos Transaccin para transferir $50 desde una cuenta A la cuenta B: 1. read(A) 2. A := A 50 3. write(A) 4. read(B) 5. B := B + 50 6. write(B) Requerimiento de atomicidad si la transaccin falla despus del paso 3 y antes del paso 6, el sistema debe garantizar que sus cambios no se reflejan en la base de datos, de lo contrario resultar una inconsistencia. Requerimiento de consistencia la suma de A y B no se modifica por la ejecucin de la operacin. Silberschatz, Korth and Sudarshan 15.6 Database System Concepts - 5 th Edition, Sep 10, 2005. Ejemplo de transferencia de fondos (Cont.) Requerimiento de aislamiento si entre los pasos 3 y 6, otra transaccin puede acceder a los datos parcialmente actualizados en la base de datos, ver una base de datos inconsistente (la suma de A + B ser menor de lo que debera ser). El aislamiento puede ser asegurada trivialmente. Una solucin para el problema de ejecutar transacciones concurrentemente es ejecutarlas secuencialmente, es decir, una tras otra. Sin embargo, la ejecucin concurrente de transacciones produce notables beneficios en el rendimiento. Requerimiento de durabilidad una vez que el usuario ha sido notificado de que la transaccin se ha completado (es decir, la transferencia de los $ 50 ha tenido lugar), los cambios a la base de datos de la transaccin debe persistir a pesar de los fracasos. Silberschatz, Korth and Sudarshan 15.7 Database System Concepts - 5 th Edition, Sep 10, 2005. Estados de una transaccin Activa, el estado inicial; la transaccin permanece en este estado durante su ejecucin. Parcialmente comprometida, despus de ejecutarse la ltima instruccin. Fallida, tras descubrir que no puede continuar la ejecucin normal. Abortada, despus de haber retrocedido la transaccin y restablecido la base de datos a su estado anterior al comienzo de la transaccin. Comprometida, tras completarse con xito Silberschatz, Korth and Sudarshan 15.8 Database System Concepts - 5 th Edition, Sep 10, 2005. Estados de una transaccin (Cont.) Silberschatz, Korth and Sudarshan 15.9 Database System Concepts - 5 th Edition, Sep 10, 2005. Implementacin de la Atomicidad y la durabilidad El componente de gestin de recuperacin del sistema de base de datos implementa el soporte para la atomicidad y durabilidad. El esquema copia en la sombra: (copia de toda la BD en archivos) Asume que solo una transaccin esta activa en el momento. Un puntero llamado puntero_bd que apunta a la copia actual de la base de datos. Todas las actualizaciones son hechas en la copia en la sombra de la base de datos, y puntero_bd apunta a la copia en la sombra solo despus que la transaccin haya alcanzado el estado de parcialmente comprometido y todas las pginas actualizadas se han volcado a disco. En el caso que la transaccin falla, la copia consistente apuntada por puntero_bd puede ser utilizada, y la copia en la sombra puede ser eliminada. Silberschatz, Korth and Sudarshan 15.10 Database System Concepts - 5 th Edition, Sep 10, 2005. Implementacin de la Atomicidad y la durabilidad (Cont.) Asume que el disco no falla Es til para los editores de texto, pero Extremadamente ineficiente para grandes bases de datos No permite manejar transacciones concurrentes El esquema copia en la sombra : Silberschatz, Korth and Sudarshan 15.11 Database System Concepts - 5 th Edition, Sep 10, 2005. Ejecuciones concurrentes Mltiples transacciones se pueden ejecutar simultneamente en el sistema. Las ventajas son: Aumento de productividad y utilizacin de del disco. Conduce a un mejor productividad del sistema: una transaccin puede estar utilizando la CPU mientras que otra estar leyendo o escribiendo en el disco. Tiempo de espera reducido para las transacciones: Si las transacciones se ejecutan secuencialmente, la transaccin corta debe esperar a que la transaccin larga anterior se complete, lo cual puede llevar a un retardo impredecible en la ejecucin de la transaccin. Esquemas de control de concurrencia mecanismos para lograr el aislamiento, es decir, para controlar la interaccin entre las transacciones simultneas con el fin de impedir que destruyeran la consistencia de la base de datos. Silberschatz, Korth and Sudarshan 15.12 Database System Concepts - 5 th Edition, Sep 10, 2005. Planificacin de la concurrencia Planificacin una secuencia de instrucciones que especifican el orden cronolgico en que las instrucciones de transacciones concurrentes se ejecutan: Una planificacin para un conjunto de transacciones debe considerar todas las instrucciones de las transacciones Debe preservarse el orden en la que aparecen las instrucciones para cada transaccin individual. Una transaccin que completa con xito su ejecucin tendr la instruccin de comprometido como ultima sentencia. Una transaccin que que no completa correctamente su ejecucin tendr la instruccin de Abortar como la ultima sentencia. Silberschatz, Korth and Sudarshan 15.13 Database System Concepts - 5 th Edition, Sep 10, 2005. Planificacin 1 Si T 1 transfiere $50 de A a B, y T 2 transfiere el 10% del saldo de A a B. Una planificacin secuencial en el cual T 1 es seguido por T 2 : Silberschatz, Korth and Sudarshan 15.14 Database System Concepts - 5 th Edition, Sep 10, 2005. Planificacin 2 Una planificacin secuencial donde T 2 es seguido por T 1 Silberschatz, Korth and Sudarshan 15.15 Database System Concepts - 5 th Edition, Sep 10, 2005. Planificacin 3 Sea T 1 y T 2 las transacciones se ha definido anteriormente. La siguiente planificacin no es una planificacin secuencial, pero es equivalente a la planificacin1. En la planificacin 1, 2 y 3, la suma A + B se preserva. Silberschatz, Korth and Sudarshan 15.16 Database System Concepts - 5 th Edition, Sep 10, 2005. Planificacin 4 La siguiente planificacin concurrente no preserva el valor de (A + B). Silberschatz, Korth and Sudarshan 15.17 Database System Concepts - 5 th Edition, Sep 10, 2005. Secuencialidad Supuesto bsico Cada transaccin preserva la consistencia de bases de datos. As la ejecucin en serie de un conjunto de transacciones conserva la consistencia de base de datos. Una planificacin (posiblemente concurrente) se puede secuencializar si este es equivalente a su planificacin secuencial. Existe diferentes formas de equivalencia de planificacin: 1. Secuencialidad en cuanto a conflictos 2. Secuencialidad en cuanto a vistas 2. Ignoramos las operaciones que no sean instrucciones de leer y escribir, se supone que las transacciones pueden realizar clculos arbitrarios sobre los datos en los buffers locales entre la lectura y escritura. Nuestras planificaciones se simplifican a slo instrucciones de Lectura y escritura. Silberschatz, Korth and Sudarshan 15.18 Database System Concepts - 5 th Edition, Sep 10, 2005. Instrucciones secuencializables Sea las instrucciones l i e l j de las transacciones T i y T j respectivamente, existe conflicto si y slo si existe algn elemento Q accedido tanto por l i y l j , y al menos una de estas instrucciones escribi a Q. 1. l i = read(Q), l j = read(Q). l i y l j no estn en conflicto. 2. l i = read(Q), l j = write(Q). Estn en conflicto. 3. l i = write(Q), l j = read(Q). Estn en conflicto 4. l i = write(Q), l j = write(Q). Estn en conflicto Intuitivamente, un conflicto entre l i y l j obliga a (lgica) una orden temporal entre ellos. Si l i y l j son consecutivos en una planificacin y no estan en conflictos, los resultados serian los mismos incluso si ellos deciden intercambiar en la planificacin. Silberschatz, Korth and Sudarshan 15.19 Database System Concepts - 5 th Edition, Sep 10, 2005. Secuencialidad en cuanto a conflictos Si una planificacin S se puede transformar en una planificacin S por medio de una serie de intercambios de instrucciones no conflictivas, se dice que S y S son equivalente en cuanto a conflictos. Se dice que una planificacin S es secuenciable en cuanto a conflictos si es equivalente en cuanto a conflictos a una planificacin secuencial. Silberschatz, Korth and Sudarshan 15.20 Database System Concepts - 5 th Edition, Sep 10, 2005. Secuencialidad en cuanto a conflictos (Cont.) La planificacin 3 puede ser transformada en la planificacin 6, una planificacin secuencial donde T 2 sigue a T 1 , por una serie de intercambios de instrucciones no conflictivas. Por lo tanto la planificacin 3 es Secuenciable en cuanto a conflictos.. Planificacin 3 Planificacin 6 Silberschatz, Korth and Sudarshan 15.21 Database System Concepts - 5 th Edition, Sep 10, 2005. Secuencialidad en cuanto a conflictos (Cont.) Ejemplo de una planificacin que no es secuenciable en cuanto a conflictos: No podemos intercambiar instrucciones en la planificacin anterior para obtener ya sea la planificacin secuencial < T 3 , T 4 >, o < T 4 , T 3 >. Silberschatz, Korth and Sudarshan 15.22 Database System Concepts - 5 th Edition, Sep 10, 2005. Secuencialidad en cuanto a vistas Si S y S son planificaciones con el mismo conjunto de transacciones. S y S son Secuenciable en cuanto a vistas si las tres condiciones siguientes se cumplen: 1. Para todo elemento de datos Q, si la transaccin T i lee el valor inicial de Q en la planificacin S, entonces T i debe leer tambin el valor inicial de Q en la planificacin S. 2. Para todo elemento de datos Q, si la transaccin T i ejecuta leer(Q) en la planificacin S y el valor lo ha producido la transaccin T j (si existe dicha transaccin) entonces, en la planificacin S, la transaccin T i debe leer tambin el valor de Q que haya producido la transaccin T j . 3. Para todo elemento de datos Q, la transaccin (si existe) que realice la ltima operacin escribir(Q) en la planificacin S, debe realizar la ltima operacin escribir(Q) en la planificacin S. Como puede verse, la equivalencia en cuanto a vista se basa tambin en solamente instrucciones leer y escribir. Silberschatz, Korth and Sudarshan 15.23 Database System Concepts - 5 th Edition, Sep 10, 2005. Secuencialidad en cuanto a vistas (Cont.) Una planificacin S es Secuenciable en cuanto a vistas si su equivalencia en cuanto a vistas es una planificacin secuencial. Toda planificacin secuenciable en cuanto a conflictos es tambin secuenciable en cuanto a vistas. La planificacin siguiente es secuenciable en cuanto a vistas, ya que la instruccin read(Q) lee el valor inicial de Q en ambas planificaciones, y T6 realiza la escritura final de Q en ambas planificaciones. Las transacciones T4 y T6 realizan operaciones write(Q) sin haber realizado ninguna operacin read(Q). Este tipo de escrituras se denominan escrituras a ciegas. Silberschatz, Korth and Sudarshan 15.24 Database System Concepts - 5 th Edition, Sep 10, 2005. Recuperabilidad Antes se han estudiado las planificaciones que son aceptables desde el punto de vista de la consistencia de la base de datos asumiendo implcitamente que no haba fallos en las transacciones. La recuperabilidad estudia el efecto de los fallos en una transaccin durante una ejecucin concurrente. Si la transaccin T i falla, por la razn que sea, es necesario deshacer el efecto de dicha transaccin para asegurar la propiedad de atomicidad de la misma. En un sistema que permita la concurrencia es necesario asegurar tambin que toda transaccin T j que dependa de T i (es decir, T j lee datos que ha escrito T i ) se aborta tambin. Para alcanzar esta garanta, es necesario poner restricciones al tipo de planificaciones permitidas en el sistema.