Ing. Priscila Cedillo O. Mgt.

Base de Datos 2

CAPÍTULO NO. 1
TRANSACCIONES
Contenidos

 Transacciones
 Concepto de transacción
 Propiedades ACID
 Recuperación:
 Técnica de la bitácora
 Recuperación en distintos tipos de fallas.
 Confirmación de dos fases.
 Control de Concurrencia
 Método de bloqueo
 Conflictos
 Protocolo de bloqueo
 Transacción bien formada
 Solución a los problemas de actualización perdida.
INTRODUCCION

 Transacción: Unidad lógica de la ejecución de un

programa que accede y posiblemente actualiza
varios elementos de datos.
 Una transacción debe ver una base de datos
consistente.
 Durante la ejecución de una transacción la base de
datos puede quedar inconsistente temporalmente.
 Una transacción exitosa lleva a que la base de datos
quede consistente, los cambios persisten aún
cuando hayan fallos en el sistema.
 Las transacciones pueden ejecutarse en paralelo
(concurrentemente).
INTRODUCCION

 Una vez ejecutada con éxito una transacción,

sus efectos deben persistir en la base de
datos.
 Un fallo en el sistema NO debe tener como
consecuencia que la base de datos se olvide
de una transacción que haya completado con
éxito. Esta propiedad se llama
DURABILIDAD.
INTRODUCCION…

 Cuando existen transacciones concurrentes,

si no se controlan las actualizaciones de los
datos compartidos, existe la posibilidad de
que otras transacciones vean estados
intermedios inconsistentes.
 Los sistemas de bases de datos deben
proporcionar los mecanismos para aislar las
transacciones de otras transacciones
concurrentes.
 Esta propiedad se denomina aislamiento.
CONCEPTO DE TRANSACCION

 Unidad de la ejecución de un programa que

accede y posiblemente actualiza varios
elementos de datos.
 Se inicia por la ejecución de un programa de
usuario.
 Está delimitada por instrucciones de la forma
inicio transacción y fin transacción.
PROPIEDADES ACID

 Acrónimo de:

 Atomicity = Atomicidad.
 Consistency = Consistencia.
 Isolation = Aislamiento.
 Durability = Durabilidad.
ATOMICIDAD

 O todas las operaciones de la transacción se

realizan adecuadamente en la base de datos
o ninguna de ellas.
 Ejemplo:
 Una transacción que transfiere
$50 de la cuenta A a la cuenta B.
leer(a)
a : = a – 50
escribir(a)
leer(b)
b:= b + 50
escribir(b)
ATOMICIDAD

 Supongamos que antes de ejecutar la

transacción anterior los valores de las cuentas
A y B son de $1.000 y $2.000 respectivamente.
 Ocurre un fallo.
leer(a)
 Fallos en alimentación.
a : = a – 50
 Fallo de hardware.
escribir(a)
 Error de software. leer(b)
b:= b + 50
escribir(b)
Consecuencia

 Cuenta A = $950 y cuenta B = $2.000.

 Se han perdido 50 de la cuenta A.
 Ya no se conserva la suma A + B.
 Se queda la base de datos en un “Estado
inconsistente”.
 Pueden quedar estados inconsistentes
temporales.
 Si la transacción no empieza nunca o se
garantiza que se complete, un estado
inconsistente así, no sería visible durante la
ejecución de la transacción.
CONCLUSIÓN

 Si se proporciona la propiedad de atomicidad,

o todas las acciones de la transacción se ven
reflejadas en la base de datos, o ninguna de
ellas.
TECNICA

 El sistema de base de datos mantiene los

valores antiguos (en disco) de aquellos datos
sobre los que una transacción realiza una
escritura, y si la transacción no completa su
ejecución, los valores antiguos se recuperan
para que parezca que la transacción no se ha
ejecutado.
 La responsabilidad de esto, lo maneja un
componente llamado: “componente de
gestión de transacciones”
CONSISTENCIA
 La ejecución aislada de la transacción (es decir,
sin otra transacción que se ejecute
concurrentemente) conserva la consistencia de
la base de datos.
 En el caso anterior, el requisito de consistencia es
que la suma de A y B no sea alterada al ejecutar
la transacción.
 La resp0nsabilidad de asegurar la consistencia
recae en el programador de la aplicación.

Posible inconsistencia temporal

Ei Ej
AISLAMIENTO

 Aunque se ejecuten varias transacciones

concurrentemente, el sistema garantiza que
para cada par de transacciones Ti y Tj, se
cumple que para los efectos de Ti, o bien Tj ha
terminado su ejecución antes de que
comience Ti, o bien Tj ha comenzado su
ejecución después de que Ti termine.
 De este modo cada transacción ignora al
resto de las transacciones que se ejecuten
concurrentemente en el sistema.
AISLAMIENTO…

 Si varias transacciones se ejecutan

concurrentemente, se pueden entrelazar sus
operaciones de un modo no deseado,
produciendo un estado inconsistente.
 Solución posible:
 Ejecutar transacciones secuencialmente.
 Se quita la noción principal de optimización por
concurrencia.
Responsabilidad

 La responsabilidad de asegurar la propiedad

de aislamiento es de un componente del
sistema de base de datos llamado
componente de control de concurrencia.
DURABILIDAD

 Tras la finalización con éxito de una

transacción, los cambios realizados en la base
de datos permanecen, incluso si hay fallos en el
sistema.
 La propiedad de durabilidad asegura que, una
vez que se completa con éxito una transacción,
persisten todas las modificaciones realizadas
en la base de datos.
Durabilidad.

 Se garantiza la durabilidad si se asegura que:

1. Las modificaciones realizadas por la
transacción se guardan en disco antes de
que finalice la transacción.
2. La información de las modificaciones
realizadas por la transacción guardada en
disco es suficiente para permitir a la base de
datos reconstruir dichas modificaciones
cuando el sistema se reinicie después del
fallo.
Responsabilidad

 La responsabilidad de asegurar la durabilidad

es de un componente del sistema de base de
datos llamado “componente de gestión de
recuperaciones”.
ESTADOS DE UNA TRANSACCION

 Transacción abortada=>no tiene una

finalización exitosa.
 Transacción abortada=>no debe tener efecto
sobre el estado de la base de datos.
 Cambios deben deshacerse.
 Así la transacción ha retrocedido.
TRANSACCION COMPROMETIDA

 Transacción exitosa.
 Transforma la base de datos llevándola a un
nuevo estado consistente PERMANTENTE
aun luego de fallas del sistema.
 No se pueden deshacer sus efectos
abortándola.
 La única forma de deshacer los cambios de
una transacción comprometida es ejecutando
una transacción compensadora.
Ejemplo

 Una transacción añade $20 a una cuenta.

 La transacción compensadora debería restar
$20 de la cuenta.
 No siempre se puede crear la transacción
compensadora.
 Las transacciones compensadoras no las
gestiona el sistema de base de datos.
ESTADOS DE UNA TRANSACCION

 Una transacción puede estar:

 Activa
 El estado inicial; la transacción permanece en este estado
durante su ejecución.
 Parciamente comprometida
 Después de ejecutarse la última instrucción.
 Fallida
 Tras descubrir que no puede continuar la ejecución
normal.
 Abortada
 Después de haber retrocedido.
 Comprometida
 Completada con éxito.
ESTADOS DE LAS TRANSACCIONES

 Una transacción se dice que ha terminado si

se ha comprometido o bien se ha abortado.
 Una transacción comienza en el estado
activa.
 Una transacción cuando ha ejecutado su
última instrucción se dice que está
parcialmente comprometida.
 En este punto la transacción ha terminado su
ejecución. Pero debido a un error de
hardware puede tener que ser abortada.
ESTADOS DE LAS TRANSACCIONES

 El sistema de BD escribe en disco la

información suficiente para que, incluso al
producirse un fallo, puedan reproducirse los
cambios hechos por la transacción al reiniciar
el sistema tras el fallo.
 Cuando se termina de escribir esta
información, la transacción pasa al estado
comprometida.
TRANSACCIONES FALLIDAS

 El sistema determina que dicha transacción

no puede continuar su ejecución normal.
 Una transacción de este tipo debe retroceder.
 Después pasa al estado abortada.
 En este punto el sistema tiene dos opciones.
 Reiniciar.
 Cancelar.
Reiniciar

 Si la transacción se ha abortado a causa de un

error de hardware o software.
 Cuando no lo haya provocado la lógica
interna de la transacción.
 Una transacción reiniciada se considera una
nueva transacción.
CANCELAR

 Normalmente se hace esto si hay

 Algún error interno lógico que solo se puede
corregir escribiendo de nuevo el programa de
aplicación .
 Una entrada incorrecta o debido a que no se han
encontrado los datos deseados en la base de
datos.
IMPLEMENTACIÓN DE LA ATOMICIDAD Y LA DURABILIDAD

 Componente de gestión de recuperaciones.

 Sistema “copia en la sombra”: ineficiente
pero simple.
 Hace copias de la base de datos, denominadas
copias sombra.
 Asume una sola transacción activa en cada
momento.
 La base de datos es un simple archivo en disco.
 El disco mantiene un puntero que apunta a la bd.
COPIA EN LA SOMBRA…

 Una transacción que quiera actualizar una bd

crea primero una copia completa de dicha bd.
 Todos los cambios se hacen en la nueva copia
de la base de datos dejando la copia original,
la copia en la sombra, inalterada.
 Cuando una transacción se aborta, la copia
nueva simplemente se borra.
 La copia antigua no se ve afectada.
COPIA EN LA SOMBRA

 Si la transacción se completa, se compromete

como sigue:
 Se consulta al S.O. para asegurarse de que todas
las páginas de la nueva copia de la bd se han
escrito en disco.
 Se actualiza el puntero para que apunte a la nueva
copia de la bd.
 La copia antigua se borra de la bd
 La transacción está comprometida en el momento
en que el puntero actualizado se escribe en disco.
EJECUCIONES CONCURRENTES

 Los sistemas de procesamiento de

transacciones permiten normalmente la
ejecución de varias transacciones
concurrentemente.
 Provoca complicaciones de consistencia.
 Asegurar la concurrencia requiere un trabajo
extra.
Razones para la concurrencia

 Productividad y utilización de recursos

mejorada.
 Tiempo de espera reducido.
Ejemplo de concurrencia
Valores actuales:
a=1000
b=2000

 Transacción T1  Transacción T2
leer(a) leer(a)
a : = a – 50 temp:= a * 0,10
escribir(a) a:=a-temp;
leer(b) escribir(a)
b:= b + 50 leer(b)
escribir(b) b:=b+temp
escribir(b)
Si se ejecuta primero T1

 Valores finales:
 a=950 y b=2050 (luego de T1)
 a=855 y b=2145

Si se ejecuta primero T2

 Valores finales:
 a=900 y b=2100 (luego de T2)
 a=850 y b=2150
PLANIFICACIONES.

 Las secuencias de ejecución que se acaban de

describir se denominan planificaciones.
 Para un conjunto de n transacciones existen n!
planificaciones secuenciales válidas distintas.
 La planificación no necesariamente debe ser
secuencial.
 Son posibles muchas secuencias de ejecución,
puesto que varias instrucciones de ambas
transacciones se pueden intercalar. Asi se puede
tener mucho mas de n! planificaciones.
 PLANIFICACIONES T1 T2
 Como vimos es Leer (A)
A:=A-50
importante que exista Escribir(A)
concurrencia. Leer (A)
Temp:=A*0,1
 No todas las A:=A-Temp
Escribir(A)
ejecuciones
concurrentes producen Leer (B)
B:=B+50
un estado correcto. Escribir(B)
Leer (B)
 Ejemplo de B:=B+temp
Escribir(B)
planificaciones
 El componente del sistema
de base de datos que realiza
esta tarea se denomina
componente de control de T1 T2
concurrencia.
Leer (A)
 Se puede asegurar la
A:=A-50
consistencia de la base de
Leer (A)
datos en una ejecución Temp:=A*0,1
concurrente si está seguro de A:=A-Temp
que cualquier planificación Escribir(A)
Leer(B)
que se ejecute tiene el
mismo efecto que otra que Escribir (A)
Leer (B)
se hubiese ejecutado sin B:=B+50
concurrencia. Escribir(B)
 La planificación debe ser, en B:=B+temp
Escribir(B)
cierto modo, equivalente a
una planificación secuencial.
SECUENCIALIDAD

 El sistema de base de datos debe controlar la

ejecución concurrente de las transacciones
para asegurar que el estado de la base sigue
siendo consistente.
 Hay que entender las planificaciones que
aseguran la consistencia y las que no.
 Es difícil calcular cuáles son las operaciones
exactas que realiza una transacción y cómo
interaccionan las operaciones de varias
transacciones.
TIPOS DE SECUENCIALIDAD

 Las equivalencias de planificación nos llevan a

los conceptos de:

 Secuencialidad en cuanto a conflictos

 Secuencialidad en cuanto a vistas

Secuencialidad en cuanto a
conflictos
 Consideremos dos transacciones Ti y Tj
 Dos instrucciones consecutivas Ii e Ij con i<>j
 Si las instrucciones se refieren a distintos
elementos de datos se pueden intercambiar Ii
e Ij sin afectar los resultados.
 Se deben considerar adicionalmente, casos
en los cuales la concurrencia pueda afectar
los valores de los resultados esperados.
CASOS

 Ii = leer(Q) Ij=leer(Q) Orden no es reelevante

 Ii = leer(Q) Ij=escribir(Q) Orden si importa
 Ij = leer(Q) Ii=escribir(Q) Orden si importa
 Ii = escribir(Q) Ij=escribir(Q) Orden si importa
 Se dice que Ii e Ij están en conflicto si existen
operaciones de diferentes transacciones
sobre el mismo elemento de datos, y al
menos una de esas instrucciones es una
operación escribir.
Ejemplo:
T1 T2
Leer (A)
Escribir(A)
Leer (A)
Escribir(A)
Leer (B)
Escribir (B)
Leer (B)
Escribir (B)

La instrucción escribir(A) de T1 está en conflicto con la instrucción leer(A) de T2.

La instrucción escribir(A) de T2 no está en conflicto con la instrucción leer(B) de T1.
Ejemplo 2

 Si tenemos dos instrucciones consecutivas de

una planificación P. Si Ii e Ij son instrucciones
de transacciones diferentes y además Ii e Ij,
no están en conflicto, entonces podemos
cambiar el orden para obtener una nueva
planificación P’.
 En este caso se esperaría que P sea
equivalente a P’.
 Se dice que una planificación P es
secuenciable en cuanto a conflictos si es
equivalente en cuanto a conflictos a una
planificación secuencial.
 Es posible encontrar dos planificaciones que
produzcan el mismo resultado y que no sean
equivalentes en cuanto a conflictos.
Ejercicio

 Realizar 3 cambios en la secuencia de las

transacciones que no afecten el resultado del
ejercicio anterior.
SECUENCIALIDAD EN CUANTO A VISTAS

 Deben cumplir 3 condiciones:

 Para todo elemento de datos Q, si la transacción Ti
lee el valor inicial de Q en la planificación P,
entonces Ti debe leer también el valor inicial de Q
en la planificación P’.
 Para todo elemento de datos Q, si la transacción Ti
ejecuta leer(Q) en la planificación P y el valor lo ha
producido la transacción Tj entonces en la
planificación P’, la transacción Ti debe leer
también el valor de Q que haya producido la
transacción Tj.
 Para todo elemento de datos Q, la transacción que
realice la última operación escribir (Q) en la
planificación P, debe realizar la última operación
escribir (Q) en la planificación P’
 Se dice que la planificación P es secuenciable
en cuanto a vistas si es equivalente en cuanto
a vistas a una planificación secuencial.