UT 7 – Concurrencia y control de transacciones

1. Transacciones

1.1 Concepto de transacción

Una transacción es una unidad lógica de trabajo que agrupa un conjunto de operaciones
que se ejecutan sobre una base de datos y que deben considerarse como una única
operación indivisible.

Desde el punto de vista del sistema, una transacción representa una secuencia de
acciones que:

 acceden a los datos,

 los modifican,
 y llevan a la base de datos desde un estado consistente inicial a un estado
consistente final.

El SGBD debe garantizar que una transacción se ejecute completamente o no se ejecute

en absoluto.

1.2 Transacción como unidad básica de procesamiento

En un SGBD, la transacción es la unidad básica para:

 el control de concurrencia,
 la recuperación ante fallos,
 la preservación de la consistencia de los datos.

Todas las técnicas que se estudian en esta unidad (bloqueos, secuencialidad,

recuperación, control de concurrencia) se aplican sobre transacciones, no sobre
operaciones aisladas.

Por este motivo, el SGBD no razona en términos de sentencias individuales, sino en

términos de transacciones completas.

1.3 Operaciones de una transacción

Una transacción está compuesta por una secuencia de operaciones elementales, entre las
que se destacan:
  Lectura (read): obtiene el valor de un dato desde la base de datos.
 Escritura (write): modifica el valor de un dato en la base de datos.
 Confirmación (commit): indica que la transacción ha finalizado correctamente y
que sus cambios pueden hacerse permanentes.
 Retroceso (rollback): indica que la transacción no puede completarse y que sus
efectos deben deshacerse.

Estas operaciones son gestionadas internamente por el SGBD y constituyen la base para el
control y la recuperación.

1.4 Estados de una transacción

Durante su ejecución, una transacción puede atravesar distintos estados, que describen
su situación dentro del sistema.

Los estados principales son:

 Activa: la transacción se encuentra en ejecución y realizando operaciones.

 Parcialmente confirmada: la transacción ha ejecutado su última operación, pero
aún no se han hecho permanentes sus cambios.
 Confirmada (commit): la transacción ha finalizado correctamente y sus efectos han
sido registrados de forma permanente.
 Fallida: la transacción no puede continuar debido a un error o condición anómala.
 Abortada (rollback): la transacción ha sido revertida y la base de datos ha sido
restaurada al estado anterior a su inicio.

El SGBD controla estos estados para decidir si debe consolidar o deshacer los efectos de la
transacción.

1.5 Importancia de las transacciones

El uso de transacciones permite:

 garantizar la consistencia de los datos,

 manejar errores de manera controlada,
 permitir la ejecución concurrente de múltiples usuarios,
 recuperar el sistema ante fallos.

Sin el concepto de transacción, no sería posible asegurar un comportamiento confiable del

sistema frente a accesos simultáneos o fallos.
2. Propiedades ACID
Las propiedades ACID definen un conjunto de requisitos que toda transacción debe
cumplir para garantizar el funcionamiento correcto y confiable de un sistema de bases de
datos.
El acrónimo ACID hace referencia a:
 Atomicidad
 Consistencia
 Aislamiento
 Durabilidad
Estas propiedades constituyen el marco teórico fundamental sobre el cual se apoyan:
 el control de concurrencia,
 los mecanismos de recuperación,
 y la gestión de fallos.

2.1 Atomicidad (Atomicity)

La atomicidad establece que una transacción debe ejecutarse de manera todo o nada.
Esto significa que:
 o bien todas las operaciones de la transacción se ejecutan correctamente,
 o bien ninguna de ellas produce efecto sobre la base de datos.
Si durante la ejecución ocurre un error, el SGBD debe:
 deshacer todos los cambios realizados por la transacción,
 restaurar la base de datos al estado previo al inicio de la misma.
La atomicidad se garantiza mediante:
 mecanismos de rollback,
 registros de recuperación,
 control de estados de la transacción.
2.2 Consistencia (Consistency)
La consistencia establece que una transacción debe llevar a la base de datos:
 desde un estado consistente inicial,
 a otro estado consistente final.
Un estado consistente es aquel que:
 cumple todas las restricciones de integridad definidas,
 respeta las reglas del dominio del problema.
La responsabilidad de la consistencia se reparte entre:
 el diseño de la base de datos (restricciones, claves, reglas),
 la lógica de las transacciones,
 y el SGBD, que debe asegurar que solo se confirmen transacciones válidas.
Una transacción que viola la consistencia no debe confirmarse.
2.3 Aislamiento (Isolation)
El aislamiento establece que las transacciones concurrentes deben ejecutarse de manera
tal que:
 el resultado final sea equivalente al de alguna ejecución secuencial de las mismas.
Desde el punto de vista de cada transacción:
 las demás transacciones no deben interferir con su ejecución,
 los efectos parciales de otras transacciones no deben ser visibles.
Si no se garantiza el aislamiento, pueden producirse fenómenos como:
 lecturas sucias,
 actualizaciones perdidas,
 lecturas no repetibles,
 lecturas fantasma.
El aislamiento es la propiedad que da origen a:
 los problemas de concurrencia,
 los esquemas de control de concurrencia,
 los distintos niveles de aislamiento.
2.4 Durabilidad (Durability)
La durabilidad establece que, una vez que una transacción ha sido confirmada:
 sus efectos deben persistir,
 incluso frente a fallos del sistema.
Esto implica que:
 los cambios confirmados no pueden perderse,
 deben almacenarse en medios no volátiles.
La durabilidad se logra mediante:
 registros en disco,
 técnicas de recuperación,
 mecanismos de respaldo.
Aun ante caídas del sistema, el SGBD debe ser capaz de restaurar los efectos de las
transacciones confirmadas.

2.5 Relación entre las propiedades ACID

Las propiedades ACID no actúan de manera aislada, sino que:
 se complementan entre sí,
 definen el comportamiento correcto de las transacciones.
En particular:
 la atomicidad y la durabilidad están estrechamente ligadas a la recuperación ante
fallos,
 el aislamiento está directamente relacionado con el control de concurrencia,
 la consistencia es el objetivo final que se busca preservar.

2.6 Importancia de ACID en el control de concurrencia

El estudio de la concurrencia se centra principalmente en preservar:
 el aislamiento,
 y, como consecuencia, la consistencia de la base de datos.
Las técnicas que se analizan a continuación (planificaciones, secuencialidad, bloqueos,
multiversión) tienen como objetivo permitir:
 la ejecución concurrente de transacciones,
 sin violar las propiedades ACID.
Por este motivo, las propiedades ACID constituyen el marco conceptual previo al análisis
de la concurrencia.

3. Concurrencia y planificaciones

3.1 Concurrencia en sistemas de bases de datos

En un Sistema de Gestión de Bases de Datos (SGBD), existe concurrencia cuando dos o

más transacciones se ejecutan de manera simultánea, accediendo a los mismos datos.

La concurrencia es necesaria porque:

 permite atender múltiples usuarios al mismo tiempo,

 mejora el aprovechamiento de los recursos del sistema,
 incrementa el rendimiento global.

Sin embargo, la ejecución concurrente introduce riesgos, ya que el intercalado de

operaciones puede provocar inconsistencias si no se controla adecuadamente.

El objetivo del SGBD es permitir la concurrencia sin violar las propiedades ACID, en
particular el aislamiento.

3.2 Planificación de transacciones

Una planificación (o schedule) es el orden en el que se ejecutan e intercalan las

operaciones de un conjunto de transacciones.

Una planificación especifica:

 qué operaciones se ejecutan,

 en qué orden,
 y cómo se intercalan las operaciones de distintas transacciones.
Las operaciones consideradas en una planificación son:

 lectura de datos,
 escritura de datos,
 confirmación (commit),
 retroceso (rollback).

La planificación es el modelo que permite analizar formalmente el comportamiento

concurrente de las transacciones.

3.3 Planificación secuencial

Una planificación secuencial es aquella en la que:

 una transacción se ejecuta completamente antes de que comience la siguiente,

 no existe intercalado de operaciones entre transacciones.

Características:

 no hay concurrencia,
 no se producen conflictos,
 la base de datos pasa siempre de un estado consistente a otro estado consistente.

Las planificaciones secuenciales son correctas por definición, pero poco eficientes, ya que
desaprovechan el paralelismo del sistema.

3.4 Planificaciones concurrentes

Una planificación concurrente es aquella en la que:

 las operaciones de varias transacciones se intercalan,

 distintas transacciones pueden ejecutarse parcialmente al mismo tiempo.

Este tipo de planificación:

 mejora el rendimiento,
 incrementa la concurrencia,
 pero puede producir resultados incorrectos si no se controla.

No toda planificación concurrente es válida.

El desafío del control de concurrencia es determinar qué planificaciones concurrentes son
aceptables.
3.5 Estados consistentes e inconsistentes

Un estado consistente de la base de datos es aquel que:

 cumple todas las restricciones de integridad,

 representa una situación válida del sistema.

Un estado inconsistente es aquel en el que:

 alguna restricción se viola,

 los datos dejan de reflejar una situación válida.

El SGBD debe garantizar que:

 toda planificación comience en un estado consistente,

 y finalice en un estado consistente.

Una planificación que deja la base de datos en un estado inconsistente es incorrecta.

3.6 Equivalencia entre planificaciones

Dos planificaciones se consideran equivalentes si:

 parten del mismo estado inicial,

 producen el mismo estado final de la base de datos.

La equivalencia permite comparar:

 una planificación concurrente,

 con una planificación secuencial.

Si una planificación concurrente es equivalente a alguna planificación secuencial, se

considera correcta, ya que respeta la consistencia de los datos.

Este concepto es la base para definir formalmente cuándo una ejecución concurrente es
aceptable.

3.7 Importancia del análisis de planificaciones

El estudio de las planificaciones permite:

 analizar el efecto de la concurrencia,

 identificar posibles inconsistencias,
 establecer criterios de corrección para ejecuciones concurrentes.
A partir de este análisis se introducen:

 los conflictos entre operaciones,

 las nociones de secuencialidad,
 y los mecanismos de control de concurrencia.

4. Conflictos de concurrencia

4.1 Concepto de conflicto de concurrencia

Un conflicto de concurrencia se produce cuando la intercalación de operaciones de

distintas transacciones genera un resultado distinto al que se obtendría si dichas
transacciones se ejecutaran de forma secuencial.

Los conflictos aparecen cuando:

 dos o más transacciones acceden a los mismos datos,

 al menos una de ellas realiza una escritura,
 y las operaciones se intercalan sin un control adecuado.

Estos conflictos pueden provocar estados inconsistentes de la base de datos y violar las
propiedades ACID, especialmente el aislamiento.

4.2 Actualización perdida

La actualización perdida ocurre cuando:

 dos transacciones leen el mismo dato,

 ambas realizan una modificación,
 y una de las actualizaciones sobrescribe a la otra sin tenerla en cuenta.

Como consecuencia, una de las modificaciones se pierde, aunque la transacción haya

finalizado correctamente.

Ejemplo conceptual

 La transacción T1 lee un dato X.

 La transacción T2 lee el mismo dato X.
 T1 modifica X y escribe el nuevo valor.
 T2 modifica X y escribe su valor, sobrescribiendo el de T1.

El resultado final no refleja correctamente ambas operaciones.

4.3 Dependencia no confirmada (lectura sucia)

La dependencia no confirmada, también conocida como lectura sucia, ocurre cuando:

 una transacción lee un dato que ha sido modificado por otra transacción,
 pero dicha modificación aún no ha sido confirmada.

Si la transacción que realizó la modificación falla y se revierte, la transacción que leyó ese
valor habrá trabajado con un dato inválido.

Ejemplo conceptual

 T1 modifica un dato X.
 T2 lee el nuevo valor de X antes de que T1 confirme.
 T1 falla y realiza un rollback.

T2 utilizó un valor que nunca debió haber sido visible.

4.4 Análisis inconsistente

El análisis inconsistente ocurre cuando:

 una transacción realiza un cálculo sobre un conjunto de datos,

 mientras otra transacción modifica parte de esos datos,
 y el cálculo se realiza sobre valores mezclados.

El resultado obtenido no corresponde a ningún estado consistente de la base de datos.

Ejemplo conceptual

 T1 calcula un total recorriendo varios registros.

 Mientras T1 está calculando, T2 modifica algunos de esos registros.
 El resultado final de T1 combina datos antes y después de la modificación.

4.5 Lectura no repetible

La lectura no repetible ocurre cuando:

 una transacción lee un dato,

 otra transacción lo modifica y confirma,
 y la primera transacción vuelve a leer el mismo dato obteniendo un valor
diferente.

Esto implica que el valor leído no se mantiene estable durante la transacción.

Ejemplo conceptual

 T1 lee el dato X.
 T2 modifica X y confirma.
 T1 vuelve a leer X y obtiene un valor distinto.

4.6 Lectura fantasma

La lectura fantasma ocurre cuando:

 una transacción ejecuta una consulta que recupera un conjunto de filas,

 otra transacción inserta o elimina filas que cumplen la condición,
 y la primera transacción vuelve a ejecutar la consulta obteniendo un conjunto
diferente.

Aparecen “filas fantasma” que antes no existían.

Ejemplo conceptual

 T1 consulta todas las filas que cumplen una condición.

 T2 inserta una nueva fila que cumple dicha condición y confirma.
 T1 repite la consulta y obtiene un resultado distinto.

4.7 Relación entre los conflictos y el aislamiento

Todos los conflictos de concurrencia son consecuencia de un aislamiento insuficiente

entre transacciones.

Cada uno de estos fenómenos:

 viola el aislamiento,
 puede llevar a estados inconsistentes,
 justifica la necesidad de mecanismos de control de concurrencia.

La prevención de estos conflictos es uno de los principales objetivos de:

 los protocolos de bloqueo,

 los esquemas multiversión,
 y los niveles de aislamiento.
4.8 Importancia del estudio de los conflictos

El análisis de los conflictos de concurrencia permite:

 comprender por qué no toda ejecución concurrente es válida,

 justificar el uso de mecanismos de control,
 relacionar los problemas prácticos con las propiedades ACID.

A partir de estos conflictos, la UT 7 introduce:

 las nociones de secuencialidad,

 la recuperabilidad,
 y los protocolos de control de concurrencia.

5. Secuencialidad

5.1 Concepto de secuencialidad

Una planificación secuencial es aquella en la que las transacciones se ejecutan una

después de la otra, sin intercalarse.
Este tipo de ejecución garantiza, por definición, la consistencia de la base de datos.

Sin embargo, en sistemas reales se utilizan planificaciones concurrentes, por lo que surge
la necesidad de determinar cuándo una planificación concurrente es correcta.

La noción de secuencialidad permite responder a esta pregunta.

5.2 Secuencialidad de una planificación

Una planificación concurrente se considera secuencializable si es equivalente a alguna

planificación secuencial.

Esto significa que:

 aunque las operaciones estén intercaladas,

 el resultado final es el mismo que el de una ejecución secuencial válida.

La secuencialidad es un criterio de corrección lógica para las planificaciones concurrentes.

5.3 Secuencialidad en cuanto a conflictos

Una planificación es secuencializable en cuanto a conflictos si:

 puede transformarse en una planificación secuencial,

 intercambiando únicamente operaciones no conflictivas.

Dos operaciones entran en conflicto cuando:

 pertenecen a transacciones distintas,

 acceden al mismo dato,
 y al menos una de ellas es una escritura.

Si una planificación es secuencializable en cuanto a conflictos, entonces:

 preserva la consistencia,
 y es aceptable desde el punto de vista del control de concurrencia.

Este tipo de secuencialidad es el más utilizado en los SGBD, ya que es fácil de verificar y
de implementar.

5.4 Secuencialidad en cuanto a vistas

Una planificación es secuencializable en cuanto a vistas si:

 es equivalente a una planificación secuencial desde el punto de vista de los valores

leídos y escritos,
 aunque no pueda transformarse intercambiando solo operaciones no conflictivas.

La secuencialidad en cuanto a vistas es un criterio más general que la secuencialidad en

cuanto a conflictos.

Toda planificación secuencializable en cuanto a conflictos es también secuencializable en

cuanto a vistas, pero no a la inversa.

5.5 Relación entre ambos tipos de secuencialidad

Existe la siguiente relación:

 Secuencialidad en cuanto a conflictos ⊂ Secuencialidad en cuanto a vistas

Esto implica que:

 el conjunto de planificaciones secuencializables en cuanto a conflictos es un

subconjunto del de vistas,
 los SGBD suelen implementar mecanismos que garantizan secuencialidad en
cuanto a conflictos.

La razón es que:

 verificar secuencialidad en cuanto a vistas es computacionalmente complejo,

 mientras que la secuencialidad por conflictos puede garantizarse mediante
protocolos de control.

5.6 Importancia de la secuencialidad

La secuencialidad permite:

 definir formalmente cuándo una ejecución concurrente es correcta,

 establecer la base teórica de los protocolos de control de concurrencia,
 relacionar concurrencia con aislamiento y consistencia.

A partir de este concepto se introducen:

 las planificaciones recuperables,

 los problemas de retroceso,
 y los mecanismos de recuperación ante fallos.

5.7 Relación con los temas siguientes

La secuencialidad asegura la corrección lógica de una planificación, pero no garantiza por

sí sola la recuperabilidad.

Por este motivo, el siguiente paso es analizar:

 qué ocurre cuando una transacción falla,

 cómo afecta a otras transacciones,
 y qué planificaciones permiten una recuperación segura.

Esto da lugar al estudio de la recuperabilidad.

6. Recuperabilidad

6.1 Concepto de recuperabilidad

Una planificación recuperable es aquella que permite que el SGBD recupere

correctamente la base de datos ante el fallo de una o más transacciones.

La recuperabilidad se refiere a la relación entre las operaciones de lectura, escritura y

confirmación de distintas transacciones, y a cómo estas relaciones afectan la posibilidad
de realizar rollback sin comprometer la consistencia de los datos.

Una planificación puede ser secuencializable y, sin embargo, no ser recuperable.

6.2 Planificaciones recuperables

Una planificación es recuperable si cumple que:

 si una transacción T2 lee un dato escrito por otra transacción T1,

 entonces T2 no puede confirmar antes que T1.

De este modo, si T1 falla:

 T2 todavía no habrá confirmado,

 y podrá deshacerse sin dejar efectos inconsistentes.

La recuperabilidad garantiza que:

 los efectos de una transacción dependiente no se hagan permanentes antes que

los de la transacción de la cual depende.

6.3 Planificaciones no recuperables

Una planificación es no recuperable cuando:

 una transacción T2 lee datos modificados por T1,

 T2 confirma,
 y posteriormente T1 falla y realiza un rollback.

En este caso:

 T2 ya ha confirmado cambios basados en datos inválidos,

 y no existe forma de recuperar la base de datos sin violar la consistencia.

Las planificaciones no recuperables son inaceptables en un SGBD.

6.4 Retroceso en cascada

El retroceso en cascada ocurre cuando:

 una transacción falla,

 y otras transacciones que leyeron datos no confirmados de ella
 deben también ser revertidas.

Este efecto puede propagarse, generando una cadena de rollbacks.

El retroceso en cascada:

 incrementa el costo de recuperación,

 reduce el rendimiento,
 y puede afectar a múltiples transacciones.

6.5 Planificaciones sin retroceso en cascada

Una planificación es sin retroceso en cascada si:

 ninguna transacción lee datos escritos por otra transacción antes de que esta
confirme.

En este tipo de planificación:

 no existen dependencias con datos no confirmados,

 un fallo afecta únicamente a la transacción que falla,
 la recuperación es más simple y eficiente.

Las planificaciones sin retroceso en cascada son preferibles desde el punto de vista del
diseño del sistema.

6.6 Relación entre recuperabilidad y secuencialidad

La secuencialidad garantiza la corrección lógica de una planificación.

La recuperabilidad garantiza que los fallos puedan manejarse correctamente.

Una planificación correcta debe ser:

 secuencializable,
 recuperable,
 y, preferentemente, sin retroceso en cascada.

Estos criterios se utilizan como base para el diseño de los protocolos de control de
concurrencia.
6.7 Importancia de la recuperabilidad

El análisis de la recuperabilidad permite:

 comprender el impacto de los fallos sobre transacciones concurrentes,

 justificar restricciones adicionales sobre las planificaciones,
 enlazar concurrencia con recuperación ante fallos.

A partir de este concepto, la UT 7 introduce:

 los mecanismos de recuperación ante fallos,

 las técnicas de undo y redo,
 y el uso de registros de recuperación.

7. Recuperación ante fallos

7.1 Concepto de recuperación ante fallos

La recuperación ante fallos comprende el conjunto de mecanismos y técnicas que utiliza

el SGBD para restaurar la base de datos a un estado consistente cuando ocurre un fallo.

Un fallo puede producirse:

 durante la ejecución de una transacción,

 durante la ejecución concurrente de varias transacciones,
 o por una falla del sistema.

El objetivo de la recuperación es garantizar que:

 las transacciones confirmadas mantengan sus efectos,

 las transacciones no confirmadas no dejen efectos parciales en la base de datos.

7.2 Tipos de fallos

La cátedra distingue principalmente los siguientes tipos de fallos:

7.2.1 Fallos de transacción

Ocurren cuando una transacción no puede continuar su ejecución debido a:

  errores lógicos,
 violación de restricciones,
 errores de aplicación,
 abortos explícitos.

En estos casos:

 solo la transacción afectada debe ser revertida,

 el resto del sistema continúa funcionando.

7.2.2 Fallos del sistema

Ocurren cuando el sistema deja de funcionar debido a:

 cortes de energía,
 fallas del sistema operativo,
 caídas del SGBD.

En este tipo de fallos:

 se pierde el contenido de la memoria principal,

 pero no se pierde el contenido del almacenamiento estable.

El SGBD debe recuperar el estado correcto al reiniciarse.

7.2.3 Fallos del medio de almacenamiento

Ocurren cuando se produce una falla física del dispositivo de almacenamiento, como:

 daños en el disco,
 pérdida total de datos almacenados.

Este tipo de fallos es el más grave y requiere:

 mecanismos de respaldo,
 restauración desde copias de seguridad.
7.3 Almacenamiento y recuperación

Para comprender la recuperación, la cátedra distingue distintos tipos de almacenamiento:

 Memoria volátil: pierde su contenido ante un fallo (ej. memoria principal).

 Memoria no volátil: conserva su contenido ante fallos del sistema (ej. disco).
 Almacenamiento estable: medio altamente confiable, utilizado para información
crítica de recuperación.

Los mecanismos de recuperación se apoyan en la diferencia entre estos tipos de

almacenamiento.

7.4 Registro histórico (log)

El registro histórico, o log, es una estructura fundamental para la recuperación ante fallos.

En el log se registran:

 el inicio de una transacción,

 las operaciones de escritura realizadas,
 los valores anteriores y posteriores de los datos,
 la confirmación o aborto de la transacción.

El log permite al SGBD:

 deshacer operaciones (undo),

 rehacer operaciones (redo),
 reconstruir el estado correcto de la base de datos tras un fallo.

7.5 Operaciones undo y redo

 Undo: revierte los efectos de una transacción que no ha confirmado.

 Redo: reaplica los efectos de una transacción que sí ha confirmado.

Durante la recuperación:

 las transacciones no confirmadas deben ser deshechas,

 las transacciones confirmadas deben rehacerse si fuera necesario.

Estas operaciones garantizan la atomicidad y la durabilidad.

7.6 Técnicas de recuperación

Las técnicas de recuperación definen cuándo y cómo se aplican las operaciones undo y
redo.

La cátedra distingue principalmente:

 Actualización inmediata: los cambios se reflejan en la base de datos antes del

commit.
 Actualización diferida: los cambios se aplican a la base de datos solo después del
commit.

Cada técnica tiene implicancias distintas en el uso del log y en el proceso de recuperación.

7.7 Relación entre recuperación y propiedades ACID

La recuperación ante fallos está directamente relacionada con:

 la atomicidad, asegurando que las transacciones se ejecuten todo o nada,

 la durabilidad, asegurando que los efectos confirmados no se pierdan.

Sin mecanismos de recuperación, las propiedades ACID no podrían garantizarse.

7.8 Importancia de la recuperación ante fallos

La recuperación ante fallos permite:

 preservar la consistencia de la base de datos,

 mantener la confiabilidad del sistema,
 garantizar la continuidad del servicio ante errores y fallas.

A partir de estos conceptos, la UT 7 profundiza en:

 las técnicas específicas de recuperación,

 el uso de puntos de recuperación,
 y los esquemas avanzados de recuperación.

8. Técnicas de recuperación y puntos de recuperación

8.1 Técnicas de recuperación

Las técnicas de recuperación determinan la forma en que el SGBD utiliza el registro

histórico (log) para restaurar la base de datos a un estado consistente luego de un fallo.
Estas técnicas establecen:

 en qué momento se reflejan los cambios en la base de datos,

 cuándo se registran en el log,
 y cómo se aplican las operaciones undo y redo durante la recuperación.

8.2 Actualización inmediata

En la actualización inmediata, los cambios realizados por una transacción:

 se escriben en la base de datos antes de que la transacción confirme,

 pero siempre se registra previamente la información necesaria en el log.

En este esquema:

 pueden existir en la base de datos cambios de transacciones no confirmadas,

 por lo tanto, ante un fallo, es necesario:
o deshacer (undo) las transacciones no confirmadas,
o rehacer (redo) las transacciones confirmadas.

Este tipo de actualización requiere:

 un uso intensivo del log,

 mecanismos de recuperación más complejos,
 pero permite mayor concurrencia y mejor rendimiento.

8.3 Actualización diferida

En la actualización diferida, los cambios realizados por una transacción:

 no se aplican inmediatamente a la base de datos,

 se mantienen registrados en el log o en estructuras temporales,
 y se reflejan en la base de datos solo después del commit.

En este esquema:

 la base de datos nunca contiene cambios de transacciones no confirmadas,

 ante un fallo solo es necesario aplicar redo,
 no se requieren operaciones de undo.

La actualización diferida simplifica la recuperación, pero puede:

 aumentar el tiempo de confirmación,

 limitar el grado de concurrencia.
8.4 Comparación entre actualización inmediata y diferida

 La actualización inmediata:
o permite mayor concurrencia,
o requiere undo y redo,
o implica mayor complejidad de recuperación.
 La actualización diferida:
o simplifica la recuperación,
o solo requiere redo,
o puede afectar el rendimiento en sistemas con alta concurrencia.

El SGBD selecciona la técnica más adecuada según:

 el diseño del sistema,

 los requisitos de rendimiento,
 la confiabilidad del entorno.

8.5 Punto de recuperación (checkpoint)

Un punto de recuperación, o checkpoint, es un mecanismo que permite:

 reducir el tiempo de recuperación,

 limitar la cantidad de información del log que debe analizarse tras un fallo.

En un checkpoint, el SGBD:

 fuerza la escritura en disco de los datos modificados,

 registra en el log que se ha alcanzado un punto consistente,
 establece un punto de referencia para futuras recuperaciones.

8.6 Recuperación utilizando checkpoints

Cuando ocurre un fallo:

 el SGBD no necesita analizar todo el log desde el inicio,

 solo debe examinar las entradas registradas a partir del último checkpoint.

Esto permite:

 acelerar el proceso de recuperación,

 reducir el costo de análisis del log,
 mejorar la disponibilidad del sistema.
8.7 Importancia de los puntos de recuperación

El uso de checkpoints:

 reduce el tiempo de recuperación,

 limita el crecimiento del log,
 mejora la eficiencia general del sistema.

Por este motivo, los puntos de recuperación son una pieza clave en los esquemas de
recuperación modernos.

8.8 Relación con los temas siguientes

Las técnicas de recuperación y los checkpoints:

 garantizan atomicidad y durabilidad,

 complementan el control de concurrencia,
 permiten que el sistema se recupere de fallos de manera confiable.

A partir de aquí, la UT 7 continúa con:

 protocolos de control de concurrencia,

 esquemas basados en bloqueo,
 y mecanismos avanzados de ejecución concurrente.

9. Control de concurrencia y protocolos de bloqueo

9.1 Control de concurrencia

El control de concurrencia es el conjunto de mecanismos que utiliza el SGBD para:

 permitir la ejecución concurrente de transacciones,

 preservando la consistencia de la base de datos,
 y garantizando el aislamiento definido por las propiedades ACID.

El objetivo principal del control de concurrencia es asegurar que:

 las planificaciones concurrentes sean correctas,

 es decir, equivalentes a alguna planificación secuencial válida.
9.2 Rol del gestor de control de concurrencia

El SGBD incorpora un componente específico denominado gestor de control de

concurrencia, encargado de:

 coordinar el acceso simultáneo a los datos,

 detectar y prevenir conflictos entre transacciones,
 imponer restricciones sobre el orden de ejecución de las operaciones.

Este gestor actúa de forma transparente para el usuario y las aplicaciones.

9.3 Protocolos de control de concurrencia

Un protocolo de control de concurrencia define un conjunto de reglas que determinan:

 cuándo una transacción puede acceder a un dato,

 en qué condiciones debe esperar,
 y cuándo puede liberar los recursos utilizados.

Entre los distintos enfoques existentes, la cátedra se centra en los protocolos basados en
bloqueo, por ser los más utilizados en los SGBD tradicionales.

9.4 Bloqueos (locks)

Un bloqueo es un mecanismo mediante el cual una transacción obtiene el derecho a

acceder a un dato, impidiendo o restringiendo el acceso de otras transacciones.

Los bloqueos permiten:

 evitar conflictos,
 controlar el intercalado de operaciones,
 garantizar la secuencialidad de las planificaciones.

9.5 Tipos de bloqueos

La cátedra distingue principalmente dos tipos de bloqueos:

 Bloqueo compartido (C)

Permite que una transacción lea un dato.
Varias transacciones pueden mantener bloqueos compartidos sobre el mismo dato
al mismo tiempo.
 Bloqueo exclusivo (X)
Permite que una transacción lea y escriba un dato.
Mientras un dato esté bajo un bloqueo exclusivo, ninguna otra transacción puede
acceder a él.
9.6 Compatibilidad de bloqueos

La compatibilidad de bloqueos determina si dos bloqueos pueden coexistir sobre el mismo

dato.

 Un bloqueo compartido es compatible con otro bloqueo compartido.

 Un bloqueo exclusivo no es compatible con ningún otro bloqueo.

Estas reglas permiten controlar el acceso concurrente y prevenir conflictos.

9.7 Operaciones de bloqueo y desbloqueo

Antes de acceder a un dato, una transacción debe:

 solicitar el bloqueo correspondiente,

 esperar si el bloqueo no puede otorgarse inmediatamente.

Una vez finalizado el uso del dato:

 la transacción libera el bloqueo,

 permitiendo que otras transacciones accedan al recurso.

La política de adquisición y liberación de bloqueos es clave para garantizar la corrección de

las planificaciones.

9.8 Problemas asociados a los bloqueos

El uso de bloqueos puede generar ciertos problemas, entre los que se destacan:

 Inanición (starvation): una transacción espera indefinidamente porque otros

accesos tienen prioridad.
 Interbloqueo (deadlock): dos o más transacciones se bloquean mutuamente,
esperando recursos que ninguna puede liberar.

La cátedra se centra en el concepto de estos problemas, no en algoritmos específicos de

detección o prevención.

9.9 Relación con los temas siguientes

Los protocolos básicos de bloqueo permiten controlar la concurrencia, pero no garantizan

por sí solos:

 la secuencialidad,
 la ausencia de retrocesos en cascada.
10. Protocolo de bloqueo de dos fases (2PL)

10.1 Concepto de protocolo de bloqueo de dos fases

El protocolo de bloqueo de dos fases (Two-Phase Locking – 2PL) es un protocolo de

control de concurrencia que garantiza que las planificaciones generadas sean
secuencializables en cuanto a conflictos.

El protocolo recibe su nombre porque divide la ejecución de una transacción en dos fases
bien diferenciadas, relacionadas con el uso de bloqueos.

10.2 Fases del protocolo 2PL

El protocolo 2PL establece que toda transacción debe cumplir las siguientes fases:

Fase de crecimiento

Durante esta fase:

 la transacción puede solicitar bloqueos (compartidos o exclusivos),

 no puede liberar ningún bloqueo.

En esta etapa, el conjunto de bloqueos de la transacción solo puede aumentar.

Fase de decrecimiento

Durante esta fase:

 la transacción puede liberar bloqueos,

 no puede solicitar nuevos bloqueos.

Una vez que una transacción libera su primer bloqueo, entra definitivamente en la fase de
decrecimiento.

10.3 Punto de bloqueo

El punto de bloqueo es el instante en el que una transacción:

 ha adquirido todos los bloqueos que necesitará,

 y a partir del cual comienza la fase de decrecimiento.

Este punto es importante porque:

 define el orden relativo entre transacciones,

 permite razonar sobre la secuencialidad de la planificación.
10.4 Propiedades del protocolo 2PL

El protocolo 2PL garantiza que:

 las planificaciones resultantes sean secuencializables en cuanto a conflictos,

 no se produzcan conflictos de concurrencia como actualizaciones perdidas o
lecturas inconsistentes.

Sin embargo, el protocolo no garantiza por sí solo:

 la ausencia de retrocesos en cascada,

 ni la recuperabilidad de la planificación.

10.5 Limitaciones del protocolo 2PL

A pesar de sus ventajas, el protocolo 2PL presenta algunas limitaciones:

 Puede generar interbloqueos (deadlocks).

 Puede permitir lecturas de datos no confirmados, lo que da lugar a retrocesos en
cascada.
 No garantiza que una planificación sea recuperable en todos los casos.

Por estas razones, se introducen variantes más restrictivas del protocolo.

10.6 Protocolo 2PL estricto

En el 2PL estricto:

 los bloqueos exclusivos (X) se mantienen hasta que la transacción confirma o

aborta,
 los bloqueos compartidos pueden liberarse antes.

Este protocolo:

 evita la lectura de datos no confirmados,

 garantiza que las planificaciones sean sin retroceso en cascada,
 facilita la recuperación ante fallos.
10.7 Protocolo 2PL riguroso

En el 2PL riguroso:

 todos los bloqueos (compartidos y exclusivos) se mantienen hasta el commit o

rollback.

Este enfoque:

 simplifica aún más la recuperación,

 garantiza planificaciones recuperables y sin retroceso en cascada,
 puede reducir el grado de concurrencia.

10.8 Comparación entre 2PL clásico, estricto y riguroso

 2PL clásico:
Garantiza secuencialidad en cuanto a conflictos, pero puede generar retrocesos en
cascada.
 2PL estricto:
Evita retrocesos en cascada y facilita la recuperación.
 2PL riguroso:
Ofrece la mayor seguridad, a costa de menor concurrencia.

La elección del protocolo depende de los requisitos del sistema.

10.9 Relación con los temas siguientes

El protocolo 2PL resuelve muchos problemas de concurrencia, pero:

 puede limitarzón de granularidad,

 puede ser demasiado restrictivo en ciertos escenarios.

Por este motivo, la UT 7 introduce a continuación:

 el bloqueo con intención,

 y los mecanismos de granularidad de bloqueos.

11. Bloqueo con intención y granularidad

11.1 Granularidad de los bloqueos

La granularidad de un bloqueo se refiere al tamaño del objeto sobre el cual se aplica el

bloqueo.
Un bloqueo puede aplicarse sobre:

 una base de datos completa,

 una tabla,
 una página,
 una fila,
 o incluso un atributo.

Una granularidad más gruesa:

 reduce la sobrecarga de gestión de bloqueos,

 pero disminuye la concurrencia.

Una granularidad más fina:

 incrementa la concurrencia,
 pero aumenta la complejidad y el costo de control.

El SGBD debe equilibrar estos dos aspectos.

11.2 Problema de la granularidad sin control

Si se utilizan bloqueos de granularidad fina sin un mecanismo adecuado:

 pueden producirse inconsistencias,

 pueden violarse las reglas de secuencialidad,
 el control de bloqueos se vuelve complejo.

Por este motivo, se introduce el concepto de bloqueo con intención.

11.3 Bloqueos con intención

Los bloqueos con intención indican que una transacción tiene la intención de bloquear
objetos de menor granularidad dentro de una estructura jerárquica.

Estos bloqueos permiten:

 coordinar accesos entre distintos niveles de la jerarquía,

 evitar conflictos entre bloqueos de distinta granularidad.

Los bloqueos con intención no otorgan acceso directo a los datos, sino que informan
sobre accesos futuros.
11.4 Tipos de bloqueos con intención

La cátedra distingue los siguientes tipos:

 IS (Intention Shared)
Indica intención de aplicar bloqueos compartidos en niveles inferiores.
 IX (Intention Exclusive)
Indica intención de aplicar bloqueos exclusivos en niveles inferiores.
 SIX (Shared with Intention Exclusive)
Combina un bloqueo compartido en el nivel actual con intención de bloqueos
exclusivos en niveles inferiores.

11.5 Jerarquía de bloqueo

Los datos se organizan en una estructura jerárquica, por ejemplo:

Base de datos → Tabla → Página → Fila

Antes de bloquear un objeto de nivel inferior:

 la transacción debe adquirir los bloqueos de intención correspondientes en los

niveles superiores.

Esto garantiza:

 coherencia entre bloqueos,

 correcta detección de conflictos,
 preservación de la secuencialidad.

11.6 Compatibilidad de bloqueos con intención

Los bloqueos con intención siguen reglas de compatibilidad que:

 determinan qué combinaciones pueden coexistir,

 evitan conflictos entre transacciones.

Estas reglas permiten:

 mayor concurrencia,
 sin perder control sobre la jerarquía de datos.

La cátedra se enfoca en el concepto de compatibilidad, no en la tabla completa de

combinaciones.
11.7 Importancia del bloqueo con intención

El uso de bloqueos con intención permite:

 combinar granularidades finas y gruesas,

 mejorar el rendimiento del sistema,
 mantener la corrección de las planificaciones.

Este mecanismo es esencial en SGBD reales que manejan grandes volúmenes de datos y
múltiples niveles de acceso.

12. Esquemas multiversión

12.1 Motivación de los esquemas multiversión

Los esquemas multiversión surgen como alternativa a los protocolos basados en bloqueo
para:

 reducir la espera entre transacciones,

 mejorar la concurrencia,
 evitar que las operaciones de lectura bloqueen a las de escritura.

La idea central es permitir que coexistan múltiples versiones de un mismo dato, de modo
que distintas transacciones puedan acceder a versiones diferentes sin interferirse.

12.2 Concepto de multiversión

En un esquema multiversión:

 cada operación de escritura genera una nueva versión del dato,

 las versiones anteriores no se sobrescriben inmediatamente,
 las transacciones leen la versión que corresponde a su contexto de ejecución.

De esta manera:

 las lecturas no bloquean a las escrituras,

 se reduce la probabilidad de conflictos,
 se mejora el rendimiento en sistemas con alta concurrencia.
12.3 Lecturas sin espera

Una característica fundamental de los esquemas multiversión es que:

 las operaciones de lectura no necesitan esperar,

 incluso si otro proceso está escribiendo el mismo dato.

Esto se debe a que:

 la lectura accede a una versión anterior consistente,

 mientras la escritura crea una nueva versión.

Este enfoque es especialmente eficiente en sistemas con muchas consultas de lectura.

12.4 Comparación con esquemas basados en bloqueo

En comparación con los esquemas de bloqueo:

 Los bloqueos:
o pueden generar esperas,
o pueden producir interbloqueos,
o limitan la concurrencia en escenarios intensivos.
 Los esquemas multiversión:
o reducen la espera,
o evitan bloqueos de lectura,
o incrementan la concurrencia.

Sin embargo, los esquemas multiversión:

 requieren mayor uso de almacenamiento,

 implican mayor complejidad en la gestión de versiones.

12.5 Relación con la consistencia

Aunque existan múltiples versiones de un dato:

 cada transacción debe ver un estado consistente de la base de datos,

 las versiones visibles deben respetar las reglas del esquema de control.

El SGBD debe garantizar que:

 no se violen las propiedades ACID,

 especialmente el aislamiento y la consistencia.
12.6 Importancia de los esquemas multiversión

Los esquemas multiversión permiten:

 mejorar la escalabilidad del sistema,

 soportar un mayor número de transacciones concurrentes,
 reducir la contención por recursos.

Por este motivo, son ampliamente utilizados en SGBD modernos.

12.7 Relación con los temas siguientes

A partir de los esquemas multiversión, la cátedra introduce:

 la ordenación por marcas temporales,

 y los protocolos multiversión específicos.

Estos mecanismos permiten definir qué versión de un dato debe ser leída o escrita por
cada transacción.

13. Ordenación por marcas temporales (Timestamp Ordering)

13.1 Concepto de marca temporal

La ordenación por marcas temporales es un esquema de control de concurrencia que

asigna a cada transacción una marca temporal (timestamp) única, generalmente basada
en el instante en que la transacción comienza su ejecución.

La marca temporal representa el orden lógico en el que las transacciones deberían

ejecutarse.

El objetivo del esquema es garantizar que las operaciones se ejecuten respetando ese
orden temporal, evitando conflictos sin necesidad de utilizar bloqueos tradicionales.
13.2 Principio de funcionamiento

En este esquema:

 a cada transacción se le asigna una marca temporal,

 a cada dato se le asocian marcas temporales que indican:
o la última transacción que lo leyó,
o la última transacción que lo escribió.

Antes de permitir una operación de lectura o escritura, el sistema verifica si dicha

operación respeta el orden impuesto por las marcas temporales.

Si el orden se viola, la transacción debe ser abortada y reiniciada.

13.3 Regla de lectura

Una transacción puede leer un dato si su marca temporal es mayor o igual a la marca
temporal de la última escritura de ese dato.

Si la marca temporal de la transacción es menor:

 la lectura violaría el orden temporal,

 la transacción debe abortarse y reiniciarse.

13.4 Regla de escritura

Una transacción puede escribir un dato solo si su marca temporal es:

 mayor o igual que la marca temporal de la última lectura,

 y mayor o igual que la marca temporal de la última escritura del dato.

Si estas condiciones no se cumplen:

 la escritura violaría el orden temporal,

 la transacción debe abortarse y reiniciarse.

13.5 Rollback por escritura tardía

El esquema de marcas temporales puede provocar abortos frecuentes, especialmente

cuando:

 una transacción antigua intenta escribir un dato ya accedido por transacciones más
nuevas.
Este fenómeno se conoce como rollback por escritura tardía.

Aunque puede afectar el rendimiento, garantiza:

 la secuencialidad,
 la corrección de las ejecuciones concurrentes.

13.6 Ventajas del esquema de marcas temporales

Entre las principales ventajas se destacan:

 no utiliza bloqueos,
 evita interbloqueos,
 garantiza secuencialidad en cuanto a conflictos.

Este esquema es especialmente útil en entornos donde:

 los conflictos son poco frecuentes,

 se prioriza la simplicidad del control.

13.7 Desventajas del esquema de marcas temporales

Entre sus limitaciones se encuentran:

 abortos y reinicios frecuentes,

 posible desperdicio de trabajo realizado,
 impacto negativo en el rendimiento en sistemas con alta contención.

Por este motivo, no siempre es el esquema más eficiente.

13.8 Relación con los esquemas multiversión

La ordenación por marcas temporales puede combinarse con esquemas multiversión,

dando lugar a:

 versiones múltiples de los datos,

 menor cantidad de abortos,
 lecturas sin espera.

Esta combinación permite mejorar el rendimiento manteniendo la corrección.

13.9 Importancia de la ordenación por marcas temporales

El estudio de este esquema permite:

 comprender alternativas al bloqueo,

 analizar distintos enfoques de control de concurrencia,
 comparar ventajas y desventajas entre esquemas.

A partir de aquí, la UT 7 avanza hacia:

 variantes multiversión,
 y los niveles de aislamiento definidos por SQL.

14. Niveles de aislamiento

14.1 Concepto de nivel de aislamiento

Un nivel de aislamiento define el grado en que una transacción está aislada de los
efectos de otras transacciones concurrentes.

Los niveles de aislamiento determinan:

 qué fenómenos de concurrencia pueden ocurrir,

 qué fenómenos deben evitarse,
 y qué compromisos se aceptan entre consistencia y rendimiento.

Estos niveles están definidos en el estándar SQL y son implementados por los SGBD.

14.2 Fenómenos de concurrencia considerados

Los niveles de aislamiento se definen en función de la posibilidad de que ocurran los

siguientes fenómenos:

 Lectura sucia
 Lectura no repetible
 Lectura fantasma

Cada nivel permite o impide determinados fenómenos.

14.3 Read Uncommitted

En el nivel Read Uncommitted:

 una transacción puede leer datos no confirmados por otras transacciones.

Fenómenos permitidos:

 lectura sucia
 lectura no repetible
 lectura fantasma

Es el nivel de aislamiento más bajo y ofrece:

 máximo rendimiento,
 mínima protección de la consistencia.

14.4 Read Committed

En el nivel Read Committed:

 una transacción solo puede leer datos confirmados.

Fenómenos permitidos:

 lectura no repetible
 lectura fantasma

Fenómenos evitados:

 lectura sucia

Este nivel ofrece un equilibrio entre:

 consistencia razonable,
 buen rendimiento.

14.5 Repeatable Read

En el nivel Repeatable Read:

 los datos leídos por una transacción no pueden cambiar durante su ejecución.
Fenómenos permitidos:

 lectura fantasma

Fenómenos evitados:

 lectura sucia
 lectura no repetible

Este nivel proporciona mayor aislamiento, pero:

 puede limitar la concurrencia.

14.6 Serializable

El nivel Serializable es el nivel de aislamiento más alto.

Garantiza que:

 la ejecución concurrente sea equivalente a alguna ejecución secuencial.

Fenómenos evitados:

 lectura sucia
 lectura no repetible
 lectura fantasma

Este nivel ofrece:

 máxima consistencia,
 menor grado de concurrencia.

14.7 Relación entre niveles de aislamiento y control de concurrencia

Cada nivel de aislamiento puede implementarse mediante:

 protocolos de bloqueo,
 esquemas multiversión,
 combinaciones de ambos.

Los SGBD seleccionan internamente los mecanismos necesarios para cumplir el nivel
solicitado.
14.8 Importancia de los niveles de aislamiento

El estudio de los niveles de aislamiento permite:

 comprender cómo se gestionan los compromisos entre consistencia y rendimiento,

 relacionar teoría de concurrencia con SQL,
 cerrar conceptualmente la UT 7.