07 - Procesamiento de Transacciones

11/09/2009
Procesamiento de Transacciones
Contenido
PROCESAMIENTO DE Conceptos
TRANSACCIONES Problemas de la Concurrencia
Necesidad de Recuperación
Transacciones
Clasificación de Planes según Recuperación
Seriabilidad
Expectativas del usuario final CONCEPTOS BÁSICOS

Los datos son correctos

El usuario siempre espera ver los datos correctos
SGBD, clasificados por cantidad de
Los datos tienen que estar disponibles cuando los usuarios concurrentes:
necesito Monousuario
Todos pueden querer acceder al mismo tiempo
No importa que falle el hardware, que haya un apagón o incendio Multiusuario (multiprogramación)
Los datos son para mí y mis socios
Sólo los usuarios debidamente autorizados pueden consultar y Ejecución:
modificar los datos
Concurrente intercalada
Los tiempos de respuesta deben ser aceptables
Concurrente simultánea
Cátedra de Bases de Datos 3 Cátedra Bases de Datos 4
CONCEPTOS BÁSICOS (cont.) CONCEPTOS BÁSICOS (cont.)

Concurrencia intercalada programas A y B
Concurrencia simultanea programas C y D
A C
A
B D
B
t3 t4
t1 t2
Cátedra Bases de Datos 5 Cátedra Bases de Datos 6
1
11/09/2009
CONCEPTOS BÁSICOS (cont.) Ejemplo de Transacciones

Operaciones de lectura y escritura: T1 T2
Leer_elemento(X): Lee un elemento de la base de Leer_elemento(X); Leer_elemento(X);
datos llamado X y lo coloca en una variable de X:= X - N; X:= X + M;
programa (que suponemos también se llama X ).
Escribir_elemento(X); Escribir_elemento(X);
Escribir_elemento(X): Escribe el valor de la
variable de programa X en el elemento de la base de
Leer_elemento(Y);
datos llamado X. Y:= Y + N;
Transacción: ejecución de un programa que Escribir_elemento(Y);
lee o modifica el contenido de la base de datos.
¿PORQUÉ ES NECESARIO EL
CONTROL DE CONCURRENCIA? Actualización Perdida
T1 T2
Problema de actualización perdida Leer_elemento(X);
Leer_elemento(X);
X:= X + M;
Problema de actualización temporal X:= X - N;
(lectura sucia) Escribir_elemento(X);
Escribir_elemento(X);
Leer_elemento(Y);
Problema de resumen incorrecto
Y:= Y + N; Se pierde la actualización
realizada por T1
Escribir_elemento(Y);
Lectura Sucia Resumen Incorrecto

T1
T1 T2 T2
suma :=0;
Leer_elemento(X);
Leer_Elemento (A)
X:= X - N; Leer_elemento(X); suma:= suma+A;
X:= X - N;
Escribir_elemento(X); Escribir_elemento(X);
Leer_elemento(X);
Leer_elemento(X);
X:= X + M; suma:=suma+X;
Escribir_elemento(X); Leer_elemento(Y);
Leer_elemento(Y); suma:=suma+Y
Leer_elemento(Y);
Al fallar T1, el valor leído por T2 Y:= Y + N; T2 lee X después de restarse N
Falla de X es incorrecto, y X queda Escribir_elemento(Y); Lee Y antes de sumársele N
inconsistente El valor de suma es incorrecto
2
11/09/2009
¿PORQUÉ ES NECESARIA LA
RECUPERACIÓN? TIPOS DE FALLOS
Del Hardware
Para ejecutar toda transacción el
sistema debe asegurarse de que: De la Transacción o del Sistema
Todas sus operaciones: Errores locales o condiciones de
Se completen con éxito y su efecto quede excepción detectadas por la transacción
Asentado permanentemente en la base de datos, (Exceptions).
ó Imposición del control de concurrencia
La transacción no tenga efecto alguno Fallo del disco
sobre la base de datos ni sobre cualquier Problemas o catástrofes físicos
otra transacción
Control de Concurrencia y
Recuperación: Temario
Control de concurrencia
Estudio de un modelo y de los principios básicos que debe
implementar el manejador para garantizar la consistencia
de la base en la situación de modificaciones concurrentes.
Transacción
Historia (ejecución) y caracterización
Protocolos de Control de Concurrencia Transacciones
Mecanismos de Recuperación
Para asegurar un estado consistente frente a una falla.
Cátedra Bases de Datos 15
Modelo de transacciones /
OPERACIONES DIAGRAMA DE TRANSICIÓN DE ESTADOS
PARA LA EJECUCIÓN DE TRANSACCIONES
Transacción: ejecución de un programa que Leer, Escribir
lee o modifica el contenido de la base de Fin de
datos Transacción
Parcialmente
Activa Confirmar
Operaciones del programa que componen el Inicio Confirmada
modelo de transacción que estudiaremos Transacción Confirmada
Abortar Abortar
Inicio de transacción
Leer o escribir (read o write)

Fallida
Fin de transacción
Confirmar o validar (commit) Terminada

Abortar o revertir (abort)
3
11/09/2009
PROPIEDADES DE LAS
TRANSACCIONES Propiedades ACID (cont.)
Atomicidad (Atomicity)
Atomicidad: una transacción es una unidad
atómica de procesamiento, o bien se realiza por
Conservación de la consistencia (Consistency) completo o no se realiza en absoluto
Aislamiento (Isolation)
Consistencia: una ejecución correcta de la
Durabilidad o permanencia (Durability) transacción debe llevar a la BD de un estado
consistente a otro
Se las conoce como las propiedades A C I D
Modelo de transacciones /
Propiedades ACID (cont.) PLANES
Aislamiento: Una transacción no debe Un plan (historia o schedule) P de n

dejar que otras puedan ver sus transacciones T1, T2, ... Tn es
actualizaciones antes de ser confirmada un ordenamiento para las operaciones de
las transacciones, tal que
Durabilidad: si las modificaciones a la BD para cada transacción Ti que participe en
se han confirmado no deben perderse por P, las operaciones de Ti en P deben
un fallo siguiente aparecen en el mismo orden en que
ocurren en Ti
Ejemplo de planes Clasificación de los planes

Ejemplo: Según la complejidad del mecanismo de
T1: r1(x), w1 (x), c1 recuperación frente a fallas de las
T2: r2 (x), r2 (y), w2 (x), c2 Plan Serial transacciones.
Según el grado de concurrencia y su
Ps: r1(x), w1 (x), c1, r2(x), r2 (y), w2 (x), c2 correctitud.
Pe: r2(x), r1(x), w1(x), r2(y), c1, w2 (x), c2

Plan
Entrelazado
4
11/09/2009
Bitácora (log): Elemento básico

de la recuperación LA BITACORA (Log) DEL SISTEMA
¿ Cómo recuperarse de los fallos ? Tipos de registros de bitácora:

Mantenimiento de una bitácora (Log) [ T, inicio ]
se registran todas las operaciones de las [ T, X ] (leer, depende del sistema si se registran o no)
transacciones que afectan a los valores de la BD. [ T, X, valor_anterior, valor_nuevo ] (escribir)
Valor anterior o before image
El log debe ser persistente, o sea
mantenerse en disco [ T, confirmar ]
[ T, abortar ]
Operaciones
Deshacer (undo)
Rehacer (redo) T: identificador de la Transacción
PUNTO DE CONFIRMACIÓN
DE UNA TRANSACCIÓN [COMMIT]
Una transacción T llega a su punto de

confirmación cuando:
Todas sus operaciones que tienen acceso a
la base de datos se han ejecutado con
éxito y Clasificación según
El efecto de todas estas operaciones se ha Recuperabilidad
asentado en la bitácora.
Se registra en el Log un [ T, confirmar ]
Planes recuperables Ejemplos
plan No
Plan Recuperable: P0
recuperable
Un plan es Recuperable si ninguna transacción T1 confirma r1(x), w1(x), r2(x), r1(y), w2(x), c2, a1
hasta que confirmaron todas las transacciones desde las cuales
T1 leyó elementos. P1 plan
r1(x), w1(x), r2(x), r1(y), w2(x), a1 recuperable
Se dice que T1 lee de la transacción T2 en P, si T2 escribe
primero un elemento X que luego T1 lee.
5
11/09/2009
Planes que
Caso de lectura sucia Evitan Abortos en Cascada
T1 T2
Plan que Evita Abortos en Cascada:
Leer_elemento(X);
Un plan Evita Abortos en Cascada si ninguna transacción
Leer_elemento(X); lee de transacciones no confirmadas.
Commit Aborto en cascada implica que una transacción no confirmada
Leer_elemento(Y);
tiene que revertirse porque leyó un elemento de una
transacción fallida
Al fallar T1, el valor leído por T2
Falla de X es incorrecto
Ejemplo Planes estrictos

plan recuperable pero
NO Evita Abortos en Plan Estricto:
Cascada
P1 Un plan es Estricto si ninguna transacción lee o escribe hasta
que todas las transacciones que escribieron ese elemento
r1(x), w1(x), r2(x), r1(y), w2(x), a1
fueron confirmadas.
P2
Plan recuperable
w1(x, 5), w2(x, 8), a1
que Evita Abortos
en Cascada
Ejemplo Relación entre planes

Plan Recuperable que
Evita Abortos en
P2 Casacada pero NO Recuperable
Estricto
w1(x, 5), w2(x, 8), a1 Evita Abortos en Cascada
Estricto
P3 Plan Estricto
P0 x P1 x P2 x P3 x
a: r1(y), r2(z), w1(y), w2(z), c2, c1
b: r3(y), r4(z), r3(x), w4(z), w3(x), w4(u), c3, w4(x), c4
6
11/09/2009
Beneficios...
Los planes recuperables aseguran que
las transacciones confirmadas en planes entrelazados
no serán revertidas, y que
no queden datos erróneos que no se puedan corregir
de una “manera simple”
Al evitar abortos en cascada se disminuye el Clasificación según su
tiempo de recuperación evitando revertir otras
transacciones. Correctitud
Los planes estrictos simplifican la recuperación
de escrituras
Planes Seriales y Serializables Caso de la actualización perdida

T1 T2
Punto de partida sobre la “correctitud” Leer_elemento(X);
Si las transacciones se ejecutaran siempre en Leer_elemento(X);
forma serial, entonces X:= X + M;
los datos siempre serían correctos, pero
X:= X - N;
no habría concurrencia
Leer_elemento(Y);
Y:= Y + N; Se pierde la actualización
realizada por T1
Escribir_elemento(Y);
Planes Seriales y Serializables (cont.) Equivalencia de planes por conflicto

Dos operaciones de un plan están en conflicto si:
Se necesitan planes entrelazados pero con
comportamiento de seriales Pertenecen a diferentes transacciones
Tienen acceso al mismo elemento X
Un plan P de n transacciones es serializable si Una de las dos operaciones es escribir_elemento(X)
es equivalente a algún plan serial de las mismas
n transacciones Dos planes son equivalentes por conflicto si
¿ Cuando 2 planes son “equivalentes” ? el orden de cualquier par de operaciones en conflicto es
el mismo en ambos planes
7
11/09/2009
Prueba de Seriabilidad Prueba de Seriabilidad

por Conflictos de un plan P por Conflictos de un plan P (cont.)
(1) (2)
Para cada transacción Ti que participa Para cada caso en P donde Ti ejecuta
en el plan P una orden leer_elemento(X) antes
de que Tj ejecuta una orden
Crear un nodo rotulado Ti en el grafo escribir_elemento(X)
de precedencia
Crear una arista ( Ti → Tj ) en el grafo
de precedencia;
Prueba de Seriabilidad Prueba de Seriabilidad

por Conflictos de un plan P (cont.) por Conflictos de un plan P (cont.)
(3) (4)
Para cada caso en P donde Ti ejecuta Para cada caso en P donde Ti ejecuta
escribir_elemento(X) antes de que Tj una orden escribir_elemento(X) antes
ejecuta leer_elemento(X) de que Tj ejecuta una orden
escribir_elemento(X)
Crear una arista ( Ti → Tj ) en el grafo
crear una arista ( Ti → Tj ) en el grafo
de precedencia;
de precedencia;
Prueba de Seriabilidad PLANES EQUIVALENTES POR

por Conflictos de un plan P (cont.) CONFLICTOS
Ejemplo de cómo usarlo:
(5)
T1: r1(x), w1(x), r1(y), w1(y), c1; T2: r2(x), w2(x), c2
P1: r1(x), r2(x), w1(x), r1(y), w1(y), w2(x) , c1
El plan P es seriable si y sólo si el P2: r1(x), w1(x), r2(x), w2(x), r1(y), w1(y) , c2
grafo de precedencia no tiene ciclos
P1 P2 Serializable
T1 T2
No T1 T2
Serializable
8
11/09/2009
Aplicado al caso … Caso resumen incorrecto

T1 T2
Retomemos la ejecución del caso de la suma :=0;
actualización perdida Leer_Elemento (A)
suma:= suma+A;
Leer_elemento(X);
X:= X - N;
Leer_elemento(X);
T1 T2
suma:=suma+X;
Leer_elemento(Y);
suma:=suma+Y
Leer_elemento(Y);
Y:= Y + N; T2 lee X después de restarse N
Escribir_elemento(Y); Lee Y antes de sumársele N
El valor de suma es incorrecto
Aplicación de la serializabilidad Resumen

SGBD debe permitir la construcción de planes Necesidad de control de concurrencia y recuperación
serializables. Sin embargo, no se hace uso del test de Modelo incluyendo:
serializabilidad Transacción y sus operaciones.
Planes
Veremos métodos de control de concurrencia
Caracterización de los planes
basados en demorar las operaciones en conflicto con
otras anteriores hasta que éstas terminen Recuperabilidad: planes recuperables, que evitan
abotros en cascada y estrictos
Dos métodos: Correctitud: Serializabilidad
Locking (uso de bloqueos o candados o locks) Propiedades ACID de las Transacciones
Usando timestamps (estampillas de tiempo)

07 - Procesamiento de 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

07 - Procesamiento de Transacciones

Cargado por

Copyright:

Formatos disponibles

11/09/2009

Expectativas del usuario final CONCEPTOS BÁSICOS

Cátedra de Bases de Datos 3 Cátedra Bases de Datos 4

CONCEPTOS BÁSICOS (cont.) CONCEPTOS BÁSICOS (cont.)

CONCEPTOS BÁSICOS (cont.) Ejemplo de Transacciones

Lectura Sucia Resumen Incorrecto

Cátedra Bases de Datos 15

Leer o escribir (read o write)

Confirmar o validar (commit) Terminada

Cátedra Bases de Datos 17 Cátedra Bases de Datos 18

Cátedra Bases de Datos 19 Cátedra Bases de Datos 20

Aislamiento: Una transacción no debe Un plan (historia o schedule) P de n

Cátedra Bases de Datos 21 Cátedra Bases de Datos 22

Ejemplo de planes Clasificación de los planes

Pe: r2(x), r1(x), w1(x), r2(y), c1, w2 (x), c2

Bitácora (log): Elemento básico

¿ Cómo recuperarse de los fallos ? Tipos de registros de bitácora:

Cátedra Bases de Datos 25 Cátedra Bases de Datos 26

Una transacción T llega a su punto de

Planes recuperables Ejemplos

Cátedra Bases de Datos 29

Cátedra Bases de Datos 31 Cátedra Bases de Datos 32

Ejemplo Planes estrictos

Cátedra Bases de Datos 34

Ejemplo Relación entre planes

Planes Seriales y Serializables Caso de la actualización perdida

Planes Seriales y Serializables (cont.) Equivalencia de planes por conflicto

Cátedra Bases de Datos 41

Prueba de Seriabilidad Prueba de Seriabilidad

Prueba de Seriabilidad Prueba de Seriabilidad

Cátedra Bases de Datos 45 Cátedra Bases de Datos 46

Prueba de Seriabilidad PLANES EQUIVALENTES POR

Cátedra Bases de Datos 47 Cátedra Bases de Datos 48

Aplicado al caso … Caso resumen incorrecto

Aplicación de la serializabilidad Resumen

Cátedra Bases de Datos 51

También podría gustarte