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.
Concurrencia intercalada
 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

Las transacciones pueden delimitarse con las

sentencias explícitas:

Begin transaction

End transaction.
 Transacción

Las operaciones básicas de acceso a la base de

datos que una transacción puede incluir son:

Read (x).

Write (x).
 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.
Pasos de las operaciones Read (x) y
Write (x)

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

Sistema de BD de reservas en una línea aérea.

 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.
 Ejemplo

T2: reserva M asientos en el primer vuelo (X).

 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
 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.
Actualización temporal (o lectura sucia)
 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.
Resumen incorrecto
 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.
Registros del Diario (log)
Ejemplo de transacción en
Postgres