CLASE 5
ADMINISTRACIÓN DE BASE DE DATOS
MANEJO DE TRANSACCIONES
AUTORES:
Prof. Roxydel Dulcey
Prof. Josué Ramírez
Marzo, 2011
Sistemas de procesamiento de
transacciones
Son sistemas con grandes base de datos y
cientos de usuarios concurrentes que están
ejecutando transacciones de base de datos.
Ejemplos: sistemas de reservas, banca,
proceso de tarjetas de crédito, mercado de
valores, cajas de supermercados, entre otros.
Sistemas de procesamiento de
transacciones
Estos sistemas requieren:
Alta disponibilidad.
Tiempo de respuesta adecuado para atender a
cientos de usuarios concurrentes.
Transacción
Es una unidad lógica de procesamiento de la
base de datos que incluye una o más
operaciones de acceso a la base de datos, que
pueden ser de inserción, eliminación,
modificación o recuperación.
Transacción
Las operaciones de la base de datos que
forman una transacción pueden estar
insertadas dentro de un programa de
aplicación o se pueden especificar de forma
interactiva a través de un lenguaje de consulta
de alto nivel como SQL.
Transacción
Read (x): lee un elemento de la base de datos
llamado ‘x’ y lo coloca en una variable de
programa.
Write (x): escribe el valor de la variable de
programa en el elemento de la base de datos
llamado ‘x’.
Bloque
Es la unidad básica de transferencia de datos
del disco a la memoria principal del
computador.
Un bloque del buffer se graba en disco:
Porque el gestor de buffer necesita espacio
de memoria para otros propósitos.
O porque el SGBD desea reflejar el cambio
hecho a ‘x’ en el disco.
Ejemplos de transacciones
Una transacción deberá incluir funciones read
(x) y write (x) para tener acceso y actualizar la
base de datos:
Concurrencia
Las transacciones de los usuarios se podrían
ejecutar de manera concurrente y podrían
acceder y actualizar los mismos elementos de
la BD.
Concurrencia
Si esta ejecución concurrente no se controla,
puede provocar problemas tales como que la
base de datos no sea consistente.
Por esta razón son necesarios mecanismos
para el control de concurrencia.
Concurrencia
A continuación 3 de los problemas que
pueden presentarse:
Actualización perdida.
Actualización temporal (o lectura sucia).
Resumen incorrecto.
Ejemplo
T1: transfiere N reservas de un vuelo, cuyo
número de asientos reservados está
almacenado en el elemento de la BD llamado
X, a otro vuelo, cuyo número de asientos
reservados está almacenado en el elemento
de la BD llamado Y.
Actualización perdida
Esto ocurre cuando las transacciones que
tienen acceso a los mismos elementos de la
BD tienen sus operaciones intercaladas de
modo que hacen incorrecto el valor de algún
elemento.
T1 y T2 se introducen al mismo tiempo y sus
operaciones se intercalan.
Actualización perdida
El valor final del elemento X es incorrecto,
porque T2 lee el valor de X ANTES de que T1
lo modifique en la BD, con lo que se pierde el
valor actualizado que resulta de T1.
Actualización perdida
Si X=80 al principio, N=5 (T1 transfiere 5
reservas de asientos del vuelo que
corresponde a X al vuelo que corresponde a Y)
y M=4 (T2 reserva 4 asientos en X), el
resultado final debería ser X=79, pero es X=84,
porque la actualización de T1 que eliminó 5
asientos de X se ha perdido.
Actualización temporal (o lectura
sucia)
Esto ocurre cuando una transacción actualiza
un elemento de la BD y luego la transacción
falla por alguna razón. Otra transacción tiene
acceso al elemento actualizado antes de que
se restaure a su valor original.
T1 actualiza el elemento X y después falla
antes de completarse, así que el sistema debe
cambiar X otra vez a su valor original.
Actualización temporal (o lectura
sucia)
Antes de que pueda hacerlo, la transacción T2
lee el valor “temporal” de X, que no se
grabará permanentemente en la BD debido al
fallo de T1.
El valor que T2 lee de X se llama dato sucio,
porque fue creado por una transacción que no
se ha completado ni confirmado todavía.
Resumen incorrecto
Si una transacción está calculando una
función agregada de resumen sobre varios
registros mientras otras transacciones están
actualizando algunos de ellos, puede ser que
la función agregada calcule algunos valores
antes de que se actualicen y otros después de
actualizarse.
Resumen incorrecto
Por ejemplo, una transacción T3 está
calculando el número total de reservas de
todos los vuelos; mientras se está ejecutando
T1.
Por qué es necesaria la recuperación
Siempre que se introduce una transacción a
un SGBD para ejecutarla, el sistema tiene que
asegurarse de que:
Todas las operaciones de la transacción se
realicen con éxito y su efecto quede
registrado permanentemente en la BD.
Por qué es necesaria la recuperación
Que la transacción no tenga efecto alguno
sobre la BD ni sobre otra transacción, si es
que no se completa o falla.
Tipos de fallos
Caída del Sistema: durante la ejecución de la
transacción se produce un error de hardware,
software o red.
Error de transacción o del sistema: alguna
operación de la transacción puede hacer que
ésta falle (overflow) o errores de lógica.
Tipos de fallos
Errores locales o condiciones de excepción:
puede que no se encuentren los datos para la
transacción, por ejemplo: saldo insuficiente.
Ésta podría programarse y no ser un tipo de
fallo.
Tipos de fallos
Imposición de control de concurrencia: el
método de control de concurrencia puede
decidir que se aborte la transacción, porque
viola la seriabilidad o porque varias
transacciones de encuentran en un abrazo
mortal o deadlock (varias transacciones
“pelean” por el mismo recurso).
Tipos de fallos
Fallo del disco: algunos bloques de disco
pueden perder sus datos por un mal
funcionamiento de lectura o de escritura o
por un fallo de un cabezal de
lectura/escritura.
Tipos de fallos
Problemas físicos y Catástrofes: algunos de
éstos pueden ser interrupción de la energía
eléctrica, incendio, robo, sabotaje,
sobreescritura de discos por error,
terremotos, entre otros.
Estados de Transacciones
Una transacción es una unidad atómica de
trabajo que se realiza por completo o bien no
se efectúa en absoluto.
Estados de Transacciones
El componente del sistema encargado de
lograr la atomicidad se conoce como
administrador de transacciones y las
operaciones COMMIT (comprometer) y
ROLLBACK (retroceder) son la clave de su
funcionamiento.
Estados de Transacciones
La operación COMMIT señala el término
exitoso de la transacción: le dice al
administrador de transacciones que se ha
finalizado con éxito una unidad lógica de
trabajo, que la base de datos está o debería
estar de nuevo en un estado consistente y que
se pueden comprometer, o hacer
permanentes todas las modificaciones
efectuadas por esa unidad de trabajo.
Estados de Transacciones
La operación ROLLBACK, en cambio, señala el
término no exitoso de la transacción: le dice al
administrador de transacciones que algo salió
mal, que la base de datos podría estar en un
estado inconsistente y que todas las
modificaciones efectuadas hasta el momento
por la unidad lógica de trabajo deben
retroceder o anularse.
Propiedades deseables en las
Transacciones (ACID)
Atomicidad: una transacción es una unidad
atómica de procesamiento; o bien se realiza
por completo o no se realiza en absoluto.
Propiedades deseables en las
Transacciones (ACID)
Conservación de la consistencia: una
transacción conserva la consistencia si su
ejecución completa lleva la base de datos de
un estado consistente a otro.
Propiedades deseables en las
Transacciones (ACID)
Aislamiento (en inglés Isolation): una
transacción debería parecer que se está
ejecutando de forma aislada de las demás
transacciones. Es decir, la ejecución de una
transacción no debería interferir con otras
transacciones que se ejecuten
concurrentemente.
Propiedades deseables en las
Transacciones (ACID)
Durabilidad o permanencia: los cambios
aplicados a la base de datos por una
transacción confirmada deben perdurar en la
base de datos.