Prof.

Robert Espinoza

Transacciones
Transacciones

 Hasta ahora nos ocupamos de realizar consultas,

actualizaciones, etc.
 ¿De qué sirve una BD si no se puede confiar en la
información que está contenida en ella?

 Qué pasa si:

 Las operaciones fallan antes de completarse
 Varios usuarios quieren hacer a la vez cosas
contradictorias
Transacciones

 Una transacción es una secuencia de operaciones

que forman una única unidad lógica de trabajo
 Una transacción se hace o no se hace. NO puede
quedar a medias.
 Termina y sus efectos quedan en la BD o se anula y sus
efectos no quedan en la BD

 Objetivo: garantizar la consistencia de la BD a pesar

de los fallos del Sistema y de la ejecución concurrente.
 Transacciones

Ejemplo: Transferencia desde la cuenta 2 a la cuenta 1

 Cuenta 1: saldo 2000

 Cuenta 2: saldo 1000

 Transferencia de 100

 Cuenta 1: saldo 2100

 Cuenta 2: saldo 900

 Hacemos la resta a la cuenta 2, la guardamos y queda

con 900; luego se produce un fallo, se “pierden” 100

soles.
 Esto no puede pasar: o se hace la resta y la suma, o
no se hace nada.
 Transacciones

Condición de idempotencia.
 Idempotencia significa la habilidad para realizar una

acción determinada varias veces y aun así conseguir

el mismo resultado que se obtendría si se realizase
una sola vez.
 Un mensaje idempotente, como por ejemplo una
instrucción para "cambiar el precio del producto dos a
10,00$", no provocará ningún efecto secundario si se
recibe varias veces,
 Mientras que un mensaje no idempotente, como por
ejemplo una instrucción para "incrementar el precio del
producto dos en un 10%", producirá un resultado
diferente según el número de veces que se reciba.
 Transacciones

Propiedades ACID
 Atomicidad (Atomicity): una transacción debe ser una

unidad atómica de trabajo

 Una operación atómica es aquella que si está formada
por operaciones más pequeñas, se consideran como un
paquete indivisible.
 Deben ejecutarse todas correctamente, o en el caso de
que alguna de ellas no pueda hacerlo, debe deshacerse,
como si el conjunto de las operaciones no se hubieran
realizado.
 Atomicidad y transacción no son sinónimos.
 Mientras atomicidad es una propiedad, la transacción es el
mecanismo que utilizan los SGBD para lograr la atomicidad.
Transacciones

Propiedades ACID
 Consistencia (Consistency):

 La consistencia se refiere a la integridad de los datos,

con esta finalidad los diseñadores de BD definen reglas
sobre un conjunto de datos y el sistema garantiza que se
cumplan.
 Si el sistema permite consistencia, significa que esas
reglas se vigilan constantemente para todos los datos.
 La ejecución aislada de la transacción conserva la
consistencia de la BD. (lleva a la BD de un estado
consistente a otro consistente)
 Transacciones

Propiedades ACID
 Aislamiento (Isolation):

 Una transacción que se realiza sobre un conjunto de

datos será independiente de cualquier otra transacción
que se realice sobre el mismo conjunto de datos.
 El sistema nos garantiza que no va a dejar que se
interfieran entre ellas.
 El sistema escogerá el orden correcto de ejecución para que
ambas se ejecuten como si la otra no existiera.
 Además, el sistema no dejará que durante una operación
atómica se pueda acceder a resultados intermedios de la
operación.
 Los datos no reflejarán su nuevo estado hasta estar
finalizada correctamente la operación atómica.
 Transacciones

Propiedades ACID
 Durabilidad (Durability):

 Una transacción terminada con éxito realiza cambios

permanentes en la BD, incluso si hay fallos en el sistema.
 Esto, que puede parecer obvio, no siempre ocurre. Hay
muchos sistemas que informan del éxito de una
operación, pero los resultados no han quedado aún
registrados correctamente.
Transacciones

 Una transacción es un conjunto de instrucciones DML

que se ejecutan consecutivamente.
 Una transacción comienza con la primera instrucción
DML que se ejecute y finaliza con alguna de estas
circunstancias:
 Una operación COMMIT o ROLLBACK
 Una instrucción DDL (como ALTER TABLE por ejemplo)
 Una instrucción DCL (como GRANT)
 El usuario abandona la sesión
 Caída del sistema
Transacciones

 Hay que tener en cuenta que cualquier instrucción DDL

o DCL da lugar a un COMMIT implícito, es decir todas
las instrucciones DML ejecutadas hasta ese instante
pasan a ser definitivas.
Transacciones

Sentencias de Control de Transacciones

 COMMIT

 ROLLBACK
 Transacciones

COMMIT
 La instrucción COMMIT hace que los cambios

realizados por la transacción sean definitivos,

irrevocables.
 Sólo se debe utilizar si estamos de acuerdo con los
cambios, conviene asegurarse mucho antes de realizar
el COMMIT ya que las instrucciones ejecutadas
pueden afectar a miles de registros.
 Además el cierre correcto de la sesión da lugar a un
COMMIT, aunque siempre conviene ejecutar
explícitamente esta instrucción a fin de asegurarnos de
lo que hacemos.
 Transacciones

ROLLBACK
 Esta instrucción regresa a la instrucción anterior al

inicio de la transacción, normalmente el último

COMMIT, la última instrucción DDL o DCL o al inicio de
sesión.
 Anula definitivamente los cambios, por lo que conviene
también asegurarse de esta operación.
 Un abandono de sesión incorrecto o un problema de

comunicación o de caída del sistema dan lugar a un

ROLLBACK implícito.
Transacciones

 Inicie una transacción con el primer comando DML

que requerirá luego un COMMIT o ROLLBACK.
 Use las sentencias COMMIT y ROLLBACK para
terminar de manera explícita una transacción.
Transacciones
 Si se inicia una transacción usando comandos DML
hay que tener en cuenta que:
 Se puede volver a la instrucción anterior a la transacción
cuando se desee
 Las instrucciones de consulta SELECT realizadas por el
usuario que inició la transacción muestran los datos ya
modificados por las instrucciones DML
 El resto de usuarios ven los datos tal cual estaban antes
de la transacción, de hecho los registros afectados por la
transacción aparecen bloqueados hasta que la
transacción finalice. Esos usuarios no podrán modificar
los valores de dichos registros.
 Tras la transacción todos los usuarios ven los datos tal
cual quedan tras el fin de transacción. Los bloqueos son
liberados y los puntos de ruptura borrados.
 Transacciones

Estados de una transacción

 Activa: estado inicial, estado normal durante la

ejecución.
 Parcialmente Cometida: después de ejecutarse la

última instrucción.
 Fallada: luego de descubrir que no puede seguir la
ejecución normal.
 Abortada: después de haber retrocedido la

transacción y restablecido la BD al estado anterior al

comienzo de la transacción.
 Cometida: (tras completarse con éxito) se ha

cometido parcialmente y se garantiza que nunca

abortará.
Transacciones

Diagrama de estado de una transacción

Parcialmente
Cometida
cometida

Activa

Fallada Abortada
 Transacciones

 Transacción abortada: ¿Qué hacer?

 Reiniciar la transacción: cualquier error que no dependa de la
lógica de la transacción (hardware o software)
 Cancelar la transacción: error interno lógico en el programa
que ejecuta la transacción.
 Una transacción que llega al estado de fallo después que se
determina que no puede seguir con su ejecución normal,
debe retroceder, esto es retrotraer lo hecho.
 Hay que tener cuidado con las escrituras externas (por ej. a
impresora) Cuando pase algo así no puede borrarse, puesto
que puede haber sido vista fuera del sistema de BD. Muchos
sistemas permiten que tales escrituras tengan lugar sólo
después que la transacción llegue a estado cometida
Fallos

 Con pérdida de Información

 Sin pérdida de Información (no presentan graves
problemas, ya que los datos quedan bien)
Fallos

Tipos de fallo con pérdida de

información
 Fallo en la transacción:

 Lógicos: la transacción no puede Otras

continuar su ejecución a causa de alguna transacciones
condición interna. continúan con
su ejecución
 Del sistema: el sistema alcanza un
estado no correcto. La transacción puede
volver a ejecutarse más tarde.

 Caída del sistema: errores del hardware Todas las

o software (SO, DBMS) transacciones
deben ser
 Fallo de disco recuperadas
 Fallos

Acciones de recuperación
 Para asegurar la consistencia en la base de datos y la

atomicidad de las transacciones (a pesar de los fallos),

los algoritmos tienen dos partes:
 Acciones tomadas durante el procesamiento normal de la
transacción para asegurar que existe suficiente
información para permitir la recuperación de fallos
(preventivas).
 Acciones tomadas a continuación de un fallo para
asegurar la consistencia de la base de datos y la
atomicidad de las transacciones (paliativas).
Fallos
Estructura de almacenamiento
 Almacenamiento volátil

 La información que reside en este almacenamiento no

suele sobrevivir a las caídas del sistema. (Ej: memoria
principal y caché)
 Almacenamiento no volátil
 La información que reside aquí sobrevive a las caídas del
sistema. (Ej. discos y las cintas)
 Almacenamiento estable
 En teoría nunca se pierde la información
 Replicar la información en varios medios no volátiles
independientes, y actualizar controladamente para
asegurar que se mantienen los datos ante cualquier
situación.
Fallos

Recuperación en caso de Fallo

 ¿Ante un error, como proceder ?

 Reejecutar: no sirve, se pierde consistencia

 No Reejecutar: no sirve, se pierde consistencia
 Para el caso de transferir $ 100 de una cuenta a otra
 Reejecutamos: se hizo la resta de una cuenta y falta la
suma, si hacemos de nuevo volvemos a restar, dos
veces, y hacemos una sola suma.
 No Reejecutamos: quedó una sola resta
Fallos

Recuperación en caso de Fallo

 Problema:

 Modificar la BD sin seguridad que la transacción se va a

cometer.
 Solución:
 Indicar las modificaciones antes de hacerlas efectivas,
entonces permite recuperar
Recuperación en caso de Fallo

 Métodos de Recuperación
 Basado en Bitácora (log)
 Doble Paginación
 Recuperación mediante Bitácora

 La bitácora es una estructura usada para guardar

información sobre las modificaciones que se realizaron a
los datos.
 Existen varias implementaciones. Veremos una
implementación que contiene registros con los campos:
 Nombre de la Transacción: el nombre de la transacción que
ejecutó el Write.
 Nombre del Dato: el nombre único del dato escrito.
 Valor Antiguo: el valor del dato anterior a la escritura.
 Valor Nuevo: el valor que tendrá el dato después de la
escritura.
 Las operaciones sobre la BD deben almacenarse antes
en la Bitácora
Recuperación mediante Bitácora

 Registro histórico: secuencia de actividades

realizadas sobre la BD.
 Contenido de la Bitácora
 <Ti iniciada> se graba antes de que empiece a ejecutar
la transacción i. Indica que la transacción está activa
 <Ti, E, Va, Vn>
 Identificador de la transacción
 Identificador del elemento de datos
 Valor anterior
 Valor nuevo
 <Ti Commit> Indica que la transacción está parcialmente
cometida
 <Ti Abort>
Recuperación mediante Bitácora

Dos técnicas de Bitácora

 Modificación diferida de la BD

 La base de datos se cambia recién cuando la transacción

pasa al estado de cometida
 Modificación inmediata de la BD
 Ante un cambio, primero se guarda en la Bitácora y luego
inmediatamente se lleva a la BD.
 Recuperación mediante Bitácora

Modificación diferida
 Garantiza la atomicidad de la transacción grabando

todas las modificaciones en la bitácora pero aplazando

todas las operaciones Write hasta que la transacción
se comete parcialmente.
 La información en la bitácora asociada a la transacción
parcialmente cometida se usa en la ejecución de las
escrituras diferidas.
 Si el sistema se cae antes de que termine de
ejecutarse una transacción, o si la transacción aborta,
se ignora la información de la bitácora.
Recuperación mediante Bitácora

Modificación diferida: pasos a seguir

 Información de la bitácora

 Antes de que comience una transacción T, se escribe el

registro de bitácora <T,start>.
 Si T realiza una operación Write(X,v), se escribe el
registro de bitácora <T,X,v>.
 Cuando T está parcialmente cometida, se escribe el
registro de bitácora <T,commit>.
 Escritura diferida de las modificaciones en la BD
 Estado cometido
 Recuperación mediante Bitácora

Modificación diferida
 Dada la siguiente transacción

 < T0 Start >

 < T0, A, 900 >
 < T0, B, 2100 >
 < T0 Commit >
 Recién con T0 parcialmente cometida, entonces se
actualiza la BD.
 No se necesita valor viejo de A y B, ya que se modifica
todo al final o no se modifica.
Recuperación mediante Bitácora

Modificación diferida
 Ante un fallo el esquema de recuperación usa la

operación REDO (Rehacer) usando información de la

bitácora.
 REDO (T) cuando en la bitácora existen los registros
<T,start> y <T,commit>
 Sino tiene Commit entonces se ignora, dado que no llegó
hacer algo en la BD.
 Recuperación mediante Bitácora

Modificación inmediata
 Las modificaciones en la base de datos se realizan

mientras la transacción está activa, antes de alcanzar

el estado de cometida.
 Se necesita el valor viejo, pues los cambios se fueron
efectuando.
 Este tipo de modificaciones se denominan
modificaciones no cometidas.
 En caso de que ocurra una caída o fallo de una
transacción se debe recurrir a una operación Undo que
“deshace” los cambios hechos.
 La operación Undo extrae la información de la bitácora

para determinar que datos deben restaurarse.

Recuperación mediante Bitácora

Modificación inmediata: pasos a seguir

 Información de la bitácora

 Antes de que comience una transacción T, se escribe el

registro de bitácora <T,start>.
 Si T realiza una operación Write(X,v), se escribe el
registro de bitácora <T,X,v1,v2>.
 Cuando T está parcialmente cometida, se escribe el
registro de bitácora <T,commit>.
 No puede permitirse la actualización efectiva de la
base de datos (Output (RegDatos)) antes de que se
escriba el registro de bitácora en memoria estable
(Output(RegBitácora)).
 Recuperación mediante Bitácora

Modificación inmediata
 Ante un fallo el esquema de recuperación usa las

operaciones Undo (Deshacer) y Redo (Rehacer)

usando información de la bitácora.
 Cuando se produce un fallo, el esquema de
recuperación consulta a la bitácora para determinar
que transacciones deben deshacerse o rehacerse.
 UNDO (T): cuando la bitácora contiene el registro
<T,start> pero no contiene el registro <T,commit>.
 REDO (T): cuando la bitácora contiene tanto el registro
<T,start> como el registro <T,commit>
 Recuperación mediante Bitácora

Buffers de Bitácora
 Grabar en disco cada registro de bitácora insume gran

costo de tiempo, entonces se utilizan buffer, ¿cómo

proceder?
 Una Transacción está parcialmente cometida después de
grabar en memoria no volátil el Commit de la Bitácora.
 Un Commit de la Bitácora en memoria no volátil, implica
que todos los registros anteriores de esa transacción ya
están en memoria no volátil.
 Antes de grabar en la BD un bloque que está en memoria
principal, deben haberse grabado en memoria estable
todos los registros de bitácora que pertenecen a los
datos de ese bloque. (Siempre graba primero la
Bitácora y luego la BD)
 Recuperación mediante Bitácora

Puntos de verificación (checkpoints)

 Cuando ocurre un fallo del sistema es necesario

consultar la bitácora para ver cuáles transacciones

deben rehacerse y cuáles deshacerse.
 Esto implica revisar TODA la bitácora.

 El proceso de búsqueda consume tiempo.

 La mayor parte de las transacciones que, según el
algoritmo, deben volver a hacerse, ya escribieron sus
actualizaciones en la base de datos en memoria estable.
 Volver a hacerlas no causa daño (redo es idempotente)
pero consume tiempo.
 Recuperación mediante Bitácora

Checkpoints: Pasos a seguir

 Los checkpoints buscan reducir los tiempos extra en

los procesos de búsqueda en la bitácora.

 Al disparar un checkpoint el sistema realiza la

siguiente secuencia de acciones:

 Grabar en memoria estable todos los registros de
bitácora que están en memoria principal.
 Grabar en disco los bloques modificados de los registros
intermedios (buffer).
 Grabar un registro de bitácora <checkpoint> en memoria
estable.
 El checkpoint es una actividad del sistema de base de
datos periódica y programada.
 Recuperación mediante Bitácora

Checkpoints: Pasos a seguir

 Recuperación mediante Bitácora

Checkpoints: Pasos a seguir ante fallos

 Para cada transacción Ti tal que aparece en la bitácora

el registro <Ti,commit> antes del registro

<checkpoint>, no es necesario ejecutar un REDO.
 Después de un fallo, se examina la bitácora para
determinar cuál fue la última transacción Ti que
comenzó a ejecutarse antes del último checkpoint.
 Esto se hace examinando la bitácora hacia atrás
buscando el primer registro <checkpoint> y cual es el
registro <Ti,start> más cercano.
 Luego, se aplica Redo o Undo sobre Ti y todas las
transacciones Tk que le suceden.
 Recuperación mediante Bitácora

Checkpoints: Pasos a seguir ante fallos

 Pasos a seguir con el resto de las transacciones:

 Ejecutar Redo(Tk) para todas las transacciones cuyo

registro <Tk,commit> aparece en la bitácora.
 Ejecutar Undo(Tk) de la transacción cuyo registro
<Tk,commit> no aparece en la bitácora (sólo si se usa
modificación inmediata).

Hasta ahora el algoritmo de recuperación sólo considera

un ambiente de trabajo centralizado y no concurrente. Al
momento de un fallo de sistema, a lo sumo existe una
única transacción activa
Recuperación mediante Bitácora

Checkpoints: Un ejemplo
Doble Paginación (Paginación en la
Sombra)
 La BD se divide en un número determinado de bloques
de longitud fija (páginas)
 Las páginas se numeran
 Para localizar una página dada en disco, se utiliza una
tabla de paginado
 Se mantiene en memoria volátil una tabla actual y en
almacenamiento estable una tabla doble (sombra)
 Al inicio de una transacción ambas tablas son iguales
 Durante una transacción sólo se modifica la tabla
actual
 En caso de falla, se usa la tabla doble para
recuperación
 Doble Paginación (Paginación en la
Sombra)

 IDEA principal: mantener 2 tablas de páginas

durante la vida de una transacción (tabla de
páginas actual y tabla de páginas sombra)
 Doble Paginación (Paginación en la
Sombra)
 Cuando se realiza una transacción se genera una nueva
página apuntada por la tabla actual
 La tabla de páginas de sombra mantiene un puntero a la
página que contiene el estado anterior de los datos
involucrados en la transacción (página con el estado
anterior de la BD)
 Doble Paginación (Paginación en la
Sombra)
 Ante caída de sistema o fallo de una transacción, se
recupera el estado anterior de la BD desde la página de
sombra
 La tabla de páginas actual se escribe en
almacenamiento NO volátil cuando la transacción pasa
al estado de cometida. La página actual se convierte en
nueva página de sombra y se ejecuta la siguiente
transacción
 Doble Paginación (Paginación en la
Sombra)
 La tabla de páginas sombra apunta siempre a las
páginas de la BD correspondientes al estado anterior de
cualquier transacción que estuviera activa en el
momento de la caída del sistema.
 Así no es necesario disponer de una operación
deshacer. (Abort automáticos, se tienen la dirección de
la página anterior sin las modificaciones. )
Doble Paginación (Paginación en la
Sombra)
 Doble Paginación (Paginación en la
Sombra)
 Ventajas:
 Menos accesos a disco
 Elimina la sobrecarga de escrituras del log
 Recuperación más rápida (no existe el REDO o UNDO).
 Desventajas:
 Complicada en un ambiente concurrente / distribuido.
 Sobrecarga: la técnica de paginación es por cada
transacción.
 Fragmentación de datos: cambia la ubicación de los
datos continuamente.
 Garbage Collector: ante un fallo queda una página que no
es más referenciada
Fallos con pérdida en memoria no volátil

 Hasta ahora abordamos fallas que resultan en pérdida

de información que reside en memoria volátil.
 Aunque rara vez se producen fallos en la memoria no
volátil, debemos estar preparados para este tipo de
fallos.
 La técnica es copiar periódicamente el contenido
entero (dump) de la base de datos a un
almacenamiento estable (por ejemplo, cintas
magnéticas).
Fallos con pérdida en memoria no volátil

 Si falla el almacenamiento no volátil, se restaura el

contenido de la última copia.
 Esto restaura la base de datos al estado en que se
encontraba cuando se realizó la copia de la bases de
datos completa a memoria estable.
 Luego, el sistema usa la bitácora para llevar la base de
datos al estado consistente más reciente posible.
 Fallos con pérdida en memoria no volátil

Copias de Seguridad
 Ninguna transacción debe estar activa durante el

proceso de dump y se ejecuta un proceso similar al

checkpointing:
 Se vuelcan los registros de bitácora residiendo
actualmente en memoria principal al almacenamiento
estable.
 Se vuelcan todos los bloques de buffer al disco.
 Se copian los contenidos de la base de datos al
almacenamiento estable.
 Se vuelca un registro de bitácora <dump> al
almacenamiento estable.
Implementación de Memoria Estable

 La información que reside en memoria estable nunca

se pierde.
 Para alcanzar ello, debe repetirse la información (de
manera controlada) en varios medios de
almacenamiento.
 La transferencia de bloques entre la memoria y el
disco puede resultar en:
 Terminación con Éxito: la información transferida llegó
íntegra a su destino.
 Fallo Parcial: ocurrió un fallo durante la transferencia y el
bloque destino tiene información incorrecta.
 Fallo Total: ocurrió un fallo al inicio de la transferencia y el
bloque destino queda intacto
Implementación de Memoria Estable

 Si ocurre un fallo en la transferencia de datos, el

sistema debe detectarlo e invocar un sistema de
recuperación que restaure el bloque a un estado
consistente.
 Para hacerlo, el sistema debe mantener dos bloques
físicos por cada bloque lógico de la base de datos.
 En el caso de discos espejados, ambos bloques están
físicamente en la misma locación.
 En el caso de copias remotas, uno de los bloques es
local y el otro está en un sitio remoto.
 Implementación de Memoria Estable

La Operación Output(B)
 Una operación de salida se ejecuta como sigue:

 Escribir la información en el primer bloque físico.

 Una vez que se completa con éxito la primera escritura,
escribir la misma información en el segundo bloque
físico.
 La salida está completa sólo después de terminar con
éxito la segunda escritura.
Implementación de Memoria Estable

 Durante la recuperación, se examina cada par de

bloques físicos.
 Si los dos son iguales y no existen errores detectables,
no es necesario tomar más acciones.
 Si un bloque contiene un error detectable (checksum),
se sustituye su contenido por el valor del segundo
bloque.
 Si ambos bloques no contienen errores detectables,
pero el contenido es diferente, entonces se sustituye el
contenido del primer bloque por el valor del segundo.
 Este procedimiento garantiza que una escritura en
almacenamiento estable termine con éxito o no
produzca cambio alguno.