TRANSACCIONES
DISEÑO DE BASE DE DATOS
TRANSACCION
 Colección
de operaciones que forman una
única unidad lógica de trabajo.
PROPIEDAD DE UNA TRANSACCION
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

Tras la 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
 Escribir
de BD a memoria intermedia de la tx
(x)
 Transfiere
de memoria intermedia a la base de datos
EJEMPLO

Sea Ti una transacción para transferir Q. 50 de
la cuenta A a 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
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
parcialmente
comprometida
Commit
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


 End
WriteDB (histo, x)
Commit
MODELO DE FALLO
E
D
C
B
A
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
bitacora
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 T3
•Begin transaction
•ReadDB(D)
•ReadDB(G)
•D= D – 1000
•G= G + 1000
•WriteDB(D)
•WriteDB(G)
•Commit
Transaction T1
•Begin transaction
•ReadDB(A)
•A = A + 5000
•WriteDB(A)
•Commit
Transaction T4
•Begin transaction
•ReadDB(A)
•A= A – 10,000
•WriteDB(A)
•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 ejecució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;
Descargar

commit - WordPress.com