You are on page 1of 24

Database System Concepts, 5th Ed.

Silberschatz, Korth and Sudarshan


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.

You might also like