Tabla de contenido

Transacciones................................................................................................................................................................................2
Propiedades ACID......................................................................................................................................................................2
Operaciones de una Transacción..............................................................................................................................................3
Estados de una Transacción......................................................................................................................................................4
Implementación de la Atomicidad............................................................................................................................................5
Comandos de Control de Transacciones...............................................................................................................................5
Implementación del Aislamiento..............................................................................................................................................6
Control de Concurrencia...........................................................................................................................................................8
Ejecuciones Concurrentes.....................................................................................................................................................8
Secuencialidad.......................................................................................................................................................................9
Secuencialidad en cuanto a Conflictos................................................................................................................................10
Secuencialidad en cuanto a Vistas......................................................................................................................................12
Recuperabilidad...................................................................................................................................................................13
Planificaciones Recuperables..............................................................................................................................................14
Planificaciones sin Cascada.................................................................................................................................................14
Técnicas de Control de Concurrencia..................................................................................................................................15
Implementación de la Persistencia.........................................................................................................................................19
Diseño y Creación de la Bitácora.........................................................................................................................................19
Recuperación a partir de la Bitácora...................................................................................................................................20
Contenido de la Bitácora.....................................................................................................................................................21
Responsabilidades del Gestor de Transacciones....................................................................................................................21
 Transacciones

Una transacción es una unidad de la ejecución de un programa. Puede consistir en varias operaciones de acceso a la base
de datos.

Propiedades ACID
Atomicidad [atomicity]: Las transacciones deben ser atómicas (o todos sus efectos o ninguno). Una transacción… o bien se
ejecuta completamente [commit], o bien deja todo como si nunca hubiese comenzado a ejecutarse [abort/rollback].

Consistencia [consistency preservation] Base de datos consistente antes y después de la transacción (puede que no durante
la transacción). La ejecución atómica de una transacción lleva a la base de datos de un estado consistente (en el que se
satisfacen todas las restricciones) a otro estado, también consistente. Es responsabilidad del programador que las
transacciones mantengan la consistencia del sistema.

Aislamiento [isolation] El resultado de la ejecución concurrente de transacciones es el mismo que si se ejecutasen

secuencialmente. Los efectos de una transacción no son visibles para las demás transacciones hasta que termina su
ejecución: La ejecución de una transacción no debe interferir en la ejecución de otras transacciones simultáneas.

Fallo de aislamiento: Dos transferencias simultáneas sobre la misma cuenta acceden en paralelo a su saldo, sin que el
sistema fuerce a que la primera transferencia termine antes de comenzar la segunda.

Persistencia/durabilidad [durability] Una vez completada su ejecución, los cambios realizados por una transacción son
permanentes: nadie puede cambiar la transacción y el sistema debe garantizar su durabilidad aunque se produzcan fallos.

Fallo de persistencia: En una transferencia bancaria, el usuario cree que la transacción ha terminado pero los datos están en
un buffer de disco gestionado por el sistema operativo y falla el suministro eléctrico antes de que los datos se almacenen
físicamente en el disco.

Una transacción es una unidad lógica de trabajo o procesamiento (ejecución de un programa que incluye operaciones de
acceso a la base de datos).

Una transacción es una secuencia de operaciones que llevan la base de datos desde un estado de consistencia a otro estado
de consistencia, por esto suele decirse también que la transacción es una unidad lógica de integridad.

Cuando múltiples transacciones son introducidas en el sistema por varios usuarios, es necesario evitar que interfieran entre
ellas de forma tal que provoquen que la BD quede en un estado no consistente; desde este punto de vista, podemos ver
una transacción como una unidad lógica de concurrencia.

Cuando ocurre un fallo que provoca la caída del sistema, en el momento en el que había varias transacciones en curso de
ejecución, muy probablemente dejará erróneos los datos en la BD (estado inconsistente); en estas circunstancias, se debe
garantizar que la BD pueda ser recuperada a un estado en el cual su contenido sea consistente, por esto una transacción es
considerada también una unidad lógica de recuperación.

La idea clave es que una transacción debe ser atómica, es decir, las operaciones que la componen deben ser ejecutadas en
su totalidad o no ser ejecutadas en absoluto.
Una sentencia de definición o manipulación de datos ejecutada de forma interactiva (por ejemplo utilizar el SQL*Plus de
Oracle para realizar una consulta) puede suponer el inicio de una transacción. Asimismo, la ejecución de una sentencia SQL
por parte de un programa que no tiene ya una transacción en progreso, supone la iniciación de una transacción.

Toda transacción finaliza con una operación de commit (confirmar) o bien con una operación de rollback (anular, abortar o
revertir). Tanto una operación como la otra puede ser de tipo explícito (si la propia transacción (su código) contiene una
sentencia COMMIT o ROLLBACK) o implícito (si dicha operación es realizada por el sistema de forma automática, por
ejemplo tras detectar una terminación normal (éxito) o anormal (fallo) de la transacción).

Por defecto, una vez finalizada una transacción, si todas sus operaciones se han realizado con éxito, se realiza un COMMIT
implícito de dicha transacción; y si alguna de ellas tuvo problemas, se lleva a cabo un ROLLBACK implícito de la transacción
(es decir, se deshacen todas las operaciones que había realizado hasta el momento del fallo).

El Subsistema de Recuperación del SGBD es el encargado de conseguir el cumplimiento de las propiedades de atomicidad y
durabilidad de las transacciones.

La conservación de la consistencia es una propiedad cuyo cumplimiento han de asegurar, por un lado los programadores de
base de datos, y por otro el Subsistema de Integridad del SGBD.

El Subsistema de Control de Concurrencia es el encargado de conseguir el aislamiento de las transacciones.

Operaciones de una Transacción

Para hacer posible el control de la concurrencia de las transacciones, así como la recuperación del sistema tras fallos o
caídas del mismo, es necesario almacenar cuándo se inicia, termina, se confirma o se aborta cada transacción, y además
qué modificaciones de qué elementos de BD realiza cada una.

• INICIO DE TRANSACCIÓN Operación que marca el momento en el que una transacción comienza a ejecutarse.

• LEER o ESCRIBIR Operaciones de lectura/escritura de elementos de la base de datos, que se realizan como parte de una
transacción.

• FIN DE TRANSACCIÓN Las operaciones de LEER y ESCRIBIR han terminado. En este punto se verifica si la transacción debe
abortarse por alguna razón (si viola el control de concurrencia, por ejemplo), o bien si los cambios realizados por la
transacción (hasta ahora en buffers de memoria volátil) pueden aplicarse permanentemente a la base de datos en disco (es
decir, si puede realizarse una operación de CONFIRMAR (COMMIT)).

• CONFIRMAR La transacción terminó con éxito, todos los cambios que ha realizado se pueden confirmar sin peligro en la
BD y ya no serán cancelados.

• ABORTAR La transacción terminó sin éxito y toda actualización que ha realizado se debe cancelar.

Algunas técnicas de recuperación necesitan operaciones adicionales como las siguientes:

• DESHACER Similar a ABORTAR, pero se aplica a una sola operación y no a una transacción completa.

• REHACER Especifica que algunas de las operaciones realizadas por una transacción deben repetirse, para asegurar que
todas las operaciones realizadas por una transacción que ha sido CONFIRMADA se hayan aplicado con éxito a la BD (es
decir, los cambios hayan quedado grabados físicamente en disco).
Estados de una Transacción
El siguiente es el diagrama de transición de estados para la ejecución de transacciones:

Una transacción entra en el estado ACTIVA justo después de iniciar su ejecución y, en este estado, puede realizar
operaciones LEER y ESCRIBIR.

Cuando la transacción finaliza, pasa al estado PARCIALMENTE CONFIRMADA. En este punto, el Subsistema de Control de
Concurrencia puede efectuar verificaciones para asegurar que la transacción no interfiera con otras transacciones en
ejecución. Además, el Subsistema de Recuperación puede anotar qué operaciones (qué cambios) ha realizado que la
transacción en un fichero del sistema (bitácora), con el objetivo de garantizar que los cambios realizados por la transacción
terminada queden permanentes, a pesar de fallos del sistema.

Una vez realizadas con éxito ambas verificaciones, la transacción ha llegado a su punto de confirmación4 y pasa al estado
CONFIRMADA (ha concluido su ejecución con éxito).

Si una de las verificaciones falla o la transacción se aborta mientras está en estado ACTIVA, pasa al estado FALLIDA. En este
caso, es posible que la transacción deba ser cancelada (anulada, revertida, abortada) para anular los efectos de sus
operaciones ESCRIBIR sobre la BD.

El estado TERMINADA indica que la transacción ha abandonado el sistema.

Las transacciones fallidas (abortadas) pueden ser reiniciadas posteriormente, ya sea de forma automática por parte del
sistema, o bien sea el usuario el que las reintroduzca como si fueran nuevas transacciones.

Implementación de la Atomicidad

Comandos de Control de Transacciones

Los comandos de control de transacciones manejan de forma explícita los cambios realizados por comandos DML (Data
Manipulation Language) son los siguientes:

Comando Propósito
COMMIT Hacer permanentes los cambios realizados por las
sentencias ejecutadas en la transacción actual, y
 establecer el comienzo de una nueva transacción.
ROLLBACK Deshacer todos los cambios realizados desde el
comienzo de la transacción actual o desde un
savepoint.
SAVEPOINT Establecer un punto hasta el cual se podrá
deshacer cambios.
SET TRANSACTION Establecer propiedades para la transacción actual.

La sentencia SAVEPOINT Identifica un punto en una transacción hasta el cual se podrá hacer rollback posteriormente.

Sintaxis:

SAVEPOINT savepoint

Donde savepoint es el nombre del savepoint que se está creando.

Notas de Uso: Los savepoints se utilizan con el comando ROLLBACK para deshacer porciones de la transacción actual.

Los savepoints son útiles en programas interactivos, porque se puede crear y nombrar pasos intermedios de un programa.
Esto permite mayor control sobre programas largos y complejos. Por ejemplo, es posible usar savepoints a lo largo de una
serie de actualizaciones (updates) largas y complejas, para que si se comete un error, no se tenga que rehacer cada una de
las sentencias. Los savepoints son útiles en programas de aplicación de manera similar.

Si un programa contiene varios subprogramas, se puede crear un savepoint antes del comienzo de cada subprograma. Si
falla algún subprograma, es fácil volver al estado anterior de los datos antes de que empezara el subprograma (haciendo
rollback hasta el savepoint adecuado), y entonces re-ejecutar el mismo una vez revisados los parámetros o realizada alguna
acción de recuperación.

El nombre de un savepoint debe ser único dentro de una transacción dada. Si se crea un segundo savepoint con el mismo
identificador que un savepoint anterior, éste último es eliminado. Después de crear un savepoint, se puede continuar el
procesamiento, confirmar (commit) el trabajo, anular (rollback) la transacción completa, o bien hacer rollback hasta el
savepoint. Ejemplo Tras actualizar el salario de los empleados BLAKE y CLARK, comprobamos que el salario total de la
compañía excede de 20000, lo cual no es posible, así que reintroducimos el salario de CLARK:

UPDATE emp SET sal = 2000 WHERE ename = 'BLAKE' ;

SAVEPOINT blake_sal ;
UPDATE emp SET sal = 1500 WHERE ename = 'CLARK' ;
SAVEPOINT clark_sal ;
SELECT SUM(sal) FROM emp ; -
ROLLBACK TO SAVEPOINT blake_sal ;
UPDATE emp SET sal = 1300 WHERE ename = 'CLARK' ; COMMIT ;

Nota: Estos son órdenes desde el editor de SQL.

Implementación del Aislamiento

Se puede ajustar el nivel de aislamiento entre las transacciones y determinar para una transacción el grado de aceptación
de datos inconsistentes. A mayor grado de aislamiento, mayor precisión, pero a costa de menor concurrencia.

El nivel de aislamiento para una sesión SQL establece el comportamiento de los bloqueos para las instrucciones SQL.

Niveles de aislamiento

SQL92 define 4 niveles de aislamiento:

o Lectura no comprometida. Menor nivel. Asegura que no se lean datos corruptos físicamente.
o Lectura comprometida. Sólo se permiten lecturas de datos comprometidos.
o Lectura repetible. Las lecturas repetidas de la misma fila para la misma transacción dan los mismos resultados.
o Secuenciable. Mayor nivel de aislamiento. Las transacciones se aíslan completamente.

Comportamiento concurrente de las transacciones

Entre los problemas que pueden ocurrir debido al acceso concurrente se encuentran:

 Problema de la actualización perdida

• T1 lee las existencias disponibles de un producto (E)
• T2 también lee las existencias disponibles (E)
• T1 incrementa dichas existencias en 100 unidades (E+100)
• T2 también incrementa dichas existencias en 100 unidades (E+100)
• El resultado final (E+100) sería incorrecto (debería ser E+200), ya que se ha perdido la actualización de T1
Ambas transacciones leen el valor antes de que lo cambie la otra…

 Problema de la lectura sucia

• T1 lee las existencias disponibles de un producto (E)

• T1 incrementa dichas existencias en 100 unidades (E+100)
• T2 lee las existencias disponibles de dicho producto (E+100)
• T1 aborta, debido a un error, deshaciéndose sus cambios (las existencias pasan de nuevo a valer E)
• T2 incrementa las existencias en 100 unidades (E+200)
• El resultado final (E+200) sería incorrecto (debería ser E+100) ya que T1 ha abortado su actualización

Una transacción actualiza un ítem que luego lee otra. Después falla (por tanto, la segunda lee un dato que “nunca
existió”).

 Problema del resumen incorrecto

• T1: cálculo del saldo total de todas las cuentas de un banco

• T2: transferencia de una cuenta bancaria a otra (c1 à c2)

• T2 sustrae X del saldo de c1

• T1 lee el saldo de c1

• T1 lee el saldo de c2

• T2 añade X al saldo de c2

• El saldo total calculado por T1 será menor que el real por X

 Una transacción calcula un agregado de registros mientras otra actualiza algunos de esos registros  algunos
valores se consideran antes de la actualización y otros después

 Problema de la lectura no repetible

• T1 consulta asientos disponibles en varios vuelos:

- Hay N asientos disponibles en IB245 y N’ en FJ143
• T2 reserva X asientos en el vuelo IB245
• T1 decide finalmente reservar en el vuelo IB245
- Al volver a leer los asientos disponibles en dicho vuelo, se obtiene N-X (no coincide con los de
antes)
- Incluso podría no haber ya asientos disponibles…

Una transacción lee dos valores diferentes para un ítem, debido a una modificación intermedia por parte de otra

 Problema de la lectura fantasma (tuplas que no existían antes)

Todos estos problemas se pueden resumir en tres, con fines de explicar los niveles de aislamiento:

o Lectura sucia. Lectura de datos no comprometidos. (Retrocesos)

o Lectura no repetible. Se obtienen resultados inconsistentes en lecturas repetidas.
o Lectura fantasma. Una lectura de una fila que no existía cuando se inició la transacción.

SET TRANSACTION ISOLATION LEVEL…

Phantoms: Tuplas recién insertadas (por otras transacciones).

Server permite todos estos niveles, Oracle sólo permite el secuenciable y la lectura comprometida, que evita el problema
de la lectura sucia y de la actualización perdida. Los niveles se pueden establecer en ambos SGBD para cada transacción.
Oracle además ofrece un modo de sólo lectura (no parte del estándar) SET TRANSACTION READ ONLY.

Control de Concurrencia
Ejecuciones Concurrentes
Los sistemas de procesamiento de transacciones permiten normalmente la ejecución de varias transacciones
concurrentemente. Permitir que varias transacciones actualicen concurrentemente los datos provoca complicaciones en la
consistencia de los mismos. Asegurar la consistencia a pesar de la ejecución concurrente de las transacciones requiere un
trabajo extra; es mucho más sencillo exigir que las transacciones se ejecuten secuencialmente, es decir, una a una,
comenzando cada una sólo después de que la anterior se haya completado. Sin embargo, existen dos buenas razones para
permitir la concurrencia.

• Productividad y utilización de recursos mejoradas. Se puede entonces explotar el paralelismo de la UCP y del sistema de
E/S para ejecutar varias transacciones en paralelo.

• Tiempo de espera reducido. Debe haber una mezcla de transacciones que se ejecutan en el sistema, algunas cortas y otras
largas. La ejecución concurrente reduce los retardos impredecibles en la ejecución de las transacciones. Además se reduce
también el tiempo medio de respuesta

Sean T1 y T2 dos transacciones para transferir fondos de una cuenta a otra. La transacción T1 transfiere 50 € de la cuenta A
a la cuenta B y se define como sigue

T1:
leer(A);
A := A – 50;
escribir(A);
leer(B);
B := B + 50;
escribir(B).

La transacción T2 transfiere el 10 por ciento del saldo de la cuenta A a la cuenta B, y se define

T2:
leer(A);
temp := A * 0.1;
A := A – temp;
escribir(A);
leer(B);
B := B + temp;
escribir(B).

Supóngase que los valores actuales de las cuentas A y B son 1.000 € y 2.000 € respectivamente. Supóngase que las dos
transacciones se ejecutan de una en una en el orden T1 seguida de T2. Esta secuencia de ejecución se representa en la
figura izquierda de abajo. La secuencia de pasos o instrucciones aparece en orden cronológico de arriba abajo, con las
instrucciones de T1 en la columna izquierda y las de T2 en la derecha.

Los valores finales de las cuentas A y B, después de que tenga lugar la ejecución de la figura izquierda, son de 855 € y de
2.145 € respectivamente. De este modo, la suma total de saldo de las cuentas A y B —es decir, la suma A + B— se conserva
tras la ejecución de ambas transacciones.

Análogamente, si las transacciones se ejecutan de una en una en el orden T2 seguida de T1, entonces la secuencia de
ejecución es la de la figura derecha. De nuevo, como se esperaba, se conserva la suma A + B y los valores finales de las
cuentas A y B son de 850 € y de 2.150 € respectivamente.

PLANIFICACION 1 PLANIFICACION 2
Las secuencias de ejecución que se acaban de describir se denominan planificaciones. Representan el orden cronológico en
el que se ejecutan las instrucciones en el sistema. Obviamente una planificación para un conjunto de transacciones debe
consistir en todas las instrucciones de dichas transacciones, y debe conservar el orden en que aparecen las instrucciones en
cada transacción individual.

Estas planificaciones son secuenciales. Cada planificación secuencial consiste en una secuencia de instrucciones de varias
transacciones, en la cual las instrucciones pertenecientes a una única transacción están juntas en dicha planificación. De
este modo, para un conjunto de n transacciones existen n! planificaciones secuenciales válidas distintas.

Cuando el sistema de bases de datos ejecuta concurrentemente varias transacciones, la planificación correspondiente no
tiene por qué ser secuencial. Si dos transacciones se ejecutan concurrentemente, el sistema operativo puede ejecutarlas
intercalando sus instrucciones, compartiendo de esta forma el tiempo de la UCP.

En general no es posible predecir exactamente cuántas instrucciones se ejecutarán antes de que la UCP cambie a otra
transacción. Así, el número de planificaciones posibles para un conjunto de n transacciones es mucho mayor que n!.

Secuencialidad
El sistema de base de datos debe controlar la ejecución concurrente de las transacciones para asegurar que el estado de la
base sigue siendo consistente. Antes de examinar cómo debe realizar esta tarea, el sistema de base de datos hay que
entender primero las planificaciones que aseguran la consistencia y las que no.

Una transacción puede realizar una secuencia arbitraria de operaciones con la copia Q que reside en la memoria intermedia
local de dicha transacción. De este modo las únicas operaciones significativas de la transacción son, desde el punto de vista
de la planificación, las instrucciones leer y escribir.

Secuencialidad en cuanto a Conflictos

Considérese una planificación P en la cual hay dos instrucciones consecutivas Ii e Ij, pertenecientes a las transacciones Ti y Tj
respectivamente (i ≠ j). Si Ii e Ij se refieren a distintos elementos de datos se pueden intercambiar Ii e Ij sin afectar al
resultado de cualquier instrucción de la planificación. Sin embargo, si Ii e Ij se refieren al mismo elemento Q entonces el
orden de los dos pasos puede ser importante. Puesto que sólo se tienen en cuenta las instrucciones leer y escribir, se deben
considerar cuatro casos:
 1. Ii = leer(Q), Ij = leer(Q). El orden de Ii e Ij no importa, puesto que Ti y Tj leen el mismo valor de Q, independientemente
del orden.

2. Ii = leer(Q), Ij = escribir(Q). Si Ii está antes que Ij, entonces Ti no lee el valor de Q que escribe la instrucción Ij de Tj. Si Ij
está antes que Ii, entonces Ti lee el valor de Q escrito por Tj. Por tanto, el orden de Ii e Ij es importante.

3. Ii = escribir(Q), Ij = leer(Q). El orden de Ii e Ij es importante por razones similares a las del caso anterior.

4. Ii = escribir(Q), Ij = escribir(Q). Puesto que ambas instrucciones son operaciones escribir, el orden de dichas instrucciones
no afecta ni a Ti ni a Tj.

Sin embargo, el valor que obtendrá la siguiente instrucción leer(Q) de P sí se ve afectado, ya que únicamente se conserva
en la base de datos la última de las dos instrucciones escribir. Si no hay ninguna otra instrucción escribir(Q) después de Ii e Ij
en P, entonces el orden de Ii e Ij afecta directamente al valor final de Q en el estado de la base de datos que se obtiene con
la planificación P. De esta manera sólo en el caso en el cual Ii e Ij son instrucciones leer no tiene importancia el orden de
ejecución de las mismas.

Se dice que Ii e Ij están en conflicto si existen operaciones de diferentes transacciones sobre el mismo elemento de datos, y
al menos una de esas instrucciones es una operación escribir.

En la figura, la instrucción escribir(A) de T1 está en conflicto con la instrucción leer(A) de T2. Sin embargo, la instrucción
escribir(A) de T2 no está en conflicto con la instrucción leer(B) de T1, ya que las dos instrucciones acceden a diferentes
elementos de datos.

Sean Ii e Ij instrucciones consecutivas de una planificación P. Si Ii e Ij son instrucciones de transacciones diferentes y además
Ii e Ij no están en conflicto, entonces se puede cambiar el orden de Ii e Ij para obtener una nueva planificación P′. Lo
esperado es que P sea equivalente a P′, ya que todas las instrucciones aparecen en el mismo orden en ambas
planificaciones salvo Ii e Ij, cuyo orden no es importante.

PLANIFICACION 3 PLANIFICACION 4
En la figura anterior, puesto que la instrucción escribir(A) de T2 en la planificación 3 no está en conflicto con la instrucción
leer(B) de T1, se pueden intercambiar dichas instrucciones para generar una planificación equivalente, la planificación 4.
Independientemente de cuál sea el estado inicial del sistema, las planificaciones 3 y 4 producen el mismo estado final del
sistema.

Se puede continuar intercambiando instrucciones no conflictivas como sigue:

• Intercambiar la instrucción leer(B) de T1 con la instrucción leer(A) de T2.
• Intercambiar la instrucción escribir(B) de T1 con la instrucción escribir(A) de T2.
• Intercambiar la instrucción escribir(B) de T1 con la instrucción leer(A) de T2.

El resultado final de estos intercambios, es una planificación secuencial que es equivalente a la planificación 3 (Ver la figura
a continuación).
PLANIFICACION 5

Así se muestra que la planificación 3 es equivalente a una planificación secuencial. Esta equivalencia implica que
independientemente del estado inicial, la planificación 3 produce el mismo estado final que una planificación secuencial.

Si una planificación P se puede transformar en otra P′ por medio de una serie de intercambios de instrucciones no
conflictivas, se dice que P y P′ son equivalentes en cuanto a conflictos.

Volviendo a los ejemplos anteriores, se observa que la planificación 1 no es equivalente en cuanto a conflictos a la
planificación 2. Sin embargo, la planificación 1 es equivalente en cuanto a conflictos a la planificación 3, puesto que las
instrucciones leer(B) y escribir(B) de T1 se pueden intercambiar con las instrucciones leer(A) y escribir(A) de T2.

Se dice que una planificación P es secuenciable en cuanto a conflictos si es equivalente en cuanto a conflictos a una
planificación secuencial.

Así, la planificación 3 es secuenciable en cuanto a conflictos, ya que es equivalente en cuanto a conflictos a la planificación
secuencial 1.
Es posible encontrar dos planificaciones que produzcan el mismo resultado y que no sean equivalentes en cuanto a
conflictos. Por ejemplo, considérese la transacción T5, la cual transfiere 10 € de la cuenta B a la A. Sea la planificación 6 la
que se define en la figura.

PLANIFICACION 6

Se puede afirmar que la planificación 6 no es equivalente en cuanto a conflictos a la planificación secuencial <T1,T5>, ya que
en la planificación 6 la instrucción escribir(B) de T5 está en conflicto con la instrucción leer(B) de T1. Por este motivo no se
pueden colocar todas las instrucciones de T1 antes de las de T5 intercambiando instrucciones no conflictivas consecutivas.
Sin embargo, los valores finales de las cuentas A y B son los mismos después de ejecutar tanto la planificación 6 como la
planificación secuencial <T1, T5> —esto es, 960 € y 2.040 € respectivamente.

Con este ejemplo se puede observar que existen definiciones de equivalencia de planificaciones que son menos rigurosas
que la de equivalencia en cuanto a conflictos. En general es difícil de implementar este análisis y es costoso en términos de
cómputo. Sin embargo, existen otras definiciones de equivalencia de planificación que se basan únicamente en las
operaciones leer y escribir.

Secuencialidad en cuanto a Vistas

En este apartado se va a considerar una forma de equivalencia que es menos rigurosa que la equivalencia en cuanto a
conflictos, pero que, al igual que ésta, se basa únicamente en las operaciones leer y escribir de las transacciones.

Considérense dos planificaciones, P y P′, en las cuales participa el mismo conjunto de transacciones. Se dice que las
planificaciones P y P′ son equivalentes en cuanto a vistas si se cumplen las tres condiciones siguientes:

1. Para todo elemento de datos Q, si la transacción Ti lee el valor inicial de Q en la planificación P, entonces Ti debe leer
también el valor inicial de Q en la planificación P′.

2. Para todo elemento de datos Q, si la transacción Ti ejecuta leer(Q) en la planificación P y el valor lo ha producido la
transacción Tj (si existe dicha transacción) entonces, en la planificación P′, la transacción Ti debe leer también el valor de Q
que haya producido la transacción Tj.

3. Para todo elemento de datos Q, la transacción (si existe) que realice la última operación escribir(Q) en la planificación P,
debe realizar la última operación escribir(Q) en la planificación P′.
Las condiciones 1 y 2 aseguran que cada transacción lee los mismos valores en ambas planificaciones y por tanto realizan
los mismos cálculos. La condición 3, junto con las condiciones 1 y 2, asegura que ambas planificaciones dan como resultado
el mismo estado final del sistema.

Volviendo a los ejemplos anteriores, nótese que la planificación 1 no es equivalente en cuanto a vistas a la planificación 2,
ya que en la planificación 1 el valor de la cuenta A que lee la transacción T2 lo produce T1, mientras que esto no ocurre en
la planificación 2. Sin embargo, la planificación 1 es equivalente en cuanto a vistas a la planificación 3, ya que los valores de
las cuentas A y B que lee la transacción T2 los produce T1 en ambas planificaciones.

Se dice que la planificación P es secuenciable en cuanto a vistas si es equivalente en cuanto a vistas a una planificación
secuencial.

Como ejemplo tenemos la planificación 7, como se muestra en la figura de abajo. Esta planificación es secuenciable en
cuanto a vistas a la planificación secuencial <T3,T4,T6>, ya que la instrucción leer(Q), lee el valor inicial de Q en ambas
planificaciones, y T6 realiza la escritura final de Q en ambas planificaciones.

PLANIFICACION 7

Toda planificación secuenciable en cuanto a conflictos es secuenciable en cuanto a vistas, pero existen planificaciones
secuenciables en cuanto a vistas que no son secuenciables en cuanto a conflictos.

La planificación 7 no es secuenciable en cuanto a conflictos, puesto que para todo par de instrucciones éstas están en
conflicto y, por tanto, no es posible ningún intercambio de instrucciones.

Obsérvese que en la planificación 7, las transacciones T4 y T6 realizan operaciones escribir(Q) sin haber realizado ninguna
operación leer(Q). Este tipo de escrituras se denominan escrituras a ciegas. Las escrituras a ciegas aparecen en toda
planificación secuenciable en cuanto a vistas que no sea secuenciable en cuanto a conflictos.

Recuperabilidad
Antes se han estudiado las planificaciones que son aceptables desde el punto de vista de la consistencia de la base de datos,
asumiendo implícitamente que no había fallos en las transacciones. Ahora se va a estudiar el efecto de los fallos en una
transacción durante una ejecución concurrente.

Si la transacción Ti falla, por la razón que sea, es necesario deshacer el efecto de dicha transacción para asegurar la
propiedad de atomicidad de la misma. En un sistema que permita la concurrencia es necesario asegurar también que toda
transacción Tj que dependa de Ti (es decir, Tj lee datos que ha escrito Ti) se aborta también.

Para alcanzar esta garantía, es necesario poner restricciones al tipo de planificaciones permitidas en el sistema. Las
siguientes son planificaciones aceptables desde el punto de vista de la recuperabilidad.
Planificaciones Recuperables
PLANIFICACION 8

Considérese la planificación 8 que está en la figura , en la cual la transacción T9 realiza sólo una instrucción: leer(A).
Supóngase que el sistema permite que T9 se complete inmediatamente después de ejecutar la instrucción leer(A). Así se
completa T9 antes de que lo haga T8. Supóngase ahora que T8 falla antes de completarse. Puesto que T9 ha leído el valor
del elemento de datos A escrito por T8, se debe abortar T9 para asegurar la atomicidad de la transacción. Sin embargo, T9
ya se ha comprometido y no puede abortarse. De este modo se llega a una situación en la cual es imposible recuperarse
correctamente del fallo de T8.

La planificación 8, cuyo compromiso tiene lugar inmediatamente después de ejecutar la instrucción leer(A), es un ejemplo
de planificación no recuperable, la cual no debe permitirse. La mayoría de los sistemas de bases de datos requieren que
todas las planificaciones sean recuperables.

Una planificación recuperable es aquella en la que para todo par de transacciones Ti y Tj, tales que Tj lee elementos de
datos que ha escrito previamente Ti, la operación comprometer de Ti aparece antes que la de Tj.

Planificaciones sin Cascada

Incluso si una planificación es recuperable, hay que retroceder varias transacciones para recuperar correctamente el estado
previo a un fallo en una transacción Ti. Tales situaciones ocurren si las transacciones leen datos que ha escrito Ti. Como
ejemplo considérese la siguiente planificación parcial.

PLANIFICACION 9

La transacción T10 escribe un valor de A que lee la transacción T11. La transacción T11 escribe un valor de A que lee la
transacción T12. Supóngase que en ese momento falla T10. Se debe retroceder T10. Puesto que T11 depende de T10, se
debe retroceder T11. Puesto que T12 depende de T11, se debe retroceder T12. Este fenómeno en el cual un fallo en una
única transacción provoca una serie de retrocesos de la transacción se denomina retroceso en cascada.

No es deseable el retroceso en cascada, ya que provoca un aumento significativo del trabajo necesario para deshacer
cálculos. Es deseable restringir las planificaciones a aquellas en las que no puedan ocurrir retrocesos en cascada. Tales
planificaciones se denominan planificaciones sin cascada.
Una planificación sin cascada es aquella para la que todo par de transacciones Ti y Tj tales que Tj lee un elemento de datos
que ha escrito previamente Ti, la operación comprometer de Ti aparece antes que la operación de lectura de Tj. Es sencillo
comprobar que toda planificación sin cascada es también recuperable.

Técnicas de Control de Concurrencia

El objetivo de las técnicas de control de concurrencia es evitar interferencias entre transacciones, o sea el aislamiento.

Una solución trivial es que cada transacción se ejecute en exclusión mutua, esto es muy restrictivo. No permite la
concurrencia y las BD están pensadas para acceso multi-usuario (múltiples aplicaciones). En lugar de eso, se intercalan las
acciones pero propendiendo para que el resultado sea como en exclusión mutua… aquí es donde el concepto de
secuencialidad juega un papel fundamental.

La Secuencialidad es utilizada como criterio de corrección. La idea es imponer restricciones a la libre intercalación de
operaciones de transacciones para garantizar que el plan resultante es secuenciable.

Técnicas pesimistas

Impiden ciertas operaciones si son sospechosas de producir planes no secuenciables, para esto utilizan protocolos para
garantizar la secuencialidad de los planes de ejecución (schedules).El control de las transacciones se realiza durante la
ejecución (no sólo al final).

 Técnicas de bloqueo (locks)

 Técnicas de marcas de tiempo (time-stamping)

Técnicas de bloqueo (locks)

 GRANULARIDAD DEL LOCK 

La granularidad es el tamaño de los elementos. Así, se habla de sistemas de grano fino o de grano grueso, para
denotar elementos pequeños o grandes, respectivamente, por ejemplo una tabla o una fila o una base de datos.

Una transacción puede generar un bloqueo de diferente tipo para minimizar el costo que representa sobre el
recurso. Generar el bloqueo a una granularidad menor incrementa la concurrencia, sin embargo como es de
esperarse, hacerlo significa una mayor carga por la cantidad de Locks necesarios. Al contrario es similar, un Lock
más grande tiene menor carga operativa pero disminuye la concurrencia.

 Un bloqueo es una información del tipo de acceso que se permite a un elemento. El SGBD impone los bloqueos
necesarios en cada momento. El gestor de acceso a los datos implementa las restricciones de acceso. El gestor de
bloqueos almacena los bloqueos en una tabla de bloqueos: (, , )=(E,B,T). La transacción T tiene un tipo de bloqueo
B sobre el elemento E. Varias transacciones pueden bloquear el mismo elemento de forma diferente.

 El modo de bloqueo especifica el modo en que se bloquea un elemento.

 Cerrojo (lock ó bloqueo): Variable asociada a un ítem de datos, que describe su estado con respecto a las
operaciones permitidas. Riesgos: bloqueo mortal (deadlock), inanición (starvation, que nunca sea atendida).
  Cerrojos binarios: 0 ó 1 (accesible o no accesible). Operaciones lock() y unlock()  indivisibles (exclusión
mutua, región crítica, cola de espera). Simples pero restrictivos, no usados.

 Cerrojos multi-modo: Shared locks (S locks, read locks), Exclusive locks (X locks, write locks). Operaciones
read_lock(), write_lock(), unlock()  indivisibles. Permiten accesos simultáneos en modo lectura.

 Estos son los modos de bloqueo en Sql Server:

 Compartido: para operaciones sólo de lectura. Se permiten lecturas concurrentes, pero ninguna actualización.
 Actualización: para operaciones que pueden escribir. Sólo se permite que una transacción adquiera este
bloqueo. Si la transacción modifica datos, se convierte en exclusivo, en caso contrario en compartido.
 Exclusivo. para operaciones que escriben datos. Sólo se permite que una transacción adquiera este bloqueo.
 Intención: se usan para establecer una jerarquía de bloqueo. Por ejemplo, si una transacción necesita bloqueo
exclusivo y varias transacciones tienen bloqueo de intención, no se concede el exclusivo.
o Intención compartido. Bloqueo compartido.
o Intención exclusivo. Bloqueo exclusivo.
o Compartido con intención exclusivo. Algunos bloqueos compartidos y otros exclusivos.
 Esquema. para operaciones del DDL.
 Actualización masiva. En operaciones de actualización masiva.

La idea es bloquear ítems de datos para evitar su acceso concurrente desde múltiples transacciones sincronizando el
acceso. Utilizadas en la mayoría de los SGBD comerciales.

Los cerrojos no garantizan la secuencialidad por sí solos, hace falta un protocolo adicional referente al posicionamiento de
las operaciones de bloqueo y desbloqueo dentro de una transacción.

 Protocolo de bloqueo en 2 fases. Es el más utilizado. La idea es no hacer ningún lock() después de algún unlock().
Consiste en 2 fases:
o Una fase de crecimiento/expansión: solicitud de locks
o Una fase de devolución: realización de unlocks.

Garantiza la secuencialidad, pero puede limitar la concurrencia (restrictivo), incluso puede impidir algunos planes
serializables.

 La variante más popular es 2PL estricto, en la que no se libera ningún cerrojo exclusivo (de escritura) hasta que se
finaliza. Ninguna transacción podrá leer o escribir ese ítem, esto evita el rollback en cascada y permite una fácil
recuperación (restaurar valores viejos antes del write).

Bloqueos Mortales

Dos o más transacciones se quedan a la espera de que se liberen elementos que tiene bloqueados otra. Puede producirse
incluso con protocolos de bloqueo que garantizan la seriabilidad

 Prevención

 Obligando a que las transacciones bloqueen todos los elementos que necesitan por adelantado, o todos o
ninguno (2PL conservador).
  Ordenación de transacciones por marcas de tiempo

- Wait-die  si TS(Ti) < TS(Tj), entonces Ti puede esperar; de otro modo, Ti muere. Transacciones
+ viejas esperan por otras + jóvenes.

- Wound-wait  si TS(Ti) > TS(Tj), entonces Ti hiere a Tj (que aborta); de otro modo, Ti puede
esperar. Transacciones + jóvenes esperan por otras + viejas.

- Las transacciones se reinician con la misma marca de tiempo

 Otras: abortar si no es posible obtener un cerrojo, protocolo del árbol, etc.

 Detección y recuperación
 Detección del interbloqueo controlando de forma periódica si se ha producido, para lo que suele construir
un grafo de espera:
- Cada nodo representa una transacción
- Existe un arco entre Ti y Tj si Ti está esperando un recurso que tiene bloqueado Tj
- Existe interbloqueo si el Grafo tiene un ciclo. si hay un ciclo abortar a una de las transacciones.
Cada SGBD tiene su propia política para escoger las víctimas, aunque suelen ser las transacciones
mas recientes. Problema de livelock (Se puede producir inanición si se elige siempre a la misma
víctima).

- Selección de la víctima

o La transacción que lleva menos tiempo ejecutándose

o La transacción que está bloqueando un mayor número de transacciones
o La transacción que menos veces se ha abortado

 Uso de timeouts

Técnicas de Marcas de tiempo

Con las marcas de tiempo el interbloqueo es imposible. Consiste en un identificador único para cada transacción, generado
automáticamente por el sistema, este es la marca de tiempo para la transacción.

A cada elemento X de la BD se le asigna también las marcas de tiempo correspondientes a las transacciones más nuevas
(mayor marca de tiempo) que lo han leído y escrito: TS_lect(X) y TS_escr(X).

Se usa el orden de las marcas de tiempo para garantizar la secuencialidad de la siguiente manera:

 Si una transacción T quiere escribir en X

- Si TS_lect(X) > TS(T) entonces abortar. Una transacción más nueva ya ha leído X antes de que T tuviera la
oportunidad de modificarlo
- Si TS_escr(X) > TS(T) entonces no escribir y seguir (regla de escritura de Thomas). Una transacción más
nueva ya ha escrito el valor de X, por lo que se puede ignorar la escritura por parte de T.

Problema potencial: la transacción más nueva puede abortar  debe seguir la pista a las escrituras
tentativas y a sus valores previos.

- En otro caso escribir y TS_escr(X):=TS(T).

 Si una transacción T quiere leer de X

 - Si TS_escr(X) > TS(T) entonces abortar. Una transacción más nueva escribió X antes de que T tuviera la
oportunidad de leer su valor

- Si TS_escr(X) <= TS(T) entonces leer de X y TS_lect(X):=máximo(TS(T), TS_lect(X))

Técnicas optimistas

También llamadas técnicas de validación o técnicas de certificación. No imponen restricciones, no requieren bloqueo, no
realizan ninguna verificación durante la ejecución, se comprueban posibles interferencias al final. Los cambios se realizan
sobre copias locales (no sobre los elementos de la BD). Tienen tres fases:

 Fase de lectura  lee los valores de los elementos en la BD pero no modifica ninguno (copias locales).

 Fase de validación (¿ha habido algún conflicto? ¿alguna actualización violaría la secuencialidad?)

 Fase de escritura (si se valida satisfactoriamente se actualiza la BD; de otro modo, abortar, dado que
puede haber habido interferencias).

Adecuadas cuando hay pocas interferencias entre transacciones (optimismo); si no, se asume el coste de reiniciar.

Técnicas de control Multiversión

Varias transacciones leen y escriben diferentes versiones del mismo dato siempre que cada transacción sea un conjunto
consistente de versiones de todos los datos a los que accede.

 Marca de tiempo para escrituras:

- Se genera una nueva versión cada vez que se escribe un objeto
- Su marca de tiempo de escritura es la marca de tiempo de la transacción correspondiente.
- Cada transacción T lee la versión de un ítem que es apropiada para ella, que es la versión escrita
inmediatamente antes de la ejecución teórica de T (marca temporal de T)

 Marca de tiempo para lecturas:

- Cada versión tiene una marca de tiempo que indica la marca de tiempo de la última transacción que la leyó (la
marca de tiempo de transacción más alta que la leyó)

Si una transacción intenta realizar una escritura sobre un ítem pero la marca de tiempo de dicha escritura sería inferior a la
marca de tiempo de lectura de la versión previa, entonces se aborta la escritura.

Si una versión tiene una marca de tiempo de escritura tal que no existe ninguna transacción activa con marca temporal
menor, entonces todas las versiones anteriores a dicha versión pueden eliminarse.

Implementación de la Persistencia
Diseño y Creación de la Bitácora
A continuación se mencionan, de manera general, los tipos de entradas que se escriben en la bitácora y la acción que realiza
cada una de ellas.
T se refiere a un identificador de transacción único que el sistema genera automáticamente y que sirve para identificar cada
transacción:

1. [inicio_de_transacción, T]: Asienta que se ha iniciado la ejecución de la transacción T.

2. [escribir_elemento,T,X, Valor_anterior,nuevo_valor]: Asienta que la transacción T cambió el valor del elemento de base
de datos X de valor_anterior a nuevo_valor.

3. [leer_elemento,T,X]: Asienta que la transacción T leyó el valor del elemento de base de datos X.

4. [confirmar,T]: Asienta que la transacción T terminó con éxito y establece que su efecto se puede confirmar (asentar

permanentemente) en la base de datos.

5. [abortar,T]: Asienta que se abortó la transacción T.

Tipos de registros:

Undo logging

- <escritura, numTrans, idDato, valViejo>

- Sólo deshace transacciones incompletas
- Para hacer commit, se requiere antes escribir todos los datos cambiados en la BD en disco

Redo logging

- <escritura, numTrans, idDato, valNuevo>

- Sólo rehace cambios realizados por transacciones confirmadas
- Es preciso actualizar el fichero de log incluyendo el commit, antes de modificar los datos en disco
- Las transacciones incompletas se pueden tratar durante la recuperación como si nunca hubieran existido

Undo/redo logging

- Antes de cambiar un dato en disco hay que escribir el cambio en el log en disco.
- Más flexibilidad en cuanto al orden relativo con el que los registros de commit de log y los cambios en la BD se
escriben en el disco.
- Rehace las transacciones confirmadas (empezando por las más antiguas) y deshace las transacciones incompletas
(empezando por las más nuevas)

Registros de log (caso general, undo/redo logging)

 <comienza-transacción, numTrans>

 <escritura, numTrans, idDato, valViejo, valNuevo>s2d3r4

 <lectura, numTrans, idDato, val>  salvo si el protocolo evita rollback en cascada.

 <termina_transacción_con_éxito, numTrans >

 <punto_comprobación, numTrans, numPuntoComprob>. Puntos de comprobación / salvaguarda

(checkpoints)

Tipos de fallos:
  Fallo informático (system crash): hardware, software, red.

 Error del sistema o transacción: desbordamiento de un entero, división por 0, errores de parámetros,
errores de programación, etc.

 Errores locales o condiciones de excepción detectadas por una transacción: datos que no se encuentran,
saldo insuficiente, etc.

 Control de concurrencia: transacciones abortadas para garantizar la serializabilidad o para romper un

abrazo mortal

 Fallo del disco (lectura/escritura)

 Problemas físicos y catástrofes: fuego, inundación, robo, sabotaje, fallos humanos (sobreescritura de
datos incorrecta, borrado de datos, …), etc.

¿Puedo eliminar todos los registros del log para transacciones ya confirmadas?

No, se debe eliminar porque si sucede un fallo catastrófico de disco, se puede recurrir a una copia de seguridad y con el log
(log online, log archivado) se puede recuperar la información de las transacciones realizadas entre el momento de la copia
de seguridad y el momento del fallo.

Recuperación a partir de la Bitácora

Los protocolos de recuperación que evitan las reversiones en cascada no requieren que las operaciones LEER se asienten en
la bitácora del sistema, pero otros protocolos sí necesitan estas entradas para la recuperación. En el primer caso, el costo
extra de asentar las operaciones en la bitácora se reduce, porque en ella se registran menos operaciones, sólo las de
ESCRIBIR. Además, los protocolos estrictos requieren entradas ESCRIBIR más simples que no incluyen nuevo _ valor.

Si el sistema se cae, podemos recuperar la base de datos a un estado consistente examinando la bitácora y usando una de
las técnicas de recuperación. Dado que la bitácora contiene un registro de cada operación ESCRIBIR que altera el valor de
algún elemento de la base de datos, es posible deshacer (cancelar) el efecto de estas operaciones ESCRIBIR de una
transacción T rastreando hacia atrás en la bitácora y restableciendo todos los elementos alterados con una operación
ESCRIBIR T a su valor _ anterior.

También podemos rehacer el efecto de las operaciones ESCRIBIR de una transacción t rastreando hacia delante en la
bitácora y cambiando todos los elementos modificados por una operación ESCRIBIR de T a su nuevo _ valor.

Una transacción T llega a su punto de confirmación cuando todas sus operaciones que tienen acceso a la base de datos se
han ejecutado con éxito y el efecto de todas estas operaciones se ha asentado en la bitácora.

Contenido de la Bitácora
Según [David M. Kroenke]

La bitácora contiene un registro de las modificaciones de los datos en orden cronológico. Las transacciones se escriben en la
bitácora, antes de su aplicación a la base de datos. Si el sistema se cae antes de que la transacción haya sido registrada y el
momento en que se aplica, en el peor de los casos, existe un registro de una transacción no aplicada. Si las transacciones
fueron aplicadas antes de su inclusión en la bitácora, seria posible modificar la base de datos, pero no tener registro del
cambio. 
Responsabilidades del Gestor de Transacciones
o Demarcación de transacciones (begin/commit/rollback).
o Planificación equitativa de su ejecución [fairness].
o Registro de sus actividades (writes, commits & aborts).
o Detección de conflictos, p.ej. deadlocks.
o Ejecución de tareas de recuperación [recovery].