Atomicidad, Durabilidad y Concurrencia en Sistemas de Bases de Datos

Implementación de la Atomicidad y la Durabilidad

La atomicidad y la durabilidad se implementan a través del componente de gestión de recuperaciones, utilizando el esquema de Copia Sombra. Este esquema asegura que solo haya una copia activa de la base de datos en cada momento.

• Se crea una copia completa de la base de datos.
• Los cambios se realizan en la nueva copia (NC).
• Se consulta al sistema operativo (SO) si todas las páginas de la NC se han escrito en disco.
• Se actualiza el puntero_db para que apunte a la NC, convirtiéndola en la base de datos activa.
• La copia antigua se borra.

Una transacción se considera comprometida cuando se actualiza el puntero_db en el disco, apuntando a la nueva copia, y esta se convierte en la base de datos actual. La copia antigua se borra.

Si en cualquier momento es necesario abortar la transacción antes de que se comprometa, la nueva copia se borra y la antigua permanece intacta, ya que el puntero nunca se actualizó.

Muchos editores de texto utilizan una implementación similar, renombrando el archivo nuevo para que tenga el nombre del archivo actual.

La implementación de la atomicidad y la durabilidad depende de que la escritura del puntero_db sea una operación atómica, lo cual es asegurado por el sistema de disco.

Inconvenientes: Este método es extremadamente ineficiente porque la ejecución de una simple transacción requiere copiar toda la base de datos y no permite transacciones concurrentes.

Ejecuciones Concurrentes

Los sistemas de procesamiento de transacciones normalmente permiten la ejecución de varias transacciones concurrentemente. Permitir que varias transacciones actualicen los datos de forma concurrente introduce complicaciones en la consistencia de los mismos. Aunque esto requiere un esfuerzo adicional, es más sencillo exigir que las transacciones se ejecuten secuencialmente. Sin embargo, existen dos razones importantes para permitir la concurrencia:

• Productividad y mejor utilización de los recursos: La CPU y los discos pueden trabajar en paralelo, incrementando la productividad y la utilización del procesador y del disco, ya que están menos tiempo desocupados.
• Tiempo de espera reducido: Pueden existir transacciones cortas y otras largas. Al ejecutarse en paralelo, la transacción corta no debe esperar a que finalice una larga, reduciendo el tiempo de respuesta.

Cuando se ejecutan varias transacciones concurrentemente, la consistencia de la base de datos puede verse comprometida, incluso si cada transacción individual es correcta. Por lo tanto, el sistema de base de datos debe implementar planificaciones que garanticen la consistencia.

Ejemplo:

• T1: Transacción para transferir $50 de la cuenta A a la cuenta B. Estado Inicial: A=1000 y B=2000, A+B=3000
• T2: Transacción para transferir el 10% del saldo de la cuenta A a la B.

Planificaciones

Las planificaciones representan el orden cronológico en el que se ejecutan las instrucciones en el sistema. Se debe respetar el orden de las instrucciones de cada transacción individual.

Planificación 1: Las transacciones se ejecutan secuencialmente en el orden T1 (termina) seguida de T2.

Planificación 2: Las transacciones se ejecutan secuencialmente en el orden T2 (termina) seguida de T1. Para un conjunto de n transacciones, existen n! planificaciones secuenciales válidas.

Si dos transacciones se ejecutan concurrentemente, el SO puede ejecutar una transacción durante un tiempo, luego la segunda transacción durante un tiempo, cambiar de nuevo a T1 y así sucesivamente. Si hay muchas transacciones, todas comparten el tiempo de la CPU.

Planificación 3: Las transacciones se ejecutan concurrentemente (primero T1, luego T2, luego T1 y termina T2).

Planificación 4: Las transacciones se ejecutan concurrentemente. El estado final es inconsistente. No todas las ejecuciones concurrentes producen un estado correcto. Si se deja el control al SO, puede llevar a la base de datos a un estado inconsistente.

El componente de control de concurrencia es el encargado de asegurar que cualquier planificación que se ejecute lleve a la base de datos a un estado consistente.