TRANSACCIONES

DISEO DE
BASE DE DATOS

TRANSACCION

Coleccin

de operaciones
que forman una nica
unidad lgica de trabajo.

Propiedad de una
transaccin
Atomicidad
Consistencias

Aislamiento
Durabilidad

-- Concurrencia

ATOMICIDAD
Todas

las operaciones de la transaccin

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

consistencia
La

ejecucin aislada de la transaccin

(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 ejecucin, sino que
se realizaran de forma independiente.

DURABILIDAD
Tras

la finalizacin con xito de una

transaccin, 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

T(x)

de BD a memoria intermedia de la

Escribir (x)
Transfiere

de datos

de memoria intermedia a la base

EJEMPLO

Sea Ti una transaccin para transferir Q. 50.00

de la cuenta A hacia la cuenta B. Se puede
definir dicha transaccin 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 (transaccin)
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 pasara si durante el proceso de ejecutar
la transaccin ocurriera un fallo en el sistema?
Alimentacin
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 pasara si durante el proceso de
ejecutar la transaccin ocurriera un fallo en
el sistema?

analizando
Aislamiento

Que pasara si todas las 3 propiedades se

cumplieran sin problema sin embargo 2
cuenta habientes hacen un retiro al mismo
tiempo?
La solucin es ejecutarlas secuencialmente
las transacciones

Modelos de almacenamiento

Voltil

No Voltil

Falta de energa elctrica se pierde la

informacin
Falta de energa NO se pierde la informacin
Discos duros, CDs, etc.

Permanente

No importa lo que pase siempre se dispondr

de la informacin
Mltiples copias

Modelos de almacenamiento
Almacenamiento

No voltil

Almacenamiento

Secundario

Es voltil
RAM

Primario

procesamiento
Procesamiento

Es aquel que se da cuando varios procesos

corren al mismo tiempo

Procesamiento

Concurrente

Paralelo

Sistema operativo maneja recursos de un

sistema y guarda la informacin en bloques
(sectores)

Bloque y buffer
Bloque

Es la unidad de almacenamiento
secundario

Buffer

Es la unidad de transferencia de
informacin 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

transaccin que termina su

ejecucin con xito se dice que est
comprometida
Una transaccin comprometida que
haya hecho modificaciones transforma la
base de datos llevndola 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

transaccin que no termina su

ejecucin 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
transaccin abortada debe deshacerse
Una vez deshechos los cambios de una
transaccin abortada se dice que la
transaccin se ha retrocedido

MODELO DE TRANSACCION

Una transaccin debe estar en uno de los siguientes estados:

Activa (estado inicial): la transaccin permanece en este
estado durante su ejecucin
Parcialmente Comprometida: la transaccin pasa a este
estado cuando acaba de realizar la ltima instruccin
Fallida: la transaccin pasa a este estado tras descubrir que
no puede continuar la ejecucin normal
Abortada: la transaccin pasa a este estado despus de
haber restablecido la base de datos a su estado anterior
Comprometida: la transaccin pasa a este estado tras
completarse con xito

MODELO DE TRANSACCION
Commit
parcialmente
comprometida

comprometida

activa

Fallo

fallida

Rollback

abortada

Implementacin de
transacciones sql

En la norma SQL el comienzo de una transaccin

se especifica explcitamente (usualmente
begin/start transaction)
Las transacciones terminan con una de las
siguientes instrucciones:
commit work (compromete la transaccin actual)
rollback work (provoca que la transaccin
aborte)
Si el programa termina sin ninguna de estas
rdenes, los cambios se comprometen o abortan
segn indique cada sistema

Implementacin 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)

Implementacin de
transacciones sql

Begin transaction

ReadDB (cta, saldo)

If saldo >= valor then

Begin

End
Begin

Saldo = saldo valor

WriteDB (cta, saldo)
Commit
Write (Pague)

WriteDB (histo, x)
Commit

End

Modelo de fallo
E
D
C
B
A

Tiempo de verificacin

Tiempo de fallo

RECUPERACION DEL SISTEMA

Para que el sistema se pueda recuperar ante

fallos se necesita grabar cada operacin con
la BD en un fichero LOG (bitcora).
Checkpoints.

Se escribe en el fichero LOG antes que en la BD

El fichero LOG debe estar en memoria estable

Por cada operacin se escribe un reg. en LOG

<comienza-transaccin, numt>
<escritura, numt, id_dato, val_viejo, val_nuevo>
<lectura, numt, id_dato, valor>
<termina_transaccin_con_xito, numt>
<punto_comprobacin, 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)
Cuenta A = 10,000
Cuenta B = 5,000
Cuenta C = 1,000
Cuenta D = 10,000
Cuenta E = 10,000
Cuenta F = 3,000
Cuenta G = 8,000

Transaction T1
Begin transaction
ReadDB(A)
A = A + 5000
WriteDB(A)
Commit

Transaction T3
Begin transaction Transaction T4
Begin transaction
ReadDB(D)
ReadDB(A)
ReadDB(G)
A= A 10,000
D= D 1000
WriteDB(A)
G= G + 1000
Commit
WriteDB(D)
WriteDB(G)
Commit

Transaction T2
Begin transaction
ReadDB(B)
ReadDB(C)
B= B 1000
C = C + 1000
WriteDB(B)
WriteDB(C)
Commit
Transaction T5
Begin transaction
ReadDB(B)
B= B + 10,000
WriteDB(B)
Commit

Problemas de concurrencia
La

ejecucin concurrente de
transacciones puede dar lugar a
problemas:

Problema de la actualizacin perdida

Problema de leer una actualizacin
temporal (lectura sucia)
Problema del resumen incorrecto
Problema de la lectura no repetible

Tcnicas de bloqueo (lock)

A cada elemento de datos o grnulo X de la

BD se le asocia una variable
operacin lock_exclusivo(X): deja bloqueado al
que lo pide si otro ya tiene cualquier lock sobre
X
operacin
lock_compartido(X):
deja
bloqueado al que lo pide si otro ya tiene un
lock exclusivo sobre X
operacin 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 ms unlock(X)

Deadlocks

Deadlock (o abrazo mortal o interbloqueo):

Cuando una transaccin T1 est bloqueada esperando a
que otra T2 libere un lock, la cual tambin est bloqueada
esperando a que T1 libere uno de sus lock. Se puede
generalizar para N transacciones.

Prevencin de deadlocks

Cada transaccin obtiene todos los locks al principio y si no

puede entonces no obtiene ninguno. Problema de livelock
(inanicin de algunas transacciones que pueden no obtener
todos los que necesiten)
Los elementos de la BD estn ordenados de alguna manera y
los lock hay que obtenerlos en dicho orden. Los programadores
deben controlarlo !!

Deteccin y recuperacin de deadlocks.

A medida que se piden y conceden los lock se construye un

grafo de las transacciones que estn 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;