Gestión de Transacciones DB

GestiGestin de n de transaccionestransacciones

Marta ZorrillaMarta Zorrilla

Universidad de CantabriaUniversidad de Cantabria

Lecturas recomendadasLecturas recomendadas Bsicas

Cap. 15-17. Silberschatz, A., Korth, H.F., Sudarshan, S., Fundamentos de Bases de Datos, 5 edicin, Madrid, 2006.

Cap. 17-19. Elmasri, R., Navathe, S.B., Fundamentos de Sistemas de Bases de Datos, 3; edicin, PearsonEducation, 2008.

Cap. 4. Pons, O. et al. Introduccin a las bases de datos. Paraninfo. 2007

Tabla de contenidoTabla de contenido Transacciones

Propiedades Elementos del gestor responsables del control

Estados de las transacciones Planificador de transacciones

Grafo de precedencia Secuencialidad en cuanto a conflictos

Recuperabilidad

Control de concurrencia Problemas de concurrencia Protocolos basados en bloqueo Protocolos basados en marcas temporales

Protocolos basados en validacin

Granularidad mltiples Esquemas multiversin Niveles de consistencia en SQL

Sistemas de recuperacin Clasificacin de los fallos Recuperacin y atomicidad

Acceso a los datos Ficheros de Log Copias de seguridad

Concepto de transacciConcepto de transaccinn

Una transaccin es una unidad de ejecucin de un programa que accede y posiblemente modifica los datos almacenados. (begin transaction, commit, rollback)

Transferir 50 desde una cuenta A a una cuenta B

leer(A)A := A 50escribir(A)leer(B)B := B + 50escribir(B)

Requisito de consistencia la suma de A y B no se altera por la ejecucin de la transaccin.

Requisito de atomicidad si la transaccin falla despus del paso 3 y antes del paso 6, el sistema debera asegurar que sus actualizaciones no se reflejan en la base de datos, de lo contrario resultar una inconsistencia.

Requisito de durabilidad desde que se notifica al usuario que se ha completado la transaccin (es decir, que ha tenido lugar la transferencia de 50 ), las actualizaciones de la base de datos producidas por la transaccin deben permanecer, a pesar de los fallos.

Requisito de aislamiento si entre los pasos 3 y 6 se permite acceder a otra transaccin a la base de datos parcialmente actualizada, ver una base de datos inconsistente ( la suma de A + B ser menor de lo que debera). Se puede asegurar de forma trivial ejecutando las transacciones secuencialmente, es decir, una detrs de otra.

Propiedades de las Propiedades de las transaccionestransacciones

Atomicidad. O todas las operaciones de la transaccin se reflejan correctamente en la base de datos, o ninguna.

Consistencia. La ejecucin aislada de una transaccin preserva la consistencia (coherencia) de los datos.

Aislamiento. Aunque varias transacciones se pueden ejecutar concurrentemente, cada transaccin debe ignorar a las otras transacciones que se ejecutan concurrentemente con ella. Es decir, por cada par de transacciones Ti y Tj, el sistema garantiza que, o bien Tj ha terminado su ejecucin antes de que comience Ti , o que Tj ha comenzado su ejecucin despus de que Ti terminara.

Durabilidad. Tras la finalizacin con xito de una transaccin permanecen los cambios realizados en la base de datos, incluso si hay fallos en el sistema.

Elementos del gestorElementos del gestor

El Gestor de Transacciones asegura la Atomicidad de las transacciones.

El Gestor de Concurrencia controla la interaccin entre las transacciones concurrentes (aislamiento) para garantizar la consistencia de la informacin.

El Gestor de Recuperacin que permite retornar a una situacin estable (durabilidad) a pesar de fallos en el sistema ( p. ej. Corte de luz, cada del S.O. ) o en las transacciones establecidas en los programas (p.e. reglas de negocio).

La consistencia la garantiza el programador

Estados de una transacciEstados de una transaccinn Activa, el estado inicial; la transaccin permanece en este estado mientras se est ejecutando.

Parcialmente comprometida, despus de ejecutarse la ltima instruccin.

Fallida, despus de descubrir que la ejecucin normal ya no puede llevarse a cabo.

Abortada, despus del retroceso de la transaccin y haber restaurado la base de datos su estado anterior al inicio de la transaccin. Dos opciones despus de que haya abortado: reiniciar la transaccin cancelar la transaccin

Comprometida, despus determinar con xito.

Planificador de transaccionesPlanificador de transacciones Responsable de determinar el orden de ejecucin de las transacciones sin intercalar sus acciones.

Serializacin vs concurrencia: Ejecutar concurrentemente varias transacciones aumenta la utilizacin del procesador y del disco y reduce el tiempo medio de respuesta

La condicin suficiente para que un plan sea serializable es que pueda ser transformado mediante permutacin de sus acciones en un plan en serie.

Ejemplo de planificaciEjemplo de planificacinn Sea T1 la transferencia de $50 desde A a B, y T2 la transferencia del 10% del saldo desde A a B.

P1. secuencial P2. secuencial

tiempo

Ejemplo de planificaciEjemplo de planificacin n (y 2)(y 2) Sea T1 la transferencia de $50 desde A a B, y T2 la transferencia del 10% del saldo desde A a B.

P4. concurrente pero NO PRESERVA la consistencia

P3. planificacin concurrente, pero presenta conflicto de secuencialidad

SecuencialidadSecuencialidad en cuanto a en cuanto a conflictosconflictos

Se tienen en cuenta dos tipos de operaciones: lecturas y escrituras, aunque tambin se ven implicadas las operaciones de insercin y borrado.

Entonces, se puede decir que dos acciones de distintas transacciones:

a) sobre diferentes elementos siempre son permutables,

b) sobre el mismo elemento Q: 1. Ti:leer(Q) y Tj:leer(Q) son permutables, 2. Ti:leer(Q) y Tj:escribir(Q) son dos acciones no

permutables. Tambin la contraria, Ti:escribir(Q), Tj:leer(Q) 3. Ti:escribir(Q) y Tj:escribir(Q) son dos acciones no

permutables. Por lo tanto, cuando Ti lea el elemento antes de que Tj lo escriba, Ti precede a Tj, y viceversa.

Ejemplo: plan no Ejemplo: plan no serializableserializable Grafos de precedencia: permite definir una relacin de precedencia entre transacciones.

Se dice que la transaccin Ti precede a la transaccin Tj en un plan si existen dos acciones no permutables ai y aj tales que ai se ejecuta en Ti antes de que aj sea ejecutada en Tj. La condicin suficiente para que el plan sea serializable es que el grafo de precedencia asociado no contenga ciclos.

Planificaciones recuperablesPlanificaciones recuperables Si una transaccin Tj lee un elemento de datos previamente escrito por una transaccin Ti, y la operacin comprometer de Tjaparece antes que la operacin comprometer de Ti, entonces si aborta Ti, Tj sera no recuperable.

Si T9 se compromete inmediatamente despus de la lectura y T8 aborta, T9 habra ledo (y posiblemente mostrado al usuario) un estado inconsistente de la base de datos.

Por tanto, la base de datos debe asegurar que las planificaciones son recuperables.

PlanificaciPlanificacin sin cascadan sin cascada Incluso si una planificacin es recuperable, pudiera darse el caso de tener que realizar un rollback en cascada, si fallara Ti.

Sucede cuando hay transacciones posteriores que han ledo Ti sin estar sta comprometida.

Supone un alto costepor lo que hay que evitarlo.

Control de concurrenciaControl de concurrencia

Se requieren planificaciones secuenciales en cuanto a conflictos y sin cascada para garantizar el aislamiento.

Esquemas de control de concurrencia -Mecanismos para conseguir aislamiento Basados en bloqueo Basados en marcas temporales Basados en validacin

EjercicioEjercicioEs secuenciable en cuanto a conflictos esta planificacin?

EjercicioEjercicio Esta planificacin es secuenciablefrente a conflictos?

T5 T1 T3 T2 T4

Si es secuenciable

EjercicioEjercicio

T1:

leer(A)Leer(B)If A=0 then B=B+1Escribir(B)

T2:

leer(A)Leer(B)If B=0 then A=A+1Escribir(A)

Requisito de consistencia A o B = 0Valores iniciales A=B=0

a) Demostrar que la ejecucin secuencial conserva la consistencia

b) Mustrese una ejecucin concurrente de T1 y T2 no secuencial

c) existe ejecucin concurrente que produzca una planificacin secuenciable?

Control de Control de concurrenciaconcurrencia

Marta ZorrillaMarta Zorrilla


Problemas de concurrenciaProblemas de concurrencia

Actualizacin perdida

--

Write Q-t4

--

-Write Qt3

--

Read Q-t2

--

-Read Qt1

--

Trans.#2Trans.#1Tiempo

Lectura no confirmada

Rollback-t3

--

-Read Qt2

--

Write Q-t1

--


Rollback-t3

--

-Write Qt2

--

Write Q-t1

--


Escritura no confirmada

Problemas de concurrenciaProblemas de concurrencia

C=30B=50A=40

-Leer CWrite A+B+C

T8T9

Commit-T7

Write A + 10-T6

Leer A-T5

Write C-10-T4

Leer C-T3

-Leer BT2

-Leer AT1

--


Inconsistencia

Trans.#1: A +B +C

Trans. #2: C -10 A + 10

A+B+C = 110 y no 120, la escritura est confirmada

BloqueoBloqueo Objetivo: Asegurar la secuencialidad retrasando las ejecucin de acciones que pueden provocar conflictos.

Modos de bloqueo: Compartido:

Para realizar lecturas del elemento Q. bloquear_C (Q)

Exclusivo: Para realizar lecturas y escrituras del elemento Q. bloquear_X (Q)

Las transacciones solicitan bloqueos y es el control de la concurrencia el que los concede. Posteriormente las transacciones deben desbloquear el elemento (desbloquear(Q)).

Bloqueo (y 2)Bloqueo (y 2) Compatibilidad de modos de bloqueo

Si hay incompatibilidad ante una peticin de bloqueo se debe esperar a que terminen todos los bloqueos incompatibles

La transaccin no ejecuta ninguna otra accin hasta que no se le conceda el bloqueo inanicin

FalsoFalsoExclusivo

FalsoCiertoCompartido

ExclusivoCompartido

Ejemplo bloqueosEjemplo bloqueos//T1: transferir 100 de B a AT1:

Bloquear_X(B);Leer(B);B := B 100;Escribir (B);Desbloquear (B);Bloquear_X(A);Leer(A);A:=A+100;Escribir (A);Desbloquear (A);

/* T2: visualizar el total A+B*/T2:

Bloquear_C(A);Leer(A);Desbloquear (A);Bloquear_C(B);Leer(B);Desbloquear (B);visualizar (A+B);

Si la ejecucin es secuencial (T1 T2 o T2 T1) siendo A=100 y B=200, el resultado es 300

Ejemplo de mal uso de Ejemplo de mal uso de bloqueosbloqueos

A=100B=200

Si T1 y T2 se ejecutaran en serie A+B=300

Pero con este esquema de bloqueos al finalizar T2: A+B= 200

Bloqueo en dos fasesBloqueo en dos fases Para que los algoritmos de bloqueo funcionen, todas las transacciones se han de ejecutar siguiendo el protocolo de bloqueo de las dos fases. Este protocolo consiste en que:

Fase de crecimiento: una transaccin puede obtener bloqueos pero no puede liberarlos.

Fase de decrecimiento: una transaccin puede liberar bloqueos pero no puede obtener ninguno nuevo.

Todo plan de ejecucin para un conjunto de transacciones que cumplen el protocolo de bloqueo de las dos fases es serializable.

Sin embargo, en algunos casos el nivel de concurrencia disminuye las transacciones no liberan los elementos hasta que terminan de ejecutarse

Problema de Problema de interbloqueointerbloqueo Una situacin de interbloqueo surge cuando un grupo de transacciones satisface las siguientes propiedades: Toda transaccin del grupo est detenida y esperando por un elemento.

La finalizacin de una transaccin que no pertenece al grupo no permite a ninguna transaccin del grupo conseguir el bloqueo del elemento por el que espera.

Ni T3 ni T4 pueden progresar rollback

SoluciSolucin al n al interbloqueointerbloqueo

Si el algoritmo de concurrencia no impide el interbloqueo, peridicamente se ha de examinar las peticiones de reserva para detectar interbloqueos.Se reconocen por la aparicin de ciclos en grafos de espera. Con qu periodicidad? Seleccin de la transaccin a abortar

Otros algoritmos establecen un tiempo de espera mximo, de tal forma que si una transaccin sobrepasa ese tiempo de espera se supone que ha entrado en un interbloqueo y es abortada. qu tiempo? Esperas largas producen retraso y cortas, abortos incluso cuando no se produce interbloqueo.

Otros hacen que cada transaccin pida todas sus reservas de una vez y el gestor de concurrencia se las concede todas o ninguna. De esta forma el nivel de concurrencia baja ms.

Otras variantes de bloqueo Otras variantes de bloqueo en dos fasesen dos fases

El bloqueo estricto en dos fases, esto es, la transaccin debe tener todos los bloqueos en modo exclusivo hasta que se complete. Menos concurrencia Evita rollback en cascada

El bloqueo riguroso en dos fases con conversiones de bloqueo. Se puede cambiar un bloqueo compartido por uno exclusivo (subir) y viceversa, pero la subida slo se puede realizar en la fase de crecimiento y la bajada en la de decrecimiento.

Cuando Ti realiza una operacin leer(Q), el sistema genera una instruccin bloquear-C(Q) seguida de la operacin leer(Q)

Cuando Ti realiza una operacin escribir(Q), el sistema comprueba si Ti posee bloqueo compartido, si es as, genera instruccin subir(Q) seguida de escribir(Q). En otro caso, genera instruccin bloquear-X(Q) seguida de escribir(Q)

Todos los bloqueos que obtenga una transaccin no se desbloquean hasta que dicha transaccin se comprometa o aborte (sin cascada).

Ejemplo para mostrar Ejemplo para mostrar conversiconversin de bloqueo n de bloqueo T1: Bloquear_X(a1);

Leer(a1);

Bloquear_C(a2);

Leer(a2);

.

Bloquear_C (an);

Leer (an);

Escribir (a1);

Desbloquear (a1);

Desbloquear (a2);

Desbloquear (an);

T2:Bloquear_C(a1);Leer(a1);Bloquear_C(a2);Leer(a2);visualizar (a1+b1);Desbloquear (a1);Desbloquear (a2);

Como a1 requiere bloqueo exclusivo, la ejecucin de T1 y T2 debe ser secuencial utilizando bloqueo en dos fases.

Ejemplo con conversiEjemplo con conversin n T1: Bloquear_C(a1);Leer(a1);

Bloquear_C(a2);Leer(a2);.

Bloquear_C (an);Leer (an);

Subir (a1);Escribir (a1);

Desbloquear (a1);Desbloquear (a2);Desbloquear (an);

T2:

Bloquear_C(a1);Leer(a1);

Bloquear_C(a2);Leer(a2);visualizar (a2+a1);Desbloquear (a1);Desbloquear (a2);

Con conversiones de bloqueo se consigue mayor concurrencia

Marcas temporalesMarcas temporales Se asocia a cada Ti un valor temporal secuencial (reloj del sistema, contador). Si Ti es anterior a Tj, entonces MT(Ti)

Marcas temporales (y 2)Marcas temporales (y 2)Ti ejecuta leer(Q)a. Si MT(Ti) < E-mt(Q) ERROR.

Una Tj posterior a Ti escribi Q antes de que fuera ledo por Ti. Hay que retroceder Ti.

b. Si MT(Ti) > E-mt(Q) CORRECTO leer (Q) actualizar L-mt(Q) con el mximo de ( L-mt(Q) , MT(Ti) )

Ti ejecuta escribir(Q)a. Si MT(Ti) < L-mt(Q) ERROR:

Una Tj posterior a Ti ley Q antes de que fuera escrito por Ti. Hay que retroceder Ti.

b. Si MT(Ti) < E-mt(Q) ERROR Ti intenta escribir un valor obsoleto de Q Hay que retroceder Ti.

c. En otro caso CORRECTO escribir (Q) actualizar E-mt(Q) con MT(Ti)

EjemploEjemplo

Si MT(T14) < MT(T15)

La planificacin que se presenta s es correcta

Protocolo basado en marcas temporales: Se asegura la secuencialidad en cuanto a conflictos Se asegura la ausencia de interbloqueos Puede generar planificaciones no recuperables aunque se pueden evitar con una extensin del mtodo.

Algoritmos optimistas o Algoritmos optimistas o basados en validacibasados en validacinn

Se basan en la idea de que los problemas de concurrencia van a aparecer en muy pocas ocasiones.

Es cierto en bases de datos en las que se realizan solamente operaciones de consulta, siendo las operaciones de escritura muy escasas.

Consiste en hacer que las transacciones preparen todas sus modificaciones en un buffer con anterioridad a modificar la base de datos. Una vez las transacciones han terminado y antes de modificar la base de datos, se ejecuta una validacin que comprueba la secuencialidad de las operaciones realizadas en el buffer (p. ej. con marcas temporales). En caso de que la validacin falle, las transacciones sern abortadas y ejecutadas de nuevo con otro plan.

Posibilidad de inanicin de transacciones largas, pero no se producen rollback en cascada ya que se escribe despus de validar.

ProtocoloProtocolo basadobasado en en validacivalidacinn

Cada transaccin Ti tiene 3 marcas temporales Inicio(Ti) : el tiempo Ti en el cual comienza la transaccin

Validacin(Ti): el tiempo Ti en el cual comienza la fase de validacin

Fin (Ti) : el tiempo Ti en el cual termina la fase de escritura

El orden de secuencialidad de las transacciones se determina por la marca temporal de validacin

ComprobaciComprobacin de validacin de validacin n de de TTjj

Para toda Ti con MT (Ti) < MT (Tj) se debe cumplir una de las dos condiciones siguientes:

fin (Ti) < inicio(Tj)

inicio(Tj) < fin (Ti) < validacin(Tj) y el conjunto de datos escritos por Ti no tiene interseccin por los ledos por Tj.

entonces Tj puede ser confirmada. En otro caso, la validacin falla y Tj es abortada.

PlanificaciPlanificacinn porpor validacivalidacinnT14 T15

leer(B)leer(B)B:- B-50leer(A)A:- A+50

leer(A)(validar)mostrar (A+B)

(validar)escribir (B)escribir (A)

fin (T14) < inicio(T15)

inicio(T15) < fin (T14) < validacin(T15)

GRANURALIDAD MGRANURALIDAD MLTIPLELTIPLE

La idea es manejar elementos de informacin de distinto tamao, no nicamente datos individuales (la base de datos, unas tablas, una nica tabla, registros, etc.)

Se necesita definir mltiples niveles de granuralidad (se puede representar como un rbol).

Los bloqueos se realizan sobre nodos del rbol.

Se agiliza el mecanismo de peticin de bloqueos. No es necesario bloquear explcitamente cada nodo descendiente del elemento al que se quiere acceder (ya sea en modo C o X).

Permite concurrencia y reduce sobrecarga de bloqueos. til en aplicaciones en las que se mezclan transacciones cortas que acceden a algunos datos con otras largas que producen informes a partir de un archivo completo

JerarquJerarqua de a de granularidadgranularidad

ESQUEMAS MULTIVERSIN

La idea es que cada operacin de escribir(Q) crea una versin (Qi) y cuando se realiza una operacin leer(Q), el gestor elige una versin de Q que garantice la secuencialidad.

Una alternativa es utilizar marcas temporales con estructuras del tipo:Qi= (Contenido del elemento Q, E-mt(Q), L-mt(Q)) Se borran las versiones cuando su marca temporal es anterior a cualquiera de las marcas temporales de las transacciones activas

Problemas: la lectura requiere actualizar L-mt(Q) ms accesos a disco Los conflictos entre transacciones se resuelven con retrocesos y no con esperas. Ms costoso.

Operaciones de insertar y Operaciones de insertar y borrarborrar

Sean las transacciones Ti y Tj y Ti incluye una operacin borrari(Q). Sea opj(Q) una operacin realizada por Tj en Q, donde op = lectura, escritura, borrado o insercin. (

Operaciones de insertar y Operaciones de insertar y borrarborrar(cont.)(cont.)

Si se utiliza bloqueo en dos fases: Una operacin de borrar requiere bloqueo exclusivo Una operacin de insertar, requiere bloqueo exclusivo para la tupla que inserta

Si se utiliza marcas temporales: MT(ti) debe ser posterior a E(Q) y L(Q) para borrar Y al insertar, se actualizar E(Q) y L(Q) a MT(ti)

Se puede producir el fenmeno fantasma. Una transaccin (e.j., sumar los saldos de las cuentas de las sucursales de Santander) y una transaccin que inserta una tupla en la relacin (e.j., insertar una nueva cuenta en sucursal de Santander) puede ocurrir conflicto a pesar de no tener tuplas en comn

Si slo se bloquean las tuplas que se ven afectadas por la transaccin, se pueden producir planificaciones no serializables; por eso hay que evitar que se puedan realizar acciones sobre la relacin afectada bloqueo de elemento de datos o bloqueo de ndice.

Transacciones en SQLTransacciones en SQL El lenguaje de manipulacin de datos incluye una construccin para especificar el conjunto de acciones que comprometen una transaccin.

En SQL, una transaccin empieza implcitamente.

Una transaccin en SQL termina por: Commit work compromete la transaccin actual y empieza una nueva. Rollback work origina el aborto de la transaccin actual.

Niveles de consistencia especificados por SQL-92: Secuenciable por defecto (serializable) Lectura repetible (repeatable read) Con compromiso de lectura (read commited) Sin compromiso de lectura (read uncommited)

Niveles de aislamiento SQLNiveles de aislamiento SQL--9292 Secuenciable no se permiten lecturas sucias, ni lecturas no repetibles, ni fantasmas.

Lectura repetible slo se pueden leer los registros comprometidos, repetidas lecturas del mismo registro en una transaccin deben devolver el mismo valor. No permite que otra transaccin actualice el registro.

Con compromiso de lectura slo se pueden leer los registros comprometidos, pero lecturas sucesivas del registro pueden devolver valores diferentes.

Sin compromiso de lectura se pueden leer incluso registros no comprometidos.

Problemas de concurrenciaProblemas de concurrencia Lectura sucia (dirty read): T1 puede leer una actualizacin de T2 an no confirmada y si T2 falla y se aborta, T1 ley un valor que no existe.

Lectura no repetible (nonrepeatable read): T1 puede leer un valor D que posteriormente actualiza T2. Si T1 vuelve a leer el valor de D lo encuentra cambiado.

Fantasmas (phantoms) - T1 puede leer una tabla en la que posteriormente T2 inserta una fila. Si T1 vuelve a leer la tablaaparece una fila nueva: un fantasma.

EjercicioEjercicio Determinar si el algoritmo de ordenacin por marca de tiempo permite su ejecucin

RecuperaciRecuperacinnMarta ZorrillaMarta Zorrilla


CLASIFICACIN DE FALLOS

Fallo en la transaccin: Error lgico (del programa): la transaccin no puede continuar por alguna condicin interna como acceso a informacin que no existe, entradas errneas, overflow, etc.

Error del sistema: la transaccin no puede continuar, p. ej. interbloqueos, aunque entrar a ejecutarse ms tarde.

Cada del sistema: Fallo hardware (alimentacin), o software (del SGDB, del SO). Se pierde informacin voltil.

Fallo de disco: Por ejemplo, un bloque que no se puede leer o transferir. Se pierde informacin no voltil.

RecuperaciRecuperacinn Los algoritmos de recuperacin aseguran la consistencia y atomicidad de las transacciones aunque se produzcan fallos. Es necesario: Guardar informacin durante el proceso normal para poder realizar una recuperacin

Realizar la recuperacin en caso de fallo

Medios Copias de seguridad (back-up).

Peridicamente se deben hacer copias y guardarlas en lugar seguro. Generalmente en cinta y almacn ignfugo

Registro histrico (log). Para restaurar la base de datos desde su ltimo backup hasta ltima situacin estable antes del fallo.

El log se almacena en un disco externo y, por lo tanto, no se pierde a no ser que el fallo sea catastrfico.

AccesoAcceso a los a los datosdatos Las transacciones llevan informacin del disco a la memoria principal y de ah al disco.

Cada Ti, crea un rea de trabajo privada en la cual guarda copia de todos los elementos que ha accedido y actualizado. Usa las operaciones: read(X) asigna el valor del elemento de datos X a la variable local xi. write(X) asigna el valor de la variable local xi al elemento de datos X en el buffer.

Ambas operaciones pueden requerir la lectura de disco a memoria (input(BX).

Transacciones Ejecutan read(X), acceden a X por primera vez Los accesos siguiente se hacen en memoria. Despus del ltimo acceso, write(X). output(BX) no va necesariamente despus de write(X). Puede que an haya datos sobre los que se est accediendo. si se produce un fallo entre ambas operaciones, se pierden los datos.

EjemploEjemplo de de accesoacceso a a datosdatos

x

Y AB

x1y1

bufferBuffer Block A

Buffer Block B

input(A)

output(B)

read(X) write(Y)

disk

work areaof T1

work areaof T2

memory

x2

Fichero de Fichero de loglog Modificacin diferida:

Una transaccin no escribe nada en la base de datos hasta que se ha confirmado.

Una transaccin no se ha confirmado hasta que no haya registrado todos sus cambios en el LOG

Modificacin inmediata Se escribe en la base de datos y en log al tiempo

Informacin que anota : Indica que la transaccin Ti ha comenzado a ejecutarse.

: Indica que la transaccin Ti ha actualizado el valor del elemento Xj con valor V2 y anteriormente tena V1.

: Indica que la transaccin Ti ha ledo el valor V del elemento X.

: Indica que la transaccin T ha terminado con xito y ha anotado todos sus cambios en el log.

: Indica que la ejecucin de la transaccin Ti ha fallado y ha sido abortada.

Ejemplo diferidaEjemplo diferida

T0: read (A)A: A - 50write (A)read (B)B: B + 50write (B)

T1 : read (C)C:C- 100write (C)

Fichero de LOG en tres instantes de tiempo

A=1000, B=2000 y C=700

Ejemplo inmediataEjemplo inmediata

T0: read (A)A: A - 50write (A)read (B)B: B + 50write (B)

T1 : read (C)C: C- 100write (C)

Fichero de LOG en tres instantes de tiempo

CheckpointCheckpoint Problemas en el procedimiento de recuperacin:

1. Bsqueda en el fichero log consume mucho tiempo2. La mayora de las transacciones que deben rehacerse de

acuerdo con el algoritmo ya tienen escritas sus actualizaciones en la base de datos.

Puntos de revisin (checkpoints)1. Salida a disco de todos los registros en memoria 2. Salida a disco de todos los bloques de memoria

modificados.3. Escribir en LOG y forzar su grabacin a

disco

Mientras se produce checkpoint no se permiten transacciones de actualizacin (escribir en bloque de memoria intermedia o escribir en fichero de log)

Checkpoints (Cont.)Checkpoints (Cont.)

Durante la recuperacin slo se tienen en cuenta las Tique empezaron antes del checkpoint y las Ti que comenzaron despus. 1. Se recorre el log hacia atrs hasta encontrar el

ms reciente 2. Se continua hacia atrs hasta encontrar . 3. Lo anotado en el log anteriormente se ignora y puede

eliminarse cuando se desee.4. Para todas las transacciones (empezando en Ti o posteriores)

con no , se ejecuta undo(Ti). (para loginmediato)

5. Se recorre hacia adelante el log, para todas las Ti con un , se ejecuta redo(Ti).

Ejemplo de Ejemplo de CheckpointsCheckpoints

T1 puede ignorarse T2 y T3 rehacer. T4 deshacer

Tiempoc TiempofT1

T2T3

T4

checkpoint Fallo del sistema

RecuperaciRecuperacin de una BDn de una BD El proceso de recuperacin consiste en deshacer todos los cambios realizados por transacciones abortadas y rehacer todas las comprometidas.

Dos propiedades deseables en todo planificador que van a ayudar a garantizar la integridad de los datos: Planes de ejecucin recuperables. Despus de un aborto siempre se debe recuperar un estado consistente de la base de datos. Se dice que un plan es recuperable cuando para todo par de transacciones Ti y Tj tales que Tj lee los previamente escritos por Ti, la transaccin Ti siempre termina antes que Tj.

Planes de ejecucin sin cascadas. Para evitar la necesidad de abortar una cascada de transacciones, los planes tienen que cumplir la siguiente condicin. Para todo par de transacciones Ti y Tj tales que Tj lee los datos previamente escritos por Ti, la transaccin Ti siempre termina antes que Tjlea los datos.

El El proceso de recuperacide recuperacin n

Si hay daos extensos en una porcin considerable de la base de datos back-up y aplicar las acciones de las transacciones confirmadas anotadas en el fichero de loghasta el momento del fallo. En este caso siempre se necesita la supervisin del administrador de la base de datos.

Cuando la base de datos no presenta daos fsicos pero se ha vuelto inconsistente deshacer los cambios que provocaron la inconsistencia consultando las entradas del fichero de log. Puede ser que la recuperacin se pueda hacer automticamente, sin intervencin del administrador.

EjercicioEjercicioA=2, B=16, W=5, X=10, Y=20

Escribe B10

B: B*59

Lee BEscribir Y8

Escribe AY: Y-W7

A: A*5Leer Y6

Escribir X5

Leer AX: X+W4

Leer XEscribir A3

Leer WA: A*22

Leer A 1

T3T2T1T

T3 commit

T3, B, 16, 90

T2 commit

T2, Y, 20, 15

T3, A, 4, 20

T2, X, 10, 15

T3 start

T1 commit

T1, A, 2 ,4

T2 start

T1 start

Anotaciones en log inmediato

Optimizando el cOptimizando el cdigo digo transaccionaltransaccional

Ejecutar transacciones lo ms cortas posibles

Limitar transacciones a operaciones de modificacin siempre que no se re-lean datos en la misma transaccin

Usar niveles de aislamiento bajos siempre que sea posible

Reducir al mnimo imprescindible los datos a modificar en una transaccin

Ejercicio de Ejercicio de CheckpointsCheckpoints

T1 y T2 puede ignorarse T3,T4 y T5 rehacer. T5 deshacer

Tiempoc TiempofT1

T3T4

T6

checkpoint Fallo del sistema

T2

T5

Gestión de Transacciones DB

Documents

Transcript of Gestión de Transacciones DB