ADMINISTRACION DE BASE

DE DATOS
Ing. Armando Caballero Alvarado
acaballeroa@upao.edu.pe
www.acaballeroa.upao.edu.pe
CAPITULO IX

TRANSACCIONES Y CONTROL
DE CONCURRENCIA
 Contenido
1. Transacciones

2. Control de concurrencia
TRANSACCIONES
 Concepto de Transacción
• Un transacción es una unidad de ejecución de programa que
accede y que posiblemente actualiza varios elementos de datos.
• Un transacción debe mantener una base de datos consistente
• Durante la ejecución de una transacción la base de datos puede
ser inconsistente
• Cuando la transacción es confirmada, la base de datos debe ser
consistente
• Dos principales asuntos para tratar con:
– Varias clases de fallas, tal como fallas de hardware y caídas
del sistema
– Ejecución concurrentes de múltiples transacciones
 Propiedades ACID
Para mantener la integridad de los datos, el sistema de base de datos debe asegurarse:

• Atomicidad. Cualquiera de todas las operaciones de la transacción están debidamente reflejadas

en la base de datos o no hay ninguno.
• Consistencia. La ejecución de una transacción en aislamiento preserva la consistencia de la base
de datos.
• Aislamiento
– A través de múltiples transacciones se puede ejecutar concurrentemente cada transacción, el
cual debe ser ignorado de otra transacción ejecutándose concurrentemente.
– Los resultados de la transacción intermedia deben ser ocultos de otras transacciones
ejecutadas concurrentemente.
– Es decir, por cada par de las transacciones Ti y Tj, se cumple que para los efectos de Ti
cualquier Tj ha finalizado su ejecución antes que termine Ti, o Tj ha comenzado su ejecución
después que Ti termine.
• Durabilidad. Después que una transacción se completa satisfactoriamente, los cambios se hacen
a la base de datos persistente, los cambios son hecho a la base de datos persistente, aun si los
sistemas fallan.
 Ejemplo de transferencia de fondos
• La transacción transfiere $50 de la cuenta A a la cuenta
B:
1. leer(A)
2. A := A – 50
3. escribir(A)
4. leer(B)
5. B := B + 50
6. escribir(B)
 Ejemplo de transferencia de fondos (Cont.)
• Requerimiento de Consistencia – la suma de A y B es inalterado por la
ejecución de la transacción.
• Requerimiento de Atomicidad — si la transacción falla después del paso 3 y
antes del paso 6, el sistema debe asegurarse que esta actualización no debe
reflejarse en la base de datos, en caso contrario podría resultar inconsistente.
• Requerimiento de Durabilidad — una vez que el usuario haya notificado que la
transacción se ha completado (ej., la transferencia de los $50 ha tenido lugar),
la actualización a la base de datos por la transacción debe persistir a pesar de
las fallas.
• Requerimiento de Aislamiento — si entre los pasos 3 y 6, otra transacción
puede acceder a la base de datos actualizada parcialmente, se tendrá una base
de datos inconsistente (la suma A + B puede ser menor de lo que debe ser).
Puede ser asegurado trivialmente ejecutando transacciones serialmente, esto es
uno después el otro. Sin embargo, ejecutando múltiples transacciones
concurrentemente tiene beneficios significativos, como puede observarse.
 Estado de la Transacción
• Activo  el estado inicial; la transacción se queda en este estado
mientras se esta ejecutando
• Parcialmente confirmado  después que la sentencia final haya
sido ejecutada.
• Fallado  después de descubrir que la ejecución final ya no puede
proceder.
• Abortado  después que la transacción haya sido deshecha y la base
de datos restaurada al estado previo de inicio de la transacción.
Dos opciones después que haya sido abortada:
– Reiniciar la transacción – solo sino tiene error lógico interno
– Matar la transacción
• Confirmado  después que se haya completado satisfactoriamente.
Estado de la Transacción (Cont.)
 Implementación de Atomicidad y Durabilidad
• El componente de administración de recuperación del sistema de base de datos
implementa el soporte para atomicidad y durabilidad.
• Esquemas de Recuperación: enfoque basado en Log vs enfoque Espejado

• El esquema de base de datos espejo:

– asume que solo una transacción esta activa en un tiempo.
– un puntero llamado db_pointer siempre apunta a la copia consistente actual
de la base de datos.
– todas las actualizaciones son hechas en una copia espejo de la base de datos, y
el db_pointer se hace apuntar a la copia espejo actualizada, solo después que
la transacción alcanza una confirmación parcial y todas las páginas
actualizadas hayan sido grabadas al disco.
– en caso que la transacción falla, una copia consistente antigua puede ser usada
por el db_pointer, y la copia espejo puede ser borrada.
 Implementación de Atomicidad y Durabilidad (Cont.)

El esquema base de datos espejo:

a) Antes de la Actualización b) Después de la Actualización

• Se asume que los discos no fallan

• Simple y útil para editores de texto, pero extremadamente ineficiente para grandes
base de datos: ejecutando una simple transacción se requiere copiar la base de
datos completa.
 Ejecuciones Concurrentes
• Múltiples transacciones son permitidas para ejecutarse concurrentemente
en el sistema. Las ventajas son:
– Incremento del uso de procesador y utilización del disco
• Conducen a un mejor throughput de la transacción
• Una transacción puede estar usando el CPU mientras otra esta
leyendo o escribiendo al disco
– Reduce el tiempo promedio de respuesta de las transacciones
• Transacciones cortas no necesitan esperar detrás de las largas

• Esquemas de control de Concurrencia

– mecanismos para lograr aislamiento
– ej., para controlar la cantidad de interacción entre las transacciones
concurrentes, a fin de evitar la destrucción de la consistencia de la base
de datos
 Planificaciones (Schedules)
• Planificaciones – son secuencias que indican el orden
cronológico en el cual las instrucciones de las transacciones
concurrentes son ejecutadas
– una planificación para un conjunto de transacciones debe
consistir de todas las instrucciones de esas transacciones
– Debe preservar el orden en el cual las instrucciones aparecen
en cada transacción individual.
• Planificación serial – secuencia de instrucciones de una a una de
transacciones
 Ejemplo: Planificación 1

• T1 transfiere $50 de A hacia B, y T2

transfiere 10% del saldo de A hacia B.
• El siguiente es una planificación
secuencial en el cual T1 es seguido por
T2 .
 Planificación 2

El siguiente es una

planificación secuencial en el
cual T2 es seguido porT1.
 Planificación 3

• T1 y T2 son las transacciones definidas

anteriormente
• La siguiente planificación no es un schedule
secuencial, pero es equivalente a la
Planificación 1
• Podríamos llamarlo una planificación
secuenciable

En ambas Planificaciones 1 y 3, la suma A + B se conserva.

 Planificación 5

• La siguiente planificación concurrente no

conserva el valor de la suma A + B.
• La siguiente planificación no es
secuenciable.
 Secuencialidad
• Supuesto básico – Cada transacción conserva la consistencia de la base de datos.
• Así la ejecución serial de un conjunto de transacciones conserva la consistencia de la
base de datos.
• Una planificación (posiblemente concurrente) es secuenciable si es equivalente a
una planificación serial.
• Diferentes formas de planificación equivalentes dan lugar a los conceptos siguientes
de:
1. conflictos de secuencialidad
2. vistas de secuencialidad
• Ignoramos otras operaciones que lean y escriban instrucciones, y asumimos que las
transacciones pueden ejecutarse arbitrariamente realizando cálculos sobre los datos
en el buffer local entre lectura y escritura.
– Nuestras planificaciones simplificados consisten de solo instrucciones de
lectura y escritura.
 Conflicto de Secuencialidad
• Las instrucciones li y lj de transacciones Ti y Tj respectivamente, están en
conflicto si y solo si ahí existe algún Q accesado por ambas li y lj, y al
menos una de estas instrucciones escribe Q.
1. li = read(Q), lj = read(Q). li y lj no tienen conflicto
2. li = read(Q), lj = write(Q). Tienen conflicto
3. li = write(Q), lj = read(Q). Tienen conflicto
4. li = write(Q), lj = write(Q). Tienen conflicto

• Intuitivamente, un conflicto entre li y lj fuerza un orden temporal (lógico)

entre ellos.
– Si li y lj son consecutivos en una planificación y ellos no tienen
conflicto, sus resultados siguen siendo los mismos, incluso si se
hubieran intercambiado en la planificación.
 Conflicto de Secuencialidad (Cont.)
• Si una planificación S puede ser transformado en una planificación S´ por una serie de
intercambios de instrucciones no conflictivas, decimos que S y S´ están en conflicto
equivalente.
• Decimos que una planificación S esta en conflicto secuenciable si éste está en conflicto
equivalente para una planificación serial.
• Ejemplo de una planificación que no esta en conflicto secuenciable:
T3 T4
leer(Q)
escribir(Q)
escribir(Q)

No podemos cambiar las instrucciones de la planificación de arriba para obtener cualquiera

de la planificación serial < T3, T4 >, o la planificación serial < T4, T3 >.

T3 T4 T3 T4
leer(Q) escribir(Q)
escribir(Q) leer(Q)
escribir(Q) escribir(Q)
 Conflicto de Secuencialidad (Cont.)
• La planificación 3 de abajo puede ser transformado en la planificación 1, una planificación serial
donde T2 sigue a T1, por series de intercambio de instrucciones no conflictivas.
• La 3rd y 4th líneas pueden ser intercambiadas con las líneas 5th y 6th
• En consecuencia la siguiente planificación 3 esta en conflicto secuencial.

Planificación 3
Planificación 5
Después de intercambiar un par de instrucciones no conflictivas en la
planificación 3
Planificación 6 –
Una planificación serial que es equivalente a la planificación 3
 Definición de Transacción en SQL
• El lenguaje de manipulación de datos debe incluir un constructor
para especificar el conjunto de acciones que comprende una
transacción.
• En SQL, una transacción inicia implícitamente.
• Una transacción en SQL termina con:
– Commit work confirma la transacción actual e inicia una
nueva.
– Rollback work causa abortar la transacción actual.
• Niveles de consistencia especificados por SQL-92:
– Serializable — defecto
– Repeatable read
– Read committed
– Read uncommitted
Control de transacciones en Oracle
CONTROL DE
CONCURRENCIA
 Protocolos basados en Bloqueo
• Un bloqueo es un mecanismo para controlar el acceso concurrente a
los ítem de datos
• Los ítem de datos pueden ser bloqueados en dos modos :
1. modo exclusivo (X): ítem de datos pueden ser leídos como escritos.
– X-lock es solicitado usando la instrucción lock-X.
2. modo shared (S): ítem de datos pueden ser solo leídos.
– S-lock es solicitado usando la instrucción lock-S.
• Solicitudes de Bloqueo son hechos por el administrador de
concurrencia
• La transacción puede proceder solo después de que la solicitud ha sido
concedida
 Protocolos basados en Bloqueo (Cont.)
• Matriz de compatibilidad de Bloqueo

• A una transacción se le puede conceder un bloqueo sobre un ítem si la solicitud

de bloqueo es compatible con bloqueos ya existentes sobre el ítem por otras
transacciones
• Cualquier numero de transacciones pueden retener bloqueos compartidos sobre
un ítem, pero si cualquier transacción retiene un bloqueo exclusivo sobre el ítem
cualquier otra transacción no puede retener cualquier bloqueo sobre el ítem.
• Si un bloqueo no puede ser concedido, la transacción solicitante esta en espera
hasta que todos los bloqueos incompatibles retenidos por otras transacciones
puedan ser liberados. El bloqueo es entonces concedido.
 Protocolos basados en Bloqueo (Cont.)

• Ejemplo de una transacción ejecutando bloqueo:

T2: lock-S(A);
read (A);
unlock(A);
lock-S(B);
read (B);
unlock(B);
display(A+B)
• El bloqueo del caso anterior no es suficiente para garantizar secuencialidad — si A y B
son actualizados entre la lectura de A y B, el display de la suma seria un error.
• Un protocolo de bloqueo es un conjunto de reglas seguidas por todas las transacciones
de solicitudes y liberación de bloqueos
• Protocolos de bloqueo restringe el conjunto de posibles planificaciones.
• El protocolo de bloqueo debe asegurar secuencialidad.
 Planificación para Transacciones:
Planificación no secuenciable

T1 T2 administración
Ejemplo de transacciones con control concurrencia
bloqueos lock-X(B)
grant-X(B, T1)
 T1: lock-X(B) T2: lock-S(A) Read(B)
B = B - 50;
read(B) read(A) write(B);
B = B -50; unlock(A) unlock(B);
lock-S(A)
write(B); lock-S(B) grant-S(A, T2)
read(A)
unlock(B); read(B);
unlock(A)
lock-X(A); unlock(B); lock-S(B)
grant-S(B, T2)
read(A); display(A+B); read(B);
A = A + 50; unlock(B);
display(A+B);
write(A); lock-X(A);
unlock(A); grant-X(A, T2)
read(A);
A = A + 50;
write(A);
unlock(A);
 Interbloqueo de protocolos basado en Bloqueo
• Considere la planificación parcial
• Ninguno de las transacciones T3 ni T4 pueden avanzar
– Ejecutando lock-S(B) causa que T4 espere por T3 para
liberar el bloqueo en B, mientras esta ejecutando lock-
X(A) causa que T3 espere por T4 para liberar este
bloqueo en A.
• Tal situación es llamada deadlock (bloqueo sin salida o
abrazo mortal).
– Para manejar un deadlock uno de las transacciones T3 o
T4 debe ser finalizada y esto liberara el bloqueo.

 Potencialmente el deadlock existe en la mayoría de los protocolos de bloqueo.

 Starvation se puede presentar si el control de concurrencia esta mal diseñado. Por
ejemplo:
 una transacción puede estar esperando por un X-lock sobre un elemento, mientras
una secuencia de otras transacciones solicitan y otorgan un S-lock sobre el mismo
elemento.
 La misma transacción es repetidamente finalizada debido a los deadlocks.
 El administrador de control de concurrencia puede ser diseñado para prevenir starvation.
 Protocolo de bloqueo de dos fases
• Este es un protocolo el cual asegura conflictos de planificaciones
secuenciales.
• Fase 1: Fase de Crecimiento
– La transacción puede obtener bloqueos
– La transacción no puede liberar bloqueos
• Fase 2: Fase de Decrecimiento
– La transacción puede liberar bloqueos
– La transacción no puede obtener bloqueos
• El protocolo asegura secuencialidad.
– Puede ser demostrado que las transacciones pueden ser
secuenciales en el orden de sus puntos de bloqueo (ej. el punto
donde una transacción adquiere su bloqueo final).
 Protocolo de bloqueo de dos fases (Cont.)
• El bloqueo de dos fases no aseguran la liberación o ausencia de los deadlocks
• El retroceso en cascada puede ocurrir en el bloqueo de dos fases.
• Bloque estricto de dos fases.
– Aquí una transacción debe retener todos los bloqueos exclusivos hasta que
se complete (commit/abort).
– No hay rollback en cascada
• Bloqueo riguroso de dos fases es aun mas estricto:
– Aquí todos los bloqueos (compartidos y exclusivos) están retenidos hasta
un commit/abort.
– No hay rollback en cascada (de acuerdo)
– En este protocolo las transacciones puede ser secuenciales en el orden en
que ellos se confirman.
Planeación parcial con bloqueo de dos fases
 T1 T2
T1 T2
lock-S(X)
lock-X(A) A1read(X)
A1A1-K
read(A)
lock-X(X)
AA+100 lock-S(X)

write(A) XA1
Ejemplos write(X)
lock-X(B)
de protocolo lock-S(Y)
unlock(A)
de dos fases A2read(Y)

lock-X(A) A2A2+K

lock-X(Y)
read(A)
YA2
AA*2 write(Y)

unlock(X)
write(A)
A1read(X)
read(B) A1A1*0.01
BB+100 lock-X(X)

XA1
write(B)
write(X)
unlock(B) lock-S(Y)

lock-X(B) unlock(Y)

A2read(Y)
unlock(A)
A2A2*0.01
read(B) lock-X(Y)

BB*2 YA2

write(Y)
write(B)
unlock(X)
unlock(B) unlock(Y)
 Protocolo de bloqueo de dos fases (Cont.)
• No puede haber schedule secuenciable en conflicto que no se puede obtener si se
usa bloqueo de dos fases.
• Sin embargo, en la ausencia de información adicional (ej. ordenando acceso a los
datos), bloqueo de dos fases es necesaria por secuencialidad en conflicto en el
siguiente sentido:
En buena cuenta una transacción Ti que no siga un bloqueo de dos fases, podemos
encontrar una transacción Tj que usa un bloqueo de dos fases, y un schedule para
Ti y Tj que no es secuenciable en conflicto.

Planificaciones
secuenciales
de bloqueo de dos
fases
Planificación secuenciable
Planificaciones secuenciales por otros protocolos de
control de concurrencia
 Bloque de dos fases con conversión de bloqueos

• El modo de bloqueo original con (lock-X, lock-S)

– asignar lock-X en los datos D cuando D es leído y escrito
• Bloqueo de dos fases con conversión de bloqueo:
– Primera fase:
– Puede adquirir un lock-S sobre un elemento
– Puede adquirir un lock-X sobre un elemento
– Puede convertir un lock-S a un lock-X (upgrade)
– Segunda fase:
– Puede liberar un lock-S
– Puede liberar un lock-X
– Puede convertir un lock-X a un lock-S (downgrade)
• Este protocolo asegura secuencialidad.
• El bloqueo de dos fases refinado recoge mas concurrencia que el bloqueo de
dos fases original
 Fig 16.9 Schedule incompleto con una conversión de bloqueo

** A menos que la conversión de bloqueos, el primer paso ―lock-S (a1)‖ en T8

debe ser ―lock-X (a1)‖, entonces T8 y T9 en el siguiente Schedule no puede ser
ejecutado concurrentemente en el protocolo original de bloqueo de dos fases.
** Sin embargo, T8 y T9 puede ejecutarse concurrentemente en el protocolo de
bloqueo de dos fases refinado debido a la conversión de bloqueo
T8 T9
T8 T9 lock-X (a1)
read (a1) read (a1) lock –S (a2)
read (a2) read (a2) …..
….. a3 = a2 – a1 lock-S (an)
read (an) unlock (a1)
a1 = a1 + a2 … an lock-S (a1)
write(a1) lock-S (a2)

 protocolo de bloqueo de dos fases estricto (con conversión de bloqueo) &

protocolo de bloqueo de dos fases riguroso (con conversión de bloqueo)
son usados extensivamente en DBMS comerciales
 Adquisición automática de bloqueos
• Una transacción Ti usa la instrucción estándar
leer/escribir, sin llamadas de bloqueos explícitos.
• La operación leer(D) es procesada como:
si Ti tiene un bloqueo sobre D
entonces
leer(D)
en otro caso
iniciar
si necesariamente  esperar hasta que no haya otra transacción que tenga un
lock-X sobre D;
conceder Ti un lock-S sobre D;
leer(D);
fin
 Adquisición automática de bloqueos (Cont.)
• escribir(D) es procesado como:
Si Ti tiene un lock-X sobre D
entonces
escribir(D)
en otro caso
iniciar
si necesariamente  esperar hasta no haya otra transacción que tenga
cualquier bloqueo sobre D ;
si Ti tiene un lock-S sobre D
entonces
upgrade bloqueo sobre D a lock-X
en otro caso
conceder Ti un lock-X sobre D
escribir(D)
fin;

• Todos los bloqueos son liberados después del commit o abort

 Implementación de bloqueos
• Un administrador de bloqueo puede ser implementado como un proceso separado en el
cual las transacciones envían solicitudes de bloqueo y desbloqueo
• El administrador de bloqueo contesta una solicitud de bloqueo enviando mensajes de
concesión de bloqueo (o un mensaje preguntando a la transacción por un rollback en caso
de un deadlock)
• La solicitud de transacción espera hasta que la solicitud haya sido contestada
• El administrador de bloqueo mantiene una estructura de datos llamada una tabla de
bloqueo para registrar bloqueos concedidos y solicitudes pendientes
• La tabla de bloqueo es usualmente implementada como una tabla hash en memoria,
indexada sobre el nombre del elemento de datos que esta siendo bloqueado
– Hashing con encadenamiento de desbordamiento
– Solicitud de bloqueo sobre elemento I  Hashing (I) & cola & espera
– Bloqueo concedido
– Solicitud de desbloqueo  sacar de cola
Tabla de Bloqueo
• Los rectángulos negros indican bloqueos
concedidos, los blancos indican solicitud
en espera
• La tabla de bloqueo también registra el tipo de
bloqueo concedido o solicitado
• Nuevas solicitudes son adicionados al final de
la cola de solicitudes de datos, y concedidos si
es compatible con todos los bloqueos anteriores
• Las peticiones de desbloqueo tienen como
resultado la petición de ser borrado, y
peticiones posteriores son verificadas para ver
si ellos ahora pueden ser concedidos
• Si la transacción aborta, todos esperan conceder
solicitudes de la transacción que es eliminada
– El administrador de bloqueo puede
mantener una lista de bloqueos ayudados
por cada transacción, a fin de aplicarlo
eficientemente
 Protocolos basados en Grafos
 Los protocolos basado en grafos son alternativas al bloque de dos fases
 Impone un ordenamiento parcial  en el conjunto D = {d1, d2 ,..., dh} de todos
los datos.
 Si di  dj entonces toda transacción que acceda tanto a di como a dj
deben accesar a di antes de acceder a dj.
 Implica que el conjunto D puede ahora ser visto como un grafo aciclico
dirigido (DAG), llamado grafo de base de datos.
• El protocolo de árbol es un simple tipo de protocolo gráfico.
– Solo son permitidos bloqueos exclusivos.
– El primer bloqueo por Ti debe ser sobre cualquier dato si
este no es bloqueado sobre los datos.
– Subsecuentemente, un dato Q puede ser bloqueado por Ti
solo si el padre de Q es actualmente bloqueado por Ti.
– Datos pueden ser desbloqueados en cualquier momento.