Capítulo 6: Transacciones

Capítulo 6
Transacciones
Transacciones
 Situación: A veces hay secuencias de instrucciones que son
una unidad única desde el punto de vista del usuario de
BD.
 Ejemplo: Transferencia bancaria.
 ¿En el ejemplo anterior qué pasa si se inicia una
transferencia y se cae el sistema luego de sacar dinero de
una cuenta sin ponerlo en la cuenta de destino?
Transacciones
 Situación: Es común que muchas de estas secuencias de

operaciones se deben ejecutar completamente para que
tenga sentido.
 En caso de falla el resultado en la BD es como si ninguna de esas
instrucciones se hubiera ejecutado
 Esto obliga a delimitar secuencias de instrucciones que se deben
ejecutar indivisiblemente.
 Ejemplo: una transferencia bancaria. Sacar dinero de una
cuenta sin ponerlo en otra es un error.
Transacciones
 Definición: Una secuencia de operaciones que forma una
unidad lógica de trabajo se llaman transacciones.
 Una transacción es una unidad de ejecución que accede y
posiblemente actualiza varios ítems de datos.
 Un sistema gestor de BD debe asegurar la ejecución adecuada de
transacciones a pesar de fallas.
 Programación de Transacciones: Una transacción puede
estar escrita en:
 un lenguaje como SQL o
 un lenguaje de programación (p.ej. C++ o Java) con acceso a
bases de datos embebidos (usando protocolos como ODBC
o JDBC).
Transacciones
 ¿Qué tipos de instrucciones hay en el código de una
transacción? Ayuda: ¿si quisieran hacer una transferencia
bancaria de una cuenta a otra, qué pasos habría?
Transacciones
 ¿Qué tipos de instrucciones hay en el código de una
transacción?
 Tenemos instrucciones de los siguientes tipos:
 Para leer datos de la BD (que se mueven de disco a la
memoria principal)
 P.ej. leo el monto en la cuenta C desde la que quiero
transferir.
 Para operar en memoria con los datos leídos
 P.ej. al monto de C le resto la suma que quiero transferir.
 Para modificar la BD: por ejemplo: borrar, insertar, modificar
datos.
 Incluye mover datos de memoria principal al disco.
 P.ej. modifico el monto de C en la BD.
Transacciones
 Modelo de transacciones que usaremos:
 Los datos se mueven de disco a memoria principal y de memoria
principal a disco.
 Por ahora ignoramos operaciones de inserción y borrado.
 Los ítems de datos contienen valores simples de datos.
 Para referirse a ítems de datos se usan letras mayúscula (A, B, C,
…)
 Las transacciones acceden a los datos usando dos operaciones:
 Read(X) (o R(X), o r(x)): transfiere el ítem de datos X de la BD a
una variable también llamada X en la transacción que ejecuta la
lectura.
 Write(X) (o W(X), o w(X)): transfiere el valor de la variable X en
la memoria principal de la transacción que ejecuta la escritura
al ítem de datos X en la BD.
Transacciones
 Modelo de transacciones que usaremos (cont):

 En un sistema de BD real la operación de escritura no
necesariamente resulta en una actualización inmediata
de los datos en el disco;
 la operación de escritura puede ser almacenada
temporalmente en otro sitio y ejecutada en el disco
después.
 Por ahora, asumimos que la escritura almacena en
disco inmediatamente.
Concepto de Transacción
 Ejemplo: Transacción para transferir $50 de la cuenta A a

la cuenta B . ¿Cómo se escribe?
Concepto de Transacción
 Ejemplo: Transacción para transferir $50 de la cuenta A a

la cuenta B:
1. read(A)
2. A := A – 50
3. write(A)
4. read(B)
5. B := B + 50
6. write(B)
Transacciones
 Problema: ¿Cómo hacer para que una transacción se

ejecute indivisiblemente?
 Solución: Aplicar atomicidad.
 Atomicidad significa o todas las operaciones de la transacción son
reflejadas en la BD o ninguna lo es.
 Un Sistema gestor de BD debe manejar la ejecución
concurrente de transacciones en una forma que evita la
introducción de inconsistencias.
Transacciones
 Uno de los asuntos importantes a mantener en una BD es
la integridad.
 O sea que se deben cumplir las restricciones de
integridad.
 ¿Cómo se preserva la integridad luego de ejecutar
instrucciones simples de BD?
Transacciones
 Uno de los asuntos importantes a mantener en una BD es
la integridad.
 O sea que se deben cumplir las restricciones de
integridad.
 ¿Cómo se preserva la integridad luego de ejecutar
instrucciones simples de BD?
 Luego de ejecutarse una instrucción de alteración
de datos se chequean las restricciones de integridad,
 y si se viola alguna se rechaza la actualización.
Transacciones
 Problema: ¿Cómo mantener la integridad de la
BD cuando se ejecutan transacciones?
Transacciones
 Problema: ¿Cómo mantener la integridad de la
BD cuando se ejecutan transacciones?
 Solución: Luego de ejecutarse una transacción
completamente, la BD debe estar en un estado
íntegro.
 Una transacción debe ver una BD consistente.
 Durante la ejecución de una transacción la BD
puede ser inconsistente en algunos momentos.
 Cuando la transacción termina completamente, la
BD debe ser consistente.
Transacciones
 ¿Por qué motivos la BD puede quedar en un
estado no íntegro cuando se ejecutan
transacciones?
Transacciones
 Puede haber errores en el diseño de una

transacción que no garantizan la consistencia de la
BD.
 Problema: Hay que resolver qué hacer si una
transacción que se ejecutó completamente deja a
la BD en un estado inconsistente.
Transacciones
 Otra razón por la cual la BD puede quedar en un

estado inconsistente es que
 la transacción no logre completarse con éxito.
 O sea, se ejecute solo parte de la misma.
 Problema: asegurar que la BD permanece en un
estado consistente a pesar de fallas de sistema y
fallas de transacciones.
Transacciones
 Resumiendo, hay varios asuntos importantes a
considerar:
 Cortes de luz, fallas de hardware y caídas de
sistema.
 Errores en el código de la transacción que hace que
la misma falle.
 P. ej. Errores en tiempo de ejecución.
Transacciones
 La transacción puede estar diseñada perfecta-

mente y no haber fallas ni de sistema ni de la
transacción,
 y a pesar de eso la BD queda en un estado
inconsistente.
 ¿Cómo puede suceder esto?
Transacciones
 En la práctica para aprovechar los recursos y no

dejar esperando a los usuarios, se ejecutan varias
transacciones concurrentemente.
 Si no se tiene cuidado en cómo se ejecutan las
transacciones concurrentemente, la BD puede
quedar en un estado inconsistente.
 Problema: controlar la interacción entre
transacciones concurrentes para asegurar la
consistencia de la BD.
Atomicidad
 Transacción para trans-  Suponga que justo antes de la
ferir $50 de la cuenta A a ejecución de la transacción los
la cuenta B: valores de las cuentas A y B son
de $1000 y $2000, respectiva-
1. read(A)
mente.
2. A := A – 50
 Ahora asuma que durante la
3. write(A) ejecución de la transacción
4. read(B) ocurre una falla que previene
5. B := B + 50 que se complete con éxito.
6. write(B)  Supongamos que la falla sucede
luego del paso 3 y antes del
 Requisito de consistencia:
paso 6.
la suma de A y B no
cambia por la ejecución de  En este caso los valores de las
la transacción. cuentas A y B son de: $950 y
$2000.
Atomicidad
 Transacción para trans-  Luego el sistema destruyó
ferir $50 de la cuenta A a $50 como resultado de esta
la cuenta B: falla.
1. read(A)  Luego la suma A+B no se
2. A := A – 50 preserva más.
3. write(A)  Luego de la falla el estado
del sistema no refleja más el
4. read(B)
estado del mundo que debe
5. B := B + 50 capturar la BD.
6. write(B)  Llamamos a este estado,
 Requisito de consistencia: estado inconsistente.
la suma de A y B no  Tales inconsistencias no se
cambia por la ejecución de deben ver en un sistema de
la transacción. BD.
Atomicidad
 Problema 1: Hay que decidir qué hacer si una

transacción que no se completó con éxito deja a la
BD en un estado inconsistente.
 Problema 2: Hay que resolver qué hacer si una
transacción que se ejecutó completamente deja a la
BD en un estado inconsistente.
Atomicidad
 Solución (a los problemas 1 y 2): Aplicar
atomicidad.
 Atomicidad significa o todas las operaciones de la
transacción son reflejadas en la BD o ninguna lo es.
 ¿Cómo hacer para garantizar la atomicidad?
Atomicidad
atomicidad.
 Para garantizar la atomicidad, si la BD quedó en
estado inconsistente, hay que deshacer los efectos de
ejecutar la transacción.
 A esto se le llama retroceder la transacción.
 ¿Qué hay que hacer una vez que se completó una
transacción? Ayuda: es lo mismo que cuando hago
una instrucción de actualización a la BD.
Atomicidad
atomicidad.
 Para garantizar la atomicidad, si la BD quedó en
estado inconsistente, hay que deshacer los efectos de
ejecutar la transacción.
 A esto se le llama retroceder la transacción.
 Una vez completada la transacción se pueden
chequear las restricciones de integridad y si alguna
no se cumple, se puede retroceder la transacción.
Atomicidad
 ¿Cómo se puede implementar la atomicidad?
Atomicidad
 Una idea para aplicar atomicidad es que el sistema de BD
lleva la pista de los valores viejos de cualquier dato en los
cuales la transacción hizo una escritura.
 Esta información se escribe en un archivo llamado log.
 ¿Si la transacción no completa su ejecución, qué puede
hacer el sistema de BD? Ayuda: usar el log.
Atomicidad
 Una idea para aplicar atomicidad es que el sistema de BD
lleva la pista de los valores viejos de cualquier dato en los
cuales la transacción hizo una escritura.
 Esta información se escribe en un archivo llamado log.
 Si la transacción no completa su ejecución, el sistema de BD
restaura los valores viejos del log para hacer aparecer como
si la transacción nunca se hubiera ejecutado.
 La propiedad de atomicidad es manejada por la
componente del sistema de BD llamada sistema de
recuperaciones.
Consistencia
 La propiedad de Consistencia significa que La
ejecución aislada y completa de una transacción
preserva la consistencia de la BD.
 ¿Bajo qué premisas se hace esta definición?
Consistencia
 Premisas:
 No ocurre ningún tipo de falla.
 Tampoco hay otras transacciones ejecutándose
concurrentemente.
 ¿Qué dice esta definición de las transacciones?
Consistencia
 Premisas:
 No ocurre ningún tipo de falla.
 Tampoco hay otras transacciones ejecutándose
concurrentemente.
 Las transacciones no tienen errores de diseño que
puedan dejar a la BD en un estado inconsistente
al finalizar.
Durabilidad
 Situación: La transacción está bien diseñada, se

ejecutó completamente con éxito y no hubo
problemas con la concurrencia,
 pero aun así se viola la consistencia de la BD.
 ¿Por qué puede pasar esto?
Durabilidad
 Situación: La transacción está bien diseñada, se

ejecutó completamente con éxito y no hubo
problemas con la concurrencia,
 pero aun así se viola la consistencia de la BD.
 P. ej. Rotura de disco, robo de disco, terremoto,
ataques de virus, etc.
Durabilidad
 Problema: Garantizar en el caso anterior que a

pesar de esas fallas o daños no se viole la
 ¿Cómo lograr esto?
Durabilidad
 Problema: Garantizar en el caso anterior que a

pesar de esas fallas o daños no se viole la
 Solución: Garantizar la propiedad de durabilidad.
 Durabilidad. Después que una transacción se
completa exitosamente, los cambios que ha hecho
a la BD persisten, incluso si hay fallas de sistema.
Durabilidad
 ¿Qué significa el requisito de durabilidad para la
transacción?
1. read(A)
2. A := A – 50
3. write(A)
4. read(B)
5. B := B + 50
6. write(B)
Durabilidad
 ¿Qué significa el requisito de durabilidad para la
transacción?
1. read(A)
2. A := A – 50
3. write(A)
4. read(B)
5. B := B + 50
6. write(B)
 una vez que el usuario ha sido notificado que la

transacción se ha completado (i.e., que la
transferencia de $50 ha tenido lugar), las
actualizaciones a la BD por la transacción deben
persistir a pesar de fallas.
Estructura de almacenamiento
 Almacenamiento volátil: Memoria principal y memoria

caché.
 ¿Qué pasa con la Información residente en almacenamiento
volátil si se cae el sistema?

caché.
 Información residente en almacenamiento volátil no sobrevive
caídas del sistema.
 Almacenamiento no volátil: discos magnéticos, memoria
flash, medios ópticos, cintas magnéticas usados para
almacenar archivos.
 ¿Qué pasa si falla uno de estos dispositivos?

caché.
almacenar archivos.
 Estos dispositivos son susceptibles a fallar, lo que puede provocar
pérdida de información.
 ¿Qué pasa con la Información residente en almacenamiento no
volátil si se cae el sistema?

caché.
almacenar archivos.
 Estos dispositivos son susceptibles a fallar, lo que puede provocar
pérdida de información.
 Información residente en almacenamiento no volátil sobrevive
 Almacenamiento estable: información en este tipo de

almacenamiento nunca se pierde.
 En teoría esto no se puede garantizar. ¿Por qué?
 ¿Qué se puede hacer para tener almacenamiento estable?
 Almacenamiento estable: información en este tipo de

almacenamiento nunca se pierde.
 En teoría esto no se puede garantizar. ¿Por qué?
 Para obtener almacenamiento estable replicamos los datos en
varios medios de almacenamiento no volátil (por ej. discos) con
modos de falla independientes.
 Este tipo de técnicas hacen la pérdida de información mucho
menos probable.
 ¿Cómo lograr que una transacción sea durable? Ayuda:

considere el tipo de almacenamiento en su respuesta.
 ¿Cómo lograr que una transacción sea durable?

 Para que una transacción sea durable, sus cambios
necesitan ser escritos en almacenamiento estable.
 ¿Cómo lograr que una transacción sea atómica? Ayuda:
considere el tipo de almacenamiento en su respuesta.
 ¿Cómo lograr que una transacción sea durable?

 Para que una transacción sea durable, sus cambios
necesitan ser escritos en almacenamiento estable.
 ¿Cómo lograr que una transacción sea atómica?
 Para que una transacción sea atómica, registros log
necesitan ser escritos en almacenamiento estable antes
que se hagan cambios a la BD en disco.
 Conclusión: el grado en el cual un sistema asegura
durabilidad y atomicidad depende de cuán estable la
implementacion del almacenamiento estable realmente
es.
Planificaciones
 ¿Cómo definirían lo que es una planificación?
Planificaciones
 Planificaciones: secuencias que indican el orden
cronológico en el cual las instrucciones de
transacciones concurrentes son ejecutadas.
 No cualquier secuencia de instrucciones que vienen de
las transacciones involucradas es una planificación
válida. ¿Por qué?
 ¿Entonces qué requisitos debe cumplir una
planificación?
Planificaciones
 Planificaciones: secuencias que indican el orden
cronológico en el cual las instrucciones de
transacciones concurrentes son ejecutadas.
 Una planificación para un conjunto de transacciones
debe consistir de todas las instrucciones de esas
transacciones.
 Debe preservar el orden en el cual las instrucciones
aparecen en cada transacción individual.
Planificaciones
 Dos planificaciones son equivalentes si

comenzando con la ejecución en el mismo estado
del sistema, terminan dejando al sistema en el
mismo estado.
 En particular terminan dejando la BD en el mismo
estado.
Planificaciones
 Dos planificaciones son equivalentes si

comenzando con la ejecución en el mismo estado
del sistema, terminan dejando al sistema en el
mismo estado.
 En particular terminan dejando la BD en el mismo
estado.
Ejemplos de Planificaciones
 T1 transfiere $50 de A a B, y T2 transfiere 10% del balance de
A a B. La siguiente es una planificación secuencial, en la cual
T1 es seguida porT2.
Planificación 1
Problemas al ejecutar
transacciones concurrentemente
 La planificación concurrente de
la izquierda no preserva el valor
de la suma de A + B.
 Asumimos que Inicialmente:
A = 400 y B = 300.
 Inicialmente A + B = 700
 Luego de ejecutar la
planificación:
 A = 350 y B = 340
 A + B = 690
 Por lo tanto el sistema destruyó
10.
Aislamiento
 Mensaje: si no tenemos cuidado con cómo se

ejecutan concurrentemente las transacciones, la BD
puede terminar en un estado inconsistente.
 Problema: controlar la interacción entre
transacciones concurrentes para asegurar la
Aislamiento
 Solución: Garantizar la propiedad del aislamiento.

 Aislamiento: La ejecución concurrente de las
transacciones resultan en un estado de sistema que es
equivalente al estado que se hubiera obtenido si esas
transacciones se hubieran ejecutado una a la vez en algún
orden.
 El aseguramiento del aislamiento es responsabilidad de
una componente del sistema de BD llamada sistema de
control de concurrencia.
Aislamiento
 ¿Cómo se puede asegurar trivialmente el

aislamiento?
Aislamiento
 ¿Cómo se puede asegurar trivialmente el

aislamiento?
 Ejecutando las transacciones secuencialmente, esto
es, una después de la otra.
 Sin embargo, ejecutar transacciones concurrente-
mente tiene múltiples beneficios.
Aislamiento
 ¿La planificación de abajo cumple la propiedad
del aislamiento?
T1 T2
1. read(A)
2. A := A – 50
3. write(A)
read(A), read(B), print(A+B)
4. read(B)
5. B := B + 50
6. write(B)
Aislamiento
 ¿La planificación de abajo cumple la propiedad
del aislamiento?
T1 T2
1. read(A)
2. A := A – 50
3. write(A)
read(A), read(B), print(A+B)
4. read(B)
5. B := B + 50
6. write(B)
 Si entre los pasos 3 y 6 de T1, a otra transacción se

le permite acceder a la BD parcialmente
actualizada, va a ver una BD inconsistente (la
suma A + B va a ser menor de lo que debería ser).
Propiedades ACID
 Resumen: cuando se trabaja con transacciones

deberían satisfacerse las propiedades ACID:
 Atomicidad (implementada por el SGBD)
 Consistencia
 Aislamiento (implementada por el SGBD) – Isolation en
inglés.
 Durabilidad
 SGBD: Sistema gestor de bases de datos
Estados de una Transacción
 Se pueden definir los estados por los que va pasando

una transacción a medida que va siendo procesada
por el SGBD.
 ¿Para qué sirve esto?
 Se pueden definir los estados por los que va pasando

una transacción a medida que va siendo procesada
por el SGBD.
 ¿Para qué sirve esto?
 Para comprender mejor el tratamiento de las transacciones.
 Para definir conceptos que serán usados más adelante los
cuales nos permitirán expresarnos con precisión.
 Activa: la transacción
permanece en este estado
mientras se está
ejecutando.
 Parcialmente comprome-
tida: después que la
última instrucción ha sido
ejecutada.
 Falló: después de
descubrir que la ejecución
normal no puede
continuar.
 Abortada: después que la

transacción ha sido retro-
cedida y la BD restaurada
a su estado antes del
comienzo de la transac-
ción. Dos opciones luego
que ha sido abortada:
 Reiniciar la transacción–
solo si no tiene errores
lógicos internos.
 Matar la transacción.
 Comprometida: luego de
completarse exitosamen-
te.
Ejecuciones Concurrentes
 Varias transacciones tienen permitido ejecutarse
concurrentemente en el sistema.
 ¿Qué ventajas tiene la ejecución concurrente de
transacciones?
Ejecuciones Concurrentes
 Varias transacciones tienen permitido ejecutarse
concurrentemente en el sistema.
 ¿Qué ventajas tiene la ejecución concurrente de
transacciones?
 Utilización del procesador y del disco aumentados,
una transacción puede estar usando la CPU mientras
otra está leyendo o escribiendo en el disco.
 Tiempo de respuesta promedio reducido, para
transacciones: transacciones cortas no necesitan
esperar después de transacciones largas.
 Esquemas de control de concurrencia: son mecanismos
para alcanzar aislamiento, i.e., para controlar la
interacción entre las transacciones concurrentes para
prevenir que ellas destruyan la consistencia de la BD.
Algunas instrucciones para transacciones
 Una transacción es delimitada entre por sentencias de
la forma begin transaction y end transaction.
o La transacción consiste de todas las operaciones
ejecutadas entre esas dos sentencias.
 Introducimos la instrucción commit para indicar que
la transacción entró en el estado de comprometida.
 Una transacción que completa exitosamente su
ejecución va a tener instrucciones commit como la
última sentencia.
 Una transacción que falla en completar su ejecución
va a tener una instrucción abort como su última
sentencia.
Planificaciones equivalentes
 Suposición Básica: cada transacción preserva la consistencia de
la BD.
 Consequencia: la ejecución secuencial de un conjunto de
transacciones preserva la consistencia de la BD.
 Repaso: Dos planificaciones son equivalentes si comenzando
con la ejecución en el mismo estado del sistema, terminan
dejando al sistema en el mismo estado.
 Definición: Una planificación (posiblemente concurrente) es
secuenciable si es equivalente a una planificación secuencial.
Secuencialidad
 Problema: ¿Cómo garantizar la propiedad del

aislamiento? (repaso)
Secuencialidad
 Problema: ¿Cómo garantizar la propiedad del

aislamiento? (repaso)
 Solución: Producir planificaciones secuenciables.
 Sean T1 y T2 las transacciones definidas previamente. La
siguiente planificación no es una planificación secuencial,
pero es equivalente a la planificación T1 seguido por T2.
Planificación 3
 La siguiente planificación concurrente no preserva el
valor de la suma de A + B. (Ya lo probamos)
Planificación 4
Secuencialidad
 El programador podría proponer una planificación que
aproveche lo más posible la concurrencia.
 ¿Cómo chequear si esta planificación es secuenciable?
Secuencialidad
 El programador podría proponer una planificación que
aproveche lo más posible la concurrencia.
 ¿Cómo chequear si esta planificación es secuenciable?
 Una idea es ir probando las distintas permutaciones de las
transacciones de la planificación
 y para cada permutación ver si se cumple la equivalencia con la
planificación propuesta.
Secuencialidad
 ¿Qué les parece la idea anterior?
Secuencialidad
 ¿Qué les parece la idea anterior?
 Esto es algo muy trabajoso y parece ser complicado. ¿Por
qué?
 Puede haber muchas permutaciones de transacciones.
 Además nos fijamos muchas veces en las operaciones distintas de
read y write.
 Por ejemplo en planificación 4 para ver que no es secuenciable
hacemos eso.
 Veremos cómo eliminar esta causa
Secuencialidad
 Problema: ¿Cómo probar que una planificación es

secuenciable en forma más efectiva y sencilla?
 Solución: Definir nociones de equivalencia más
fuertes que la equivalencia común (o sea,
contenidas en ella),
 de modo que verificar si una planificación es
equivalente a una planificación secuencial usando
una de esas nociones de equivalencia más fuerte
sea bastante sencillo.
Secuencialidad
 Idea genial: definir formas de equivalencia que
solo dependen de las operaciones read y write.
 ¿Qué consecuencias tiene esta idea?
Secuencialidad
 Idea genial: definir formas de equivalencia que
solo dependen de las operaciones read y write.
 ¿Qué consecuencias tiene esta idea?
 Se pueden ignorar operaciones distintas de las
instrucciones read y write.
 Las transacciones pueden ejecutar cómputos
arbitrarios en los datos en búferes locales entre las
lecturas y escrituras.
 Se pueden usar planificaciones simplificadas que
consistirán solo de instrucciones read y write.
 Luego, para chequear secuencialidad no será
necesario ver instrucciones distintas de read y write
Secuencialidad
 De acuerdo a la idea anterior consideramos las
siguientes nociones de equivalencia más fuertes:
1. Secuencialidad por conflictos
2. Secuencialidad por vistas
Secuencialidad por Conflictos
 Consideremos una planificación S en la cual hay dos

instrucciones consecutivas I y J de las transacciones Ti y Tj
respectivamente (I <> J).
 ¿Qué pasa si se intercambia el orden de I y J?
 Consideremos una planificación S en la cual hay dos

instrucciones consecutivas I y J de las transacciones Ti y Tj
respectivamente (I <> J).
 Si I y J se refieren a distintos elementos de datos, se pueden
intercambiar I y J sin afectar los resultados de toda instrucción en
la planificación.
 Si I y J se refieren al mismo elemento de datos Q, entonces el
orden de los dos pasos puede importar.
 Como se usan instrucciones read y write hay 4 casos a considerar:
1. l = read(Q), J = read(Q). ¿Importa el orden de estas
instrucciones?
1. l = read(Q), J = read(Q). El orden de I y J no importa.
2. l = read(Q), J = write(Q). ¿Importa el orden de I y J?
2. l = read(Q), J = write(Q). El orden de I y J importa.
3. I = write(Q), J = read(Q). ¿Importa el orden de I y J?
3. I = write(Q), J = read(Q). El orden de I y J importa.
4. l = write(Q), J = write(Q). ¿Importa el orden de I y J? (Analizar
distintos casos de lo que viene después de I y J)
3. I = write(Q), J = read(Q). El orden de I y J importa.
4. l = write(Q), J = write(Q).
• Si luego viene un read(Q) el orden de I y J importa.
• Sino y no viene un write(Q), el orden de I y J afectan el valor
final de Q en el estado de la base de datos; por eso el orden
de I y J importan.
 Definición: Instrucciones I y J consecutivas de las

transacciones Ti y Tj respectivamente, están en
conflicto si y solo si existe algún ítem Q accedido
por l y J, y al menos una de esas instrucciones
escribe Q.
 La instrucción write(A) de
T1 entra en conflicto con
la instrucción read(A) de
T2.
 La instrucción write(A) de
T2 no entra en conflicto
con la instrucción read(B)
de T1, porque las dos
instrucciones acceden a
diferentes items de datos.
 Intuitivamente, un conflicto entre dos instrucciones fuerza

un orden temporal entre ellas.
 ¿Y si no hay conflicto entre dos instrucciones hace falta
mantener el orden temporal entre ellas?
 Intuitivamente, un conflicto entre dos instrucciones fuerza

un orden temporal entre ellas.
 Sean I y J instrucciones consecutivas de una planificación S.
 Si I y J son instrucciones de diferentes transacciones y I y J no
entran en conflicto,
 entonces podemos intercambiar el orden de I y J para
producir una nueva planificación S’.
 S es equivalente a S’, debido a que todas las instrucciones
aparecen en el mismo orden en ambas planificaciones
excepto para I y J , cuyo orden no interesa.
S  Como la instrucción write(A) de

T2 en la planificación S no entra
en conflicto con read(B) de T1,
podemos intercambiar esas
instrucciones para generar una
planificación equivalente S’
 Sin importar cuál sea el estado
inicial ambas planificaciones
S’ producen el mismo estado
final.
 Continuando con el intercambio de
S’ instrucciones no conflictivas:
 Intercambiar el read(B) deT1 con el
1
read(A) de T2 .
2
 Intercambiar el write(B) de T1 con el

write(A) de T2 . 2
 Intercambiar el write(B) de T1 con el

read(A) de T2 . 2
 El resultado final de estos inter-

cambios es la planificación S”.
S”  Luego hemos mostrado que la
planificación concurrente S de
filmina anterior es equivalente a
planificación secuencial S”.
 Si una planificación S puede ser transformada en una

planificación S´ por una serie de intercambios de
instruccionesno conflictivas, decimos que S y S´ son
equivalentes por conflictos.
 Decimos que una planificación S es secuenciable por
conflictos si es equivalente por conflictos a una
planificación secuencial.
 Ejemplo: Sea la planificación 3 a la
derecha S
 ¿Será que la misma es secuenciable

por conflictos?
 Ejemplo: Sea la planificación S a la
derecha S
 ¿Será que la misma es secuenciable

por conflictos?
 Sí, porque puede ser transformada en
la planificación secuencial donde T2
sigue a T1, por una serie de
intercambios de instrucciones que no
están en conflictos.
 Ejemplo: Sea la planificación
 ¿Será que la misma es secuenciable por conflictos?

 Ejemplo: Sea la planificación

 No, porque no podemos intercambiar instrucciones en la
planificación de arriba para obtener < T3, T4 >, o < T4, T3 >.
Secuencialidad por Vistas
 La definición de equivalencia por vistas considera:

 Reglas de preservación de propiedades de
instrucciones read/write para las transacciones en las
planificaciones que se están considerando.
 Considera tres reglas de ese tipo.
 Definición: Sean S y S´ dos planificaciones con el mismo
conjunto de transacciones. S y S´ son equivalentes por vistas
si las siguientes 3 condiciones se cumplen:
1. Para cada item de datos Q, si la transacción Ti lee el valor
inicial de Q en S, entonces la transacción Ti debe en S´,
también leer el valor inicial de Q.
2. Para cada item de datos Q si la transacción Ti ejecuta
read(Q) en S, y el valor fue producido por la transacción Tj
(if any), entonces la transacción Ti debe en S´ también leer
el valor de Q que fue producido por la transacción Tj.
3. Para cada item de datos Q, la transacción (si la hay) que
realiza el último write(Q) en S debe realizar el último
write(Q) en S´.
 Como se puede ver, la equivalencia por vistas

también se basa solo en instrucciones read y
write.
 Definición: Una planificación S es sequenciable
por vistas si es equivalente por vistas a una
planificación secuencial.
 ¿Qué relación hay entre la secuencialidad por

vistas y la secuencialidad por conflictos?
 ¿Qué relación hay entre la secuencialidad por

vistas y la secuencialidad por conflictos?
 Proposición: Toda planificación secuenciable por
conflictos es también secuenciable por vistas.
 Prueba: ejercicio de la práctica.
 Ejemplo: Sea la planificación 9 de abajo
 ¿Será que la misma es secuenciable por vistas?


 Sí es secuenciable por vistas.

 Sí es secuenciable por vistas.
 No es secuenciable por conflictos.
 write(Q) es escrituras a ciegas en una transacción T si antes de
write(Q) no aparece ningún read(Q) en T.
 Resultado: Cada planificación secuenciable por vistas que no es
secuenciable por conflictos tiene escrituras a ciegas.
Otras Nociones de Secuencialidad
 ¿Será que siempre que una
planificación es secuenciable lo es por
vistas o por conflictos?
Otras Nociones de Secuencialidad
 ¿Será que siempre que una
planificación es secuenciable lo es por
vistas o por conflictos?
 La respuesta es no.
 Ejemplo: La planificación 8 a la dere-
cha produce el mismo resultado que
la planificación secuencial < T1, T5 >,
pero no es ni secuenciable por
conflictos ni secuenciable por vistas
con ella.
 Determinar la equivalencia requiere
análisis de operaciones distintas de
read y write.
Chequeo de Secuencialidad
 Ya hemos visto nociones de secuencialidad que

son relativamente fáciles de chequear a mano.
 Meta: Pero a uno le gustaría poder chequearlas
automáticamete y eficientemente.
 ¿Por qué? Así el programador no se tiene que
preocupar por esto.
 Situación: calcular todas las permutaciones de un
conjunto de transacciones y luego chequear
secuencialidad (por conflictos o por vistas) es
demasiado costoso.
 Si tengo n transacciones, hay n! permutaciones.
 En relación a la secuencialidad por conflictos surgen los

siguientes problemas:
 Problema I: ¿Cómo comprobar automáticamente y
eficientemente que una planificación es secuenciable por
conflictos?
 Problema II: ¿Si la planificación es secuenciable por
conflictos, cómo obtener eficientemente una secuencia
equivalente por conflictos?
Grafo de Precedencia
 Considerar una planificación de un conjunto de

transaccionesT1, T2, ..., Tn
 Definición: El Grafo de precedencia es un grafo
dirigido donde:
 los vértices son las transacciones (nombres).
Dibujamos un arco de Ti a Tj si las dos transacciones entran
en conflicto, y Ti accede antes al elemento de datos en el
cual el conflicto ocurre.
Podemos etiquetar un arco por el ítem que fue accedido.
Grafo de Precedencia
 Ejemplo: ¿Qué significa el siguiente grafo de precedencia?
y
Planificación A
T1 T2 T3 T4 T5
read(X)
read(Y)
read(Z)
read(V)
read(W)
read(W)
read(Y)
write(Y)
write(Z)
read(U)
read(Y)
write(Y)
read(Z)
write(Z)
read(U)
write(U)
Grafo de Precedencia de Planificación A
T1 T2
T4
T3
por Conflictos
 Solución al problema I: Teorema 1: Una planificación es

secuenciable por conflictos si y solo si el grafo de precedencia
es acíclico.
 Algoritmos de detecciones de ciclos existen los cuales toman
orden n2 , donde n es el número de vértices en el grafo.
(mejores algoritmos toman n + e donde e es el número de
arcos).
Chequeo de Secuencialidad por Conflictos
 Proposicion 1: Sea P una planicación y sea G el grafo de

precedencia de P. Sea Ti Tk un arco de G. Si P es
equivalente a P’ en cuanto a conflictos y P’ es secuencial,
entonces en P’ aparece Ti antes que Tk.
 Prueba: Como Ti Tk existen un par de de instrucciones en P,
primero una de Ti y luego otra de Tk, y ambas son conflictivas.
Supongamos que esas instrucciones son Wi(Q) (i.e. Ti ejecuta
write(Q)) y Wk(Q) (i.e. Tk ejecuta write(Q)). Entonces P tiene la
forma:
… Wi(Q) ;… Wk(Q);…
Si P fuera equivalente por conflictos a una planificación
secuencial P’ donde Tk aparece antes que Ti, entonces para
llegar de P a P’ en algún momento habría que intercambiar
Wi(Q) y Wk(Q). Lo cual no se puede hacer. Por lo tanto en P’
aparece Ti antes que Tk. QED
 Prueba del Teorema 1: Si hay un ciclo en el grafo de precedencia de P

que involucra n transacciones
T1 T2 … Tn T1
entonces por la proposición 1 en un orden secuencial hipotético, las
acciones de T1 deben preceder a aquellas de T2 , las que a su vez
preceden a aquellas de T3 y así sucesivamente hasta Tn . Pero para las
acciones de Tn que vienen luego de las de T1, se pide que ellas
también precedan a las acciones de T1, debido al arco Tn T1 . Por lo
tanto concluimos que si hay un ciclo en el grafo de precedencia de P,
entonces esta planificación no es secuenciable por conflictos.
La prueba de la conversa se hace por inducción en el número de
transacciones involucradas en P. Si hay una sola transacción en P,
entonces P ya es secuenciable por conflictos. Supongamos que P
consiste de las acciones de n transacciones:
T1 , T2 , … ,Tn
Suponemos que P tiene un grafo de precedencia acíclico.

En todo grafo acíclico finito hay al menos un nodo al que
no le llega ningún arco. Sea dicho nodo Ti. Entonces no
puede existir una acción A en P tal que:
1.involucra una transacción Tj con j ≠ i,
2.precede alguna acción de Ti, y
3.entra en conflicto con esa acción.
Por lo tanto es posible intercambiar todas las acciones de
Ti, manteniéndolas en orden pero moviéndolas al frente
de P. La planificación ha tomado ahora la forma:
(Acciones de Ti) Q,
Donde Q = (acciones de las otras n-1 transacciones).
Debido a que las acciones de Q mantienen el mismo orden relativo

que tenían en P, el grafo de precedencia para Q es el mismo que el
grafo de precedencia para P, excepto que el nodo para Ti y todos los
arcos que salen de Ti se pierden. Como el grafo de precedencia de P es
acíclico, concluimos que el grafo de precedencia de Q es también
acíclico. Como Q involucra n-1 transacciones la hipótesis inductiva se
puede aplicar al mismo. Entonces Q es equivalente por conflictos a
una planificación Q’. Por lo tanto P es equivalente por conflictos a la
planificación secuencial
(acciones de Ti) Q’
La inducción es completa y concluimos que toda planificación con un
grafo de precedencia acíclico es secuenciable por conflictos. QED.
 ¿Si una planificación P es secuenciable por conflictos, cómo

determinar las planificaciones secuenciales equivalentes a P?
 Solución al problema II: Proposición 2: Si el grafo de
precedencia es acíclico, el orden de secuencialidad puede ser
obtenido por un ordenamiento topológico del grafo.
 Definición: Un orden topológico en un grafo dirigido G es un
orden lineal de sus vértices tal que para todo arco dirigido u 
v del vértice u al vértice v, u viene antes que v en el orden
topológico.
 Un orden topológico es posible si el grafo dirigido es acícilico.
 Ejemplo: Vimos que la planificación A tiene grafo de

precedencia:
 ¿Cuál es un orden de secuencialidad para la planificación

A?
 Ejemplo: Vimos que la planificación A tiene grafo de

precedencia:
 un orden de secuencialidad para la planificación A es

T5  T1  T3  T2  T4 .
 Calcular un orden topológico de un grafo de

precedencia es eficiente.
 Hay algoritmos que calculan un orden topológico en un
grafo que son lineales en la cantidad de nodos y de
arcos del grafo.
Control de Concurrencia vs
Chequeos de Secuencialidad
 Situación: Chequear si una planificación es secuenciable

luego que ha sido ejecutada es demasiado tarde.
 Idea 1: esto podría chequearse por anticipado.
 ¿Qué les parece esta idea?
Control de Concurrencia vs
Chequeos de Secuencialidad
 Situación: Chequear si una planificación es secuenciable

luego que ha sido ejecutada es demasiado tarde.
 Idea 1: esto podría chequearse por anticipado.
 Que el programador proponga planificaciones a ser
chequeadas es algo también pesado y trabajoso,
 que puede involucrar más de un intento.
 Idea 2: que el SGBD reciba pedido de ejecución de una
nueva transacción T y construya la planificación secuenciable
(que involucra T) automáticamente.
 Este es tema del próximo capítulo.
Efectos de fallas de las transacciones
durante ejecución concurrente
 ¿Qué consecuencias tienen las fallas en transacciones

cuando hay transacciones ejecutándose concurrente-
mente?
 La respuesta a esta pregunta depende del orden en que se
compromenten las transacciones.
 Si no se cumplen ciertas reglas en relación a cuándo se
deben comprometer las transacciones,
 entonces surgen situaciones no deseadas.
 Analizaremos dos tipos de situaciones no deseadas que
podemos tener y cómo hacer para evitarlas.
 ¿Qué pasa en el ejemplo de al lado si T9

se compromete inmediatamente
después del read?
 ¿Qué pasa en el ejemplo de al lado si T9

se compromete inmediatamente
después del read?
 Si T8 debe abortar, T9 debería tener la
lectura y posiblemente mostraría al
usuario un estado de la BD inconsistente.
 ¿Cómo generalizar este ejemplo?
 Mensaje: Generalizando el ejemplo anterior:
 si una transacción Tk lee elementos de datos
previamente escritos por una transacción Ti y
 Tk se compromete antes que Ti y Ti debe abortar
después que Tk se comprometió,
 Consecuencia (situación indeseada): Tk va a haber leido
valores de datos que no existen.
 Luego es necesario que la BD asegure que este
tipo de situaciones no ocurra.
 Problema: ¿Qué tendría que pedirse para impedir situaciones

como la anterior?
Planificaciones recuperables
 Problema: ¿Qué tendría que pedirse para impedir situaciones

como la anterior?
 Solución: Que las planificaciones sean recuperables.
 Planificación Recuperable: si una transacción Tk lee elementos de
datos previamente escritos por una transacción Ti , la operación
comprometer de Ti aparece antes que la operación comprometer
de Tk.
 Luego el SGBD debe asegurar que las planificaciones sean
recuperables.
 Ejemplo: considere la siguiente planificación donde ninguna
de las transacciones se ha coomprometido aun
 ¿Qué sucede si T10 falla?

 Ejemplo: considere la siguiente planificación donde ninguna
de las transacciones se ha coomprometido aun
 ¿Qué sucede si T10 falla?

 T11 y T12 deben también retrocederse.
 ¿Cómo se puede generalizar el ejemplo anterior?
 Mensaje: Generalización del ejemplo anterior:
 En una planificación se tienen transacciones T1, …, Tn donde
para todo i < n, Ti+1 lee elemento de datos escritos por Ti y
 después de que Tn leyó elemento escrito por Tn-1 , T1 falla.
 Consecuencia (Situación Indeseada): Entonces T1,…, Tn van a
tener que ser retrocedidas.
 Retrocesos en Cascada: ocurre cuando una falla de una
transacción lleva a una serie de retrocesos de
transacciones.
 ¿Cuáles son los costos de los retrocesos en cascada?
 Mensaje: Generalización del ejemplo anterior:
 En una planificación se tienen transacciones T1, …, Tn donde
para todo i < n, Ti+1 lee elemento de datos escritos por Ti y
 después de que Tn leyó elemento escrito por Tn-1 , T1 falla.
 Consecuencia (Situación Indeseada): Entonces T1,…, Tn van a
tener que ser retrocedidas.
 Retrocesos en Cascada: ocurre cuando una falla de una
transacción lleva a una serie de retrocesos de
transacciones.
 Costos: tener retrocesos en cascada puede llevar a:
 deshacer una cantidad significativa de trabajo y
 tener que repetirlo.
 Problema: ¿Qué se puede pedir para evitar que ocurran
retrocesos en cascada?
Planificaciones sin cascadas
 Solución: Usar Planificaciones sin cascadas:
 Planificación sin cascadas: para cada par de transacciones Ti y
Tk tales que Tk lee un elemento de datos previamente escrito
por Ti, la operación comprometer de Ti aparece antes de la
operación read de Tk.
 ¿Cual es la consecuencia de tener planificaciones sin
cascada?
 Solución: Usar Planificaciones sin cascadas:
 Planificación sin cascadas: para cada par de transacciones Ti y
Tk tales que Tk lee un elemento de datos previamente escrito
por Ti, la operación comprometer de Ti aparece antes de la
operación read de Tk.
 ¿Cual es la consecuencia de tener planificaciones sin
cascada?
 En una planificación sin cascadas, si una transacción T lee
elementos de datos escritos por otra transacción T’, entonces
 las instrucciones de T’ deben estar antes que las
instrucciones de lectura de elementos de datos en T.
 Proposición: Toda planificación sin cascadas es también

recuperable.
 Es deseable restringir las planificaciones a solo aquellas
que son sin cascadas.

Capítulo 6: Transacciones

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Capítulo 6: Transacciones

Cargado por

Copyright:

Formatos disponibles

Capítulo 6

 Situación: Es común que muchas de estas secuencias de

 Modelo de transacciones que usaremos (cont):

 Ejemplo: Transacción para transferir $50 de la cuenta A a

 Ejemplo: Transacción para transferir $50 de la cuenta A a

 Problema: ¿Cómo hacer para que una transacción se

 Puede haber errores en el diseño de una

 Otra razón por la cual la BD puede quedar en un

 La transacción puede estar diseñada perfecta-

 En la práctica para aprovechar los recursos y no

 Problema 1: Hay que decidir qué hacer si una

 Situación: La transacción está bien diseñada, se

 Situación: La transacción está bien diseñada, se

 Problema: Garantizar en el caso anterior que a

 Problema: Garantizar en el caso anterior que a

 una vez que el usuario ha sido notificado que la

 Almacenamiento volátil: Memoria principal y memoria

 Almacenamiento volátil: Memoria principal y memoria

 Almacenamiento volátil: Memoria principal y memoria

 Almacenamiento volátil: Memoria principal y memoria

 Almacenamiento estable: información en este tipo de

 Almacenamiento estable: información en este tipo de

 ¿Cómo lograr que una transacción sea durable? Ayuda:

 ¿Cómo lograr que una transacción sea durable?

 ¿Cómo lograr que una transacción sea durable?

 Dos planificaciones son equivalentes si

 Dos planificaciones son equivalentes si

 Mensaje: si no tenemos cuidado con cómo se

 Solución: Garantizar la propiedad del aislamiento.

 ¿Cómo se puede asegurar trivialmente el

 ¿Cómo se puede asegurar trivialmente el

 Si entre los pasos 3 y 6 de T1, a otra transacción se

 Resumen: cuando se trabaja con transacciones

 Se pueden definir los estados por los que va pasando

 Se pueden definir los estados por los que va pasando

 Abortada: después que la

 Problema: ¿Cómo garantizar la propiedad del

 Problema: ¿Cómo garantizar la propiedad del

 Problema: ¿Cómo probar que una planificación es

 Consideremos una planificación S en la cual hay dos

 Consideremos una planificación S en la cual hay dos

 Definición: Instrucciones I y J consecutivas de las

 Intuitivamente, un conflicto entre dos instrucciones fuerza

 Intuitivamente, un conflicto entre dos instrucciones fuerza

S  Como la instrucción write(A) de

 Intercambiar el write(B) de T1 con el

 Intercambiar el write(B) de T1 con el

 El resultado final de estos inter-

 Si una planificación S puede ser transformada en una

 ¿Será que la misma es secuenciable

 ¿Será que la misma es secuenciable

 Ejemplo: Sea la planificación

 ¿Será que la misma es secuenciable por conflictos?

 Ejemplo: Sea la planificación

 ¿Será que la misma es secuenciable por conflictos?

 La definición de equivalencia por vistas considera:

 Como se puede ver, la equivalencia por vistas

 ¿Qué relación hay entre la secuencialidad por

 ¿Qué relación hay entre la secuencialidad por

 ¿Será que la misma es secuenciable por vistas?

 ¿Será que la misma es secuenciable por vistas?

 ¿Será que la misma es secuenciable por vistas?

 Ya hemos visto nociones de secuencialidad que