TRANSACCIONES

DISEÑO DE
BASE DE DATOS
TRANSACCION

Colección de operaciones
que forman una única
unidad lógica de trabajo.
Propiedad de una
transacción

 Atomicidad
 Consistencias
 Aislamiento -- Concurrencia
 Durabilidad
ATOMICIDAD

 Todas las operaciones de la transacción

se realizan adecuadamente en la base
de datos o ninguna de ellas
consistencia

 La ejecución aislada de la transacción

(sin otra que se ejecute
concurrentemente) conserva la
consistencia de la base de datos)
aislamiento

 Aunque se ejecuten varias transacciones

concurrentemente, el sistema garantiza
que para cada par de transacciones, no
se entrelazaran en su ejecución, sino que
se realizaran de forma independiente.
DURABILIDAD

 Trasla finalización con éxito de una

transacción, los cambios realizados en la
base de datos permanecen, incluso si
hay fallos en el sistema.
Propiedades ACID

Atomicity,
Consistency,
Isolation
Durability
ACCESO A LA BASE DE DATOS
 Mediante 2 operaciones
 Leer (x)
 Transfiere de BD a memoria intermedia de la
T(x)
 Escribir (x)
 Transfiere de memoria intermedia a la base
de datos
EJEMPLO
 Sea Ti una transacción para transferir Q. 50.00
de la cuenta A hacia la cuenta B. Se puede
definir dicha transacción como
Ti:leer(A);
A := A – 50;
escribir(A);
leer(B);
B := B + 50;
escribir(B).
analizando
 Consistencia
 Que no sea alterado el balance de las
cuentas A y B al efectuar el traslado de
fondos (transacción)
 Responsabilidad:
 Programador
analizando
 Atomicidad
 Suponiendo que la cuenta A tiene Q.1,000 y la
B tiene Q.2,000 antes de efectuar el traslado
 Que pasaría si durante el proceso de ejecutar
la transacción ocurriera un fallo en el sistema?
 Alimentación
 Hardware
 Software
 Otro
analizando
 Durabilidad
 Una vez se completa con éxito una T(x)
aunque ocurriera un fallo en el sistema no
se puede corromper dicha T(x)
 Que pasaría si durante el proceso de
ejecutar la transacción ocurriera un fallo en
el sistema?
analizando
 Aislamiento
 Que pasaría si todas las 3 propiedades se
cumplieran sin problema sin embargo 2
cuenta habientes hacen un retiro al mismo
tiempo?
 La solución es ejecutarlas secuencialmente
las transacciones
Modelos de almacenamiento
 Volátil
 Falta de energía eléctrica se pierde la
información
 No Volátil
 Falta de energía NO se pierde la información
 Discos duros, CDs, etc.
 Permanente
 No importa lo que pase siempre se dispondrá
de la información
 Múltiples copias
Modelos de almacenamiento
 Almacenamiento Secundario
 No volátil
 Almacenamiento Primario
 Es volátil
 RAM
procesamiento
 Procesamiento Concurrente
 Es aquel que se da cuando varios procesos
corren al mismo tiempo
 Procesamiento Paralelo
 Sistema operativo maneja recursos de un
sistema y guarda la información en bloques
(sectores)
Bloque y buffer
 Bloque
 Es la unidad de almacenamiento
secundario

 Buffer
 Es la unidad de transferencia de
información entre el almacenamiento
primario y secundario
 Es la unidad de almacenamiento primario
Bloque y buffer
 Por lo regular si el DBMS pide un registro
trae todo el bloque
 El cual puede contener varios registros.
MODELO DE TRANSACCION
 Una transacción que termina su
ejecución con éxito se dice que está
comprometida
 Una transacción comprometida que
haya hecho modificaciones transforma la
base de datos llevándola a un nueva
estado consistente, que permanece
incluso si hay fallo en el sistema
 En ausencia de fallos, todas las
transacciones se completan con éxito
 MODELO DE TRANSACCION
 Una transacción que no termina su
ejecución con éxito se dice que está
abortada
 Para asegurar la atomicidad, las
transacciones abortadas no deben tener
efecto sobre el estado de la base de datos,
cualquier cambio que haya hecho la
transacción abortada debe deshacerse
 Una vez deshechos los cambios de una
transacción abortada se dice que la
transacción se ha retrocedido
 MODELO DE TRANSACCION
 Una transacción debe estar en uno de los siguientes estados:
 Activa (estado inicial): la transacción permanece en este
estado durante su ejecución
 Parcialmente Comprometida: la transacción pasa a este
estado cuando acaba de realizar la última instrucción
 Fallida: la transacción pasa a este estado tras descubrir que
no puede continuar la ejecución normal
 Abortada: la transacción pasa a este estado después de
haber restablecido la base de datos a su estado anterior
 Comprometida: la transacción pasa a este estado tras
completarse con éxito
MODELO DE TRANSACCION
Commit
parcialmente comprometida
comprometida

activa
Fallo

Rollback
fallida abortada
Implementación de
transacciones sql
 En la norma SQL el comienzo de una transacción
se especifica explícitamente (usualmente
begin/start transaction)
 Las transacciones terminan con una de las
siguientes instrucciones:
 commit work (compromete la transacción actual)
 rollback work (provoca que la transacción
aborte)

 Si el programa termina sin ninguna de estas

órdenes, los cambios se comprometen o abortan
según indique cada sistema
Implementación de
transacciones sql
 Programa pagar_cheque
 Write (‘ingrese cuenta’)
 Read (cta)
 Write (‘valor’)
 Read (valor)
 Begin transaction
 ReadDB (cta, saldo)
 Saldo = saldo – valor
 WriteDB (cta, saldo)
 Write DB (cheque, ‘P’)
 Commit
 Write (‘Pague’)
Implementación de
transacciones sql
 Begin transaction
 ReadDB (cta, saldo)
 If saldo >= valor then
 Begin
 Saldo = saldo – valor
 WriteDB (cta, saldo)
 Commit
 Write (‘Pague’)
 End
 Begin
 WriteDB (histo, x)
 Commit
 End
Modelo de fallo
E

Tiempo de verificación Tiempo de fallo

RECUPERACION DEL SISTEMA
 Para que el sistema se pueda recuperar ante
fallos se necesita grabar cada operación con
la BD en un fichero LOG (bitácora).
Checkpoints.
 Se escribe en el fichero LOG antes que en la BD
 El fichero LOG debe estar en memoria estable
 Por cada operación se escribe un reg. en LOG
 <comienza-transacción, numt>
 <escritura, numt, id_dato, val_viejo, val_nuevo>
 <lectura, numt, id_dato, valor>
 <termina_transacción_con_éxito, numt>
 <punto_comprobación, numt, numc>
Bitacora (log)
 Archivo especial que no conviene tenerlo
en el mismo disco o directorio donde esta
la base de datos.

Almacenamiento
secundario

bitacor
a

Almacenamiento
primario
Bitacora (log) Transaction T2
Cuenta A = 10,000 •Begin transaction
Cuenta B = 5,000 Transaction T1 •ReadDB(B)
Cuenta C = 1,000 •Begin transaction •ReadDB(C)
Cuenta D = 10,000 •ReadDB(A) •B= B – 1000
Cuenta E = 10,000 •A = A + 5000 •C = C + 1000
Cuenta F = 3,000 •WriteDB(A) •WriteDB(B)
Cuenta G = 8,000 •Commit •WriteDB(C)
•Commit
Transaction T3
•Begin transaction Transaction T4 Transaction T5
•ReadDB(D) •Begin transaction •Begin transaction
•ReadDB(G) •ReadDB(A) •ReadDB(B)
•D= D – 1000 •A= A – 10,000 •B= B + 10,000
•G= G + 1000 •WriteDB(A) •WriteDB(B)
•WriteDB(D) •Commit •Commit
•WriteDB(G)
•Commit
Problemas de concurrencia
 Laejecución concurrente de
transacciones puede dar lugar a
problemas:
 Problema de la actualización perdida
 Problema de leer una actualización
temporal (lectura sucia)
 Problema del resumen incorrecto
 Problema de la lectura no repetible
Técnicas de bloqueo (lock)
 A cada elemento de datos o gránulo X de la
BD se le asocia una variable
 operación lock_exclusivo(X): deja bloqueado al
que lo pide si otro ya tiene cualquier lock sobre
X
 operación lock_compartido(X): deja
bloqueado al que lo pide si otro ya tiene un
lock exclusivo sobre X
 operación unlock(X): libera su lock sobre X
 Antes de leer X  lock_compartido(X)
 Antes de escribir (leer) X  lock_exclusivo(X)
 Si no se va a leer o escribir más  unlock(X)
Deadlocks
 Deadlock (o abrazo mortal o interbloqueo):
Cuando una transacción T1 está bloqueada esperando a
que otra T2 libere un lock, la cual también está bloqueada
esperando a que T1 libere uno de sus lock. Se puede
generalizar para N transacciones.
 Prevención de deadlocks
 Cada transacción obtiene todos los locks al principio y si no
puede entonces no obtiene ninguno. Problema de livelock
(inanición de algunas transacciones que pueden no obtener
todos los que necesiten)
 Los elementos de la BD están ordenados de alguna manera y
los lock hay que obtenerlos en dicho orden. Los programadores
deben controlarlo !!
 Detección y recuperación de deadlocks.
 A medida que se piden y conceden los lock se construye un
grafo de las transacciones que están esperando a otras. Si
existe un ciclo en dicho grafo: deadlock. Hay que proceder a
abortar a alguna de las transacciones. Problema de livelock si
se aborta siempre a la misma!
En la practica (Oracle pl/sql)
 DECLARE
importe NUMBER;
ctaOrigen VARCHAR2(23);
ctaDestino VARCHAR2(23);
BEGIN
importe := 100;
ctaOrigen := '2530 10 2000 1234567890';
ctaDestino := '2532 10 2010 0987654321';
UPDATE CUENTAS SET SALDO = SALDO - importe
WHERE CUENTA = ctaOrigen;
UPDATE CUENTAS SET SALDO = SALDO + importe
WHERE CUENTA = ctaDestino;
INSERT INTO MOVIMIENTOS
(CUENTA_ORIGEN, CUENTA_DESTINO,IMPORTE, FECHA_MOVIMIENTO)
VALUES
(ctaOrigen, ctaDestino, importe*(-1), SYSDATE);
INSERT INTO MOVIMIENTOS
(CUENTA_ORIGEN, CUENTA_DESTINO,IMPORTE, FECHA_MOVIMIENTO)
VALUES
(ctaDestino,ctaOrigen, importe, SYSDATE);
COMMIT;
EXCEPTION
WHEN OTHERS THEN
dbms_output.put_line('Error en la transaccion:'||SQLERRM);
dbms_output.put_line('Se deshacen las modificaciones);
ROLLBACK;
END;
EN LA PRACTICA (ORACLE
PL/SQL)
 create or replace procedure prueba (nfilas number)
as
begin
savepoint ninguna;
insert into tmp values ('primera fila');
savepoint una;
insert into tmp values ('segunda fila');
savepoint dos;
if nfilas=1 then
rollback to una;
else if nfilas=2 then
rollback to dos;
else
rollback to ninguna;
end if;
commit;
exception
when other then
rollback
end prueba;