TRANSACCIN

Es una unidad lgica de trabajo que incluye una secuencia de operaciones de acceso a la b.d. Mediante la cual un estado consistente de la b.d. Se transforma en otro estado consistente, la transaccin se lleva a cabo en su totalidad, o se cancela en su totalidad.

EL GESTOR DE RECUPERACIN SE MANTIENE AL TANTO DE LAS SIGUIENTES OPERACIONES

INICIO_DE_TRANSACCION LEER O ESCRIBIR FIN_DE_TRANSACCION CONFIRMAR_TRANSACCION (COMMIT) REVERTIR (ABORTAR) (ROLLBACK)

Algunas Tcnicas de recuperacin requieren operaciones adicionales :

DESHACER (UNDO) REHACER (REDO)

DIAGRAMA DE TRANSICIN DE ESTADOS PARA LA EJECUCIN DE TRANSACCIONES.

PROPIEDADES DE LAS TRANSACCIONES (ACID)

1.- Atomicidad. Una transaccin es una unidad atmica de procesamiento o bien se realiza por completo o no se realiza en absoluto. 2.- Consistencia. Una ejecucin correcta de la transaccin debe llevar a la b.d de un estado consistente a otro consistente. 3.- Aislamiento. Una transaccin no debe dejar que otras transacciones puedan ver sus actualizaciones antes de que sea confirmada. 4.- Durabilidad (o Permanencia). Una vez que una transaccin ha modificado la b.d. Y las modificaciones se han confirmado, estas nunca deben perderse por un fallo subsecuente.

BITCORA DEL SISTEMA

Es un archivo que mantiene todas la operaciones de transacciones que afectan los valores de los elementos de la base de datos. TIPOS DE ENTRADAS QUE SE ESCRIBEN EN LA BITCORA : T: identificacin nica de la transaccin dada por el sistema 1.- [inicio_de_transaccin, T] 2.- [escribir_elemento, T, X, valor_anterior, valor_nuevo] 3.- [leer_elemento, T, X] 4.- [confirmar, T] 5.- [abortar, T] Los protocolos de recuperacin que evitan la reversin en cascada no requieren que la operacin LEER se asiente en la bitcora.

PUNTOS DE CONTROL EN LA BITCORA

Otro tipo de control en la bitcora es el llamado punto de control (check point). Un registro [punto_ de_control] se escribe en la bitcora peridicamente. Acciones para asentar un punto de control: 1.- Suspender temporalmente la ejecucin de la transacciones. 2.- Forzar la escritura de todas las operaciones de actualizacin de las transacciones confirmadas (de los buffers de datos al disco). 3.- Escribir un registro [punto_de_control] en la bitcora y forzar la escritura de la bitcora en el disco (de los buffers de bitcora al disco). 4.- Reanudar la ejecucin de las transacciones

EJEMPLO DE RECUPERACIN EN EL CASO DE UNA CADA DEL SISTEMA.

TIPOS DE FALLOS

Un fallo de computador (cada del sistema). Un error de la transaccin o del sistema. Errores locales o condiciones de excepcin. Imposicin del control de concurrencia. Fallo del disco. Problemas y catstrofes fsicos.

TCNICAS DE RECUPERACIN ANTE FALLAS LEVES

ACTUALIZACIN DIFERIDA (algoritmo NO DESHACER/REHACER). ACTUALIZACIN INMEDIATA algoritmo DESHACER/NO REHACER algoritmo DESHACER/REHACER. PAGINACIN DE SOMBRA algoritmo NO DESHACER/NO REHACER

PAGINACIN DE SOMBRA.

RECUPERACIN EN TRANSACCIONES DE MULTIPLES BASES DE DATOS PROTOCOLO DE CONFIRMACIN DE DOS FASES

Para mantener la atomicidad de una transaccin de multibases de datos, es necesario contar con un mecanismo de recuperacin de dos niveles. Se requiere de un GESTOR DE RECUPERACIN GLOBAL o COORDINADOR, adems de los gestores de recuperacin locales.

PROTOCOLO DE CONFIRMACIN DE DOS FASES

FASE 1: Cuando todas las bases de datos participantes le indican al coordinador que la parte en la que intervienen cada una ha concluido, el coordinador enva el mensaje PREPRESE A CONFIRMAR a cada participante. Cada una de las bases de datos que reciben ese mensaje forzar la escritura de todos los registros de la bitcora local en disco y despus enviara una seal de CORRECTO (OK) al coordinador. Si falla la escritura forzada de la bitcora a disco o la transaccin local no puede confirmarse por alguna razn, la base de datos enva una seal de INCORRECTO (NOT OK) al coordinador. Si el coordinador no recibe una respuesta de una base de datos dentro de un cierto intervalo de tiempo, supone que la respuesta es INCORRECTO.

PROTOCOLO DE CONFIRMACIN DE DOS FASES

FASE 2: Segn la respuesta de las bases de datos participantes, el coordinador escribe un registro de decisin en la bitcora global (de confirmar o revertir). Si todas las bases de datos participantes contestan correcto, la transaccin tiene xito y el coordinador enva una seal de CONFIRMAR para esa transaccin. Cada base de datos participante completa la confirmacin de la transaccin escribiendo en la bitcora local una entrada [CONFIRMAR] para esa transaccin y actualizando la base de datos si es necesario. Si una o ms bases de datos respondieron incorrecto al coordinador, la transaccin habr fallado y el coordinador enviar a cada participante una seal de REVERTIR o deshacer el efecto local de la transaccin.

PLAN (O HISTORIA) DE TRANSACCIONES

Cuando varias transacciones se ejecutan de manera concurrente e intercalada, el orden de ejecucin de sus operaciones constituye lo que se conoce como PLAN de transacciones. DEFINICIN.- Un Plan P de n transacciones T1 , T2 , ..., Tn es un ordenamiento para las operaciones de las transacciones sujeto a la restriccin de que, para cada transaccin Ti que participe en P, las operaciones Ti en P deben aparecer en el mismo orden en que ocurren en Ti . Sin embargo las operaciones de otras transacciones Tj se pueden intercalar con las operaciones de Ti en P. (Para fines de recuperacin y control de concurrencia, nos interesan principalmente las operaciones leer_elemento y escribir_elemento, as como las operaciones de confirmar y abortar).

PLAN (O HISTORIA) DE TRANSACCIONES

T1 leer_elemento(X)
escribir_elemento(X) leer_elemento(Y) escribir_elemento(X) confirmar escribir_elemento(Y) confirmar Pa : l1(X); l2(X); e1(X); l1(Y); e2(X); c2 ; e1(Y); c1

T2
leer_elemento(X)

PLAN (O HISTORIA) DE TRANSACCIONES

Se dice que dos operaciones de un plan estn en conflicto si pertenecen a diferentes transacciones, si tienen acceso al mismo elemento X y si una de las dos operaciones es escribir_elemento(X). Por ejemplo, en el plan Pa las operaciones que estn en conflicto son: l1(X) y e2(X) l2(X) y e1(X) e1(X) y e2(X)

PLAN COMPLETO (DE ORDENAMIENTO TOTAL)

Se dice que un plan P de n transacciones T1 , T2 , ..., Tn es un plan completo si se cumplen las siguientes condiciones: 1. Las operaciones de P son exactamente las operaciones de T1 , T2 , ..., Tn incluidas una operacin de confirmar o abortar como ltima operacin de cada transaccin en el plan 2. Para cualquier par de operaciones de la misma transaccin Ti , su orden de aparicin en P es el mismo que su orden de aparicin en Ti. 3. Para cualesquier dos operaciones en conflicto, una de ellas debe ocurrir antes que la otra en el plan. (Puesto que toda transaccin ha sido confirmada o abortada, un plan completo nunca contendr transacciones activas).

PLAN DE ORDENAMIENTO PARCIAL

Las condiciones anteriores permiten que dos operaciones que no estn en conflicto ocurran en el plan sin definir cual lo haga primero, dando lugar a la definicin de un plan como un orden parcial de las operaciones en las n transacciones. Sin embargo, se debe especificar un orden total en el plan para cualquier par de operaciones en conflicto (condicin 3) y para cualquier par de operaciones de la misma transaccin (condicin 2). La condicin 1 nos dice simplemente que todas las operaciones deben aparecer en el plan completo.

PROYECCION CONFIRMADA DE UN PLAN C(P)

Debido a que es difcil encontrar planes completos en un sistema de procesamiento de transacciones, porque continuamente se estn introduciendo nuevas transacciones en el sistema, conviene definir el concepto de proyeccin confirmada de un plan P, que incluye slo las operaciones de P que pertenecen a transacciones confirmadas, esto es, transacciones Ti cuya operacin de confirmacin ci est en P.

CARACTERIZACIN DE PLANES CON BASE A SU RECUPERABILIDAD

Es importante caracterizar los tipos de planes en los cuales es posible la recuperacin, as como aquellos en los que la recuperacin es relativamente simple. 1. PLAN RECUPERABLE.- En un plan recuperable, ninguna transaccin confirmada tiene que revertirse jams. Un plan P es recuperable si ninguna transaccin T de P se confirma antes de haberse confirmado todas las transacciones T que han escrito un elemento que T lee. Ejemplo: Pa : l1(X); l2(X); e1(X); l1(Y); e2(X); c2 ; e1(Y); c1 es recuperable. Pc : l1(X); e1(X); l2(X); l1(Y); e2(X); c2; a1 no es recuperable.

CARACTERIZACIN DE PLANES CON BASE A SU RECUPERABILIDAD

2. PLAN QUE EVITA LA REVERSIN EN CASCADA.-

Si toda transaccin del plan slo lee elementos escritos por transacciones confirmadas. En este caso, todos los elementos ledos se confirmarn, y no ocurrir ninguna reversin en cascada que puede consumir mucho tiempo. Ej: Pc : l1(X); e1(X); l1(Y); a1; l2(X); e2(X); c2 evita la reversin en cascada

CARACTERIZACIN DE PLANES CON BASE A SU RECUPERABILIDAD

3. PLAN ESTRICTO.- Las transacciones no pueden LEER ni

ESCRIBIR un elemento X en tanto no se haya confirmado (o abortado) la ltima transaccin que escribi X. Es un plan recuperable y que evita la reversin en cascada. Los planes estrictos simplifican el proceso de recuperar las operaciones de escritura, reducindolo a una restauracin de la imagen anterior de un elemento X, que es el valor que X tena antes de la operacin de escritura abortada.

SERIABILIDAD DE LOS PLANES

Es importante caracterizar los planes en trminos de la interferencia provocada por las transacciones participantes, lo que conduce al concepto de seriabilidad y planes seriables. Un aspecto importante del control de concurrencia es la llamada TEORA DE LA SERIABILIDAD con la que se intenta determinar cules son los planes correctos y cules no, e inventar tcnicas que solo permitan planes correctos.

SERIABILIDAD DE LOS PLANES

1.

PLAN EN SERIE.- es un plan en el cual las operaciones de cada transaccin se ejecutan de manera consecutiva, sin operacin intercaladas de la otra transaccin. Son planes correctos. Ejemplo: T1, T2 o T2, T1 Un plan en serie es correcto si consideramos que las TRANSACCIONES SON INDEPENDIENTES. Toda transaccin es correcta si se ejecuta sola (propiedad de conservacin de consistencia) y que las transacciones son independientes entre s, por ello no importa cual transaccin se ejecute primero. El problema con los planes en serie es que limitan la concurrencia o la intercalacin de las operaciones, desperdicindose tiempo de CPU, si una transaccin est esperando que se complete una operacin de E/S.

SERIABILIDAD DE LOS PLANES

2. PLAN NO EN SERIE.- plan que permite la

ejecucin intercalada de las operaciones de las transacciones pero no garantiza que sean planes correctos.

3. PLAN SERIABLE.- un plan es seriable si es

equivalente a algn plan en serie de las mismas n transacciones. Son planes correctos.