UNIDAD 4 Recuperacion de Informacion en Ambientes de BDD ANTOLOGIA

REDES Y SISTEMAS DISTRIBUIDOS / Bases De Datos Distribuidas
INGENIERA EN SISTEMAS COMPUTACIONALES PGINA 1

Especialidad
Redes Y Sistemas Distribuidos

Materia
Base De Datos Distribuidas

A N T O L O G A
UNIDAD IV
Recuperacin De Informacin En Ambientes De
BDD

Profesor:
I. S. C. Juan Manuel Olgun Medina

Instituto Tecnolgico
Superior
De Xalapa

Ingeniera En Sistemas
Computacionales


UNIDAD IV

RECUPERACIN DE INFORMACIN EN
AMBIENTES DE BDD

4.1 Transacciones.
4.1.1 Estructura de transacciones
4.1.2 Ejecucin de transacciones centralizada y distribuida.
4.2 Control de concurrencia.
4.2.1 Serializacin de transacciones.
4.2.2 Algoritmos de control de concurrencia.
4.2.2.1 Basados en bloqueo.
4.2.2.2 Basados en estampas de tiempo.
4.2.2.3 Pruebas de validacin optimistas.
4.2.3 Disciplinas del Interbloqueo: prevencin, deteccin, eliminacin y
recuperacin.
4.3 Confiabilidad.
4.3.1 Conceptos bsicos de confiabilidad.
4.3.2 Protocolos REDO/UNDO.
4.3.3 Puntos de verificacin (checkpoints).
4.3.4 Protocolo 2PC de confiabilidad distribuida.



4.1 TRANSACCIONES

Una transaccin es un programa en ejecucin que constituye una unidad lgica del
procesamiento de una base de datos. Una transaccin incluye una o ms
operaciones de acceso a la base de datos (operaciones de insercin, eliminacin,
modificacin o recuperacin).

Se llama transaccin a una coleccin de operaciones que forman una nica unidad
lgica de trabajo. Un sistema de base de datos debe asegurar que la ejecucin de
las transacciones se realice adecuadamente a pesar de la existencia de fallos: o se
ejecuta la transaccin completa o no se ejecuta en absoluto. Adems debe gestionar
la ejecucin concurrente de las transacciones evitando introducir inconsistencias.

Una transaccin es una unidad de la ejecucin de un programa que accede y
posiblemente actualiza varios elementos de datos. Una transaccin se inicia por la
ejecucin de un programa de usuario escrito en un lenguaje de manipulacin de
datos de alto nivel o en un lenguaje de programacin (por ejemplo SQL, COBOL, C,
C++ o Java), y est delimitado por instrucciones (o llamadas a funcin) de la forma
inicio transaccin y fin transaccin. La transaccin consiste en todas las operaciones
que se ejecutan entre inicio transaccin y el fin transaccin.

Es necesario precisar qu se entiende por terminacin con xito de una transaccin.
Se establece por tanto un modelo simple abstracto de transaccin. Una transaccin
debe estar en uno de los estados siguientes:

Activa: El estado inicial; la transaccin permanece en este estado durante su
ejecucin.
Parcialmente Comprometida: Despus de ejecutarse la ltima instruccin.
Fallida: Tras descubrir que no puede continuar la ejecucin normal.
Abortada: Despus de haber retrocedido la transaccin y restablecido la base
de datos a su estado anterior al comienzo de la transaccin.
Comprometida: Tras
completarse con xito.



4.1.1 ESTRUCTURA DE TRANSACCIONES

Las transacciones planas consisten de una secuencia de operaciones primitivas
encerradas entre las palabras clave begin y end. Por ejemplo,

Begin_transaction Reservacin
. . .
end.

En las transacciones anidadas las operaciones de una transaccin pueden ser as
mismo transacciones. Por ejemplo,

Begin_transaction Reservacin
. . .
Begin_transaction Vuelo
. . .
end. {Vuelo}
. . .
Begin_transaction Hotel
. . .
end.
. . .
end.

Una transaccin anidada dentro de otra transaccin conserva las mismas
propiedades que la de sus padres, esto implica, que puede contener as mismo
transacciones dentro de ella. Existen restricciones obvias en una transaccin
anidada: debe empezar despus que su padre y debe terminar antes que l. Ms
an, el commit de una subtransaccin es condicional al commit de su padre, en otras
palabras, si el padre de una o varias transacciones aborta, las subtransacciones hijas
tambin sern abortadas.

Las transacciones anidadas proporcionan un nivel ms alto de concurrencia entre
transacciones. Ya que una transaccin consiste de varios transacciones, es posible
tener ms concurrencia dentro de una sola transaccin. As tambin, es posible
recuperarse de fallas de manera independiente de cada subtransaccin. Esto limita
el dao a un parte ms pequea de la transaccin, haciendo que costo de la
recuperacin sea menor.

En el segundo punto de vista se considera el orden de las lecturas y escrituras. Si las
acciones de lectura y escritura pueden ser mezcladas sin ninguna restriccin,
entonces, a este tipo de transacciones se les conoce como generales. En contraste,
si se restringe o impone que un dato deber ser ledo antes de que pueda ser escrito
entonces se tendrn transacciones restringidas. Si las transacciones son restringidas
a que todas las acciones de lectura se realicen antes de las acciones de escritura
entonces se les conoce como de dos pasos. Finalmente, existe un modelo de accin


para transacciones restringidas en donde se aplica an ms la restriccin de que
cada par <read,write> tiene que ser ejecutado de manera atmica.

4.2 CONTROL DE CONCURRENCIA

Las tcnicas de control de la concurrencia que se utilizan para garantizar la ausencia
de interferencias o la propiedad de aislamiento de las transacciones que se ejecutan
simultneamente. La mayora de estas tcnicas garantizan la serializacin de las
planificaciones, utilizando protocolos (conjuntos de reglas) que garantizan esa
serializacin. Un importante conjunto de protocolos emplea la tcnica del bloqueo de
los elementos de datos para evitar que varias transacciones accedan
concurrentemente a los elementos; algunos protocolos de bloqueo, que se utilizan en
casi todos los DBMSs comerciales. Otro conjunto de protocolos de control de la
concurrencia utilizan las marcas de tiempo. Una marca de tiempo es un identificador
nico generado por el sistema para cada transaccin. Los protocolos de control de la
concurrencia que utilizan la ordenacin de marcas de tiempo para garantizar la
serializacin. Los protocolos de control de la concurrencia multiversin, que utilizan
varias versiones de un elemento de datos. Presentamos un protocolo basado en el
concepto de validacin o certificacin de una transaccin despus de que haya
ejecutado sus operaciones; estos protocolos se denominan a veces protocolos
optimistas.

Otro factor que afecta al control de la concurrencia es la granularidad de los
elementos de datos (es decir, qu porcin de la base de datos es representada por
un elemento de datos). Un elemento puede ser tan pequeo como el valor de un
atributo (campo) o tan grande como un bloque de disco, o incluso un fichero entero o
la base de datos enteran.

Algunas de las principales tcnicas que se utilizan para controlar la ejecucin
concurrente de transacciones estn basadas en el concepto de bloqueo de
elementos de datos. Un bloqueo es una variable asociada a un elemento de datos
que describe el estado de ese elemento respecto a las posibles operaciones que se
le puedan aplicar. Generalmente, hay un bloqueo por cada elemento de datos de la
base de datos. Los bloqueos se utilizan como un medio para sincronizar el acceso de
las transacciones concurrentes a los elementos de la base de datos.

4.2.1 SERIALIZACIN DE TRANSACCIONES

TEORA DE LA SERIABILIDAD
Una calendarizacin (schedule), tambin llamado una historia, se define sobre un
conjunto de transacciones T = { T1, T2, ..., Tn } y especifica un orden entrelazado de
la ejecucin de las operaciones de las transacciones. La calendarizacin puede ser
especificada como un orden parcial sobre T.



Ejemplo: Considere las siguientes tres transacciones:
T1: Read( x ) T2: Write( x ) T3: Read( x )
Write( x ) Write( y ) Read( y )

Commit Read( z ) Read( z )
Commit Commit

Una calendarizacin de las acciones de las tres transacciones anteriores puede ser:
H1 = { W2(x), R1(x), R3(x), W1(x), C1, W2(y), R3(y), R2(z), C2, R3(z), C3 }

Dos operaciones Oij(x) y Okl(x) (i y k no necesariamente distintos) que accedan el
mismo dato de la base de datos x se dice que estn en conflicto si al menos una de
ellas es una escritura. De esta manera, las operaciones de lectura no tienen
conflictos consigo mismas. Por tanto, existen dos tipos de conflictos read-write (o
write-read) y writewrite. Las dos operaciones en conflicto pueden pertenecer a la
misma transaccin o a transacciones diferentes.

SERIABILIDAD EN SMBD DISTRIBUIDOS
En bases de datos distribuidas es necesario considerar dos tipos de historia para
poder generar calendarizaciones serializables: la calendarizacin de la ejecucin de
transacciones en un nodo conocido como calendarizacin local y la calendarizacin
global de las transacciones en el sistema. Para que las transacciones globales sean
serializables se deben satisfacer las siguientes condiciones: cada historia local debe
ser serializable, y dos operaciones en conflicto deben estar en el mismo orden
relativo en todas las historias locales donde las operaciones aparecen juntas.

La segunda condicin simplemente asegura que el orden de serializacin sea el
mismo en todos los nodos en donde las transacciones en conflicto se ejecutan
juntas.

Ejemplo: Considere las siguientes transacciones:
T1: Read( x ) T2: Read( x )
x x + 5 x x * 5
Write( x ) Write( x )
Commit Commit

Las siguientes historias locales son individualmente serializables (de hecho son
seriales),
LH1 = { R1(x), W1(x), C1, R2(x), W2(x), C2 }
LH2 = { R2(x), W2(x), C2, R1(x), W1(x), C1 }



4.2.2 ALGORITMOS DE CONTROL DE CONCURRENCIA

Los algoritmos de control de concurrencia deben sincronizar la ejecucin de
transacciones concurrentes bajo el criterio de correctitud. La consistencia entre
transacciones se garantiza mediante el aislamiento de las mismas.

El criterio de clasificacin ms comn de los algoritmos de control de concurrencia es
el tipo de primitiva de sincronizacin. Esto resulta en dos clases: aquellos algoritmos
que estn basados en acceso mutuamente exclusivo a datos compartidos
(candados) y aquellos que intentar ordenar la ejecucin de las transacciones de
acuerdo a un conjunto de reglas (protocolos).

Sin embargo, esas primitivas se pueden usar en algoritmos con dos puntos de vista
diferentes: el punto de vista pesimista que considera que muchas transacciones
tienen conflictos con otras, o el punto de vista optimista que supone que no se
presentan muchos conflictos entre transacciones.

Los algoritmos pesimistas sincronizan la ejecucin concurrente de las transacciones
en su etapa inicial de su ciclo de ejecucin. Los algoritmos optimistas retrasan la
sincronizacin de las transacciones hasta su terminacin.

El grupo de algoritmos pesimistas consiste de algoritmos basados en candados,
algoritmos basados en ordenamiento por estampas de tiempo y algoritmos hbridos.
El grupo de los algoritmos optimistas se clasifican por basados en candados y
basados en estampas de tiempo.



4.2.2.1 BASADOS EN BLOQUEO

Un bloqueo en general es cuando una accin que debe ser realizada est esperando
a un evento. Para manejar los bloqueos hay distintos acercamientos: prevencin,
deteccin, y recuperacin. Tambin es necesario considerar factores como que hay
sistemas en los que permitir un bloqueo es inaceptable y catastrfico, y sistemas en
los que la deteccin del bloqueo es demasiado costosa.

En el caso especfico de las bases de datos distribuidas usar bloqueo de recursos,
peticiones para probar, establecer o liberar bloqueos requiere mensajes entre los
manejadores de transacciones y el calendarizador. Para esto existen dos formas
bsicas:

Autnoma: Cada nodo es responsable por sus propios bloqueos de
recursos.
Una transaccin sobre un elemento con n replicas requiere 5n mensajes
Peticin del recurso
Aprobacin de la peticin
Mensaje de la transaccin
Reconocimientos de transaccin exitosa
Peticiones de liberacin de recursos

Copia Primaria: Un nodo primario es responsable para todos los
bloqueos de recursos.
Una transaccin sobre un elemento con n copias requiere 2n+3 mensajes
Una peticin del recurso
Una aprobacin de la peticin
n mensajes de la transaccin
n reconocimientos de transaccin exitosa
Una peticin de liberacin de recurso

Podemos definir que dos operaciones entran en conflicto que debe ser resuelto si
ambas acceden a la misma data, y una de ellas es de escritura y si fueron realizadas
por transacciones distintas.

4.2.2.2 BASADOS EN ESTAMPAS DE TIEMPO

A diferencia de los algoritmos basados en candados, los algoritmos basados en
estampas de tiempo no pretenden mantener la seriabilidad por exclusin mutua. En
lugar de eso, ellos seleccionan un orden de serializacin a priori y ejecutan las
transacciones de acuerdo a ellas. Para establecer este ordenamiento, el
administrador de transacciones le asigna a cada transaccin Ti una estampa de
tiempo nica ts( Ti ) cuando sta inicia. Una estampa de tiempo es un identificador
simple que sirve para identificar cada transaccin de manera nica. Otra propiedad
de las estampas de tiempo es la monoticidad, esto es, dos estampas de tiempo
generadas por el mismo administrador de transacciones deben ser monotonicamente


crecientes. As, las estampas de tiempo son valores derivados de un dominio
totalmente ordenado.

Existen varias formas en que las estampas de tiempo se pueden asignar. Un mtodo
es usar un contador global monotonicamente creciente. Sin embargo, el
mantenimiento de contadores globales es un problema en sistemas distribuidos. Por
lo tanto, es preferible que cada nodo asigne de manera autnoma las estampas de
tiempos basndose en un contador local. Para obtener la unicidad, cada nodo le
agrega al contador su propio identificador. As, la estampa de tiempo es un par de la
forma

<contador local, identificador de nodo>

Note que el identificador de nodo se agrega en la posicin menos significativa, de
manera que, ste sirve solo en el caso en que dos nodos diferentes le asignen el
mismo contador local a dos transacciones diferentes.

El administrador de transacciones asigna tambin una estampa de tiempo a todas las
operaciones solicitadas por una transaccin. Ms an, a cada elemento de datos x
se le asigna una estampa de tiempo de escritura, wts(x), y una estampa de tiempo de
lectura, rts(x); sus valores indican la estampa de tiempo ms grande para cualquier
lectura y escritura de x, respectivamente.

El ordenamiento de estampas de tiempo (TO) se realiza mediante la siguiente regla:

Regla TO: dadas dos operaciones en conflicto, Oij y Okl, perteneciendo a las
transacciones Ti y Tk, respectivamente, Oij es ejecutada antes de Okl, si y
solamente si, ts(Ti) < ts(Tk). En este caso Ti se dice ser un transaccin ms
vieja y Tk se dice ser una transaccin ms joven.


Dado este orden, un conflicto entre operaciones se puede resolver de la siguiente
forma:

for Ri(x) do begin
if ts(Ti) < wts( x ) then
reject Ri(x)
else
accept Ri(x)
rts(x) ts(Ti)
end

for Wi(x) do begin
if ts(Ti) < rts(x) and
ts(Ti) < wts(x) then
reject Wi(x)
else
accept Wi(x)
wts(x) ts(Ti)
end

La accin de rechazar una operacin, significa que la transaccin que la envi
necesita reiniciarse para obtener la estampa de tiempo ms reciente del dato e
intentar hacer nuevamente la operacin sobre el dato.

ORDENAMIENTO CONSERVADOR POR ESTAMPAS DE TIEMPO
El ordenamiento bsico por estampas de tiempo trata de ejecutar una operacin tan
pronto como se recibe una operacin. As, la ejecucin de las operaciones es
progresiva pero pueden presentar muchos reinicios de transacciones. El
ordenamiento conservador de estampas de tiempo retrasa cada operacin hasta que
exista la seguridad de que no ser reiniciada. La forma de asegurar lo anterior es
sabiendo que ninguna otra operacin con una estampa de tiempo menor puede
llegar al despachador. Un problema que se puede presentar al retrasar las
operaciones es que sto puede inducir la creacin de interbloqueos (deadlocks).

ORDENAMIENTO POR ESTAMPAS DE TIEMPO MLTIPLES
Para prevenir la formacin de interbloqueos se puede seguir la estrategia siguiente.
Al hacer una operacin de escritura, no se modifican los valores actuales sino se
crean nuevos valores. As, puede haber copias mltiples de un dato. Para crear
copias nicas se siguen las siguientes estrategias de acuerdo al tipo de operacin de
que se trate:

Una operacin de lectura Ri(x) se traduce a una operacin de lectura de x de
una sola versin encontrando la versin de x, digamos xv, tal que, ts(xv) es la
estampa de tiempo ms grande que tiene un valor menor a ts(Ti).
Una operacin de escritura Wi(x) se traduce en una sola version, Wi(xw), y es
aceptada si el despachador no ha procesado cualquier lectura Rj(xr), tal que,
ts(Ti) < ts(xr) < ts(Tj)

4.2.2.3 PRUEBAS DE VALIDACIN OPTIMISTAS

Los algoritmos de control de concurrencia discutidos antes son por naturaleza
pesimistas. En otras palabras, ellos asumen que los conflictos entre transacciones
son muy frecuentes y no permiten el acceso a un dato si existe una transaccin
conflictiva que accesa el mismo dato. As, la ejecucin de cualquier operacin de una
transaccin sigue la secuencia de fases: validacin (V), lectura (R), cmputo (C) y


escritura (W). Los algoritmos optimistas, por otra parte, retrasan la fase de validacin
justo antes de la fase de escritura. De esta manera, una operacin sometida a un
despachador optimista nunca es retrasada.

Las operaciones de lectura, cmputo y escrita de cada transaccin se procesan
libremente sin actualizar la base de datos corriente. Cada transaccin inicialmente
hace sus cambios en copias locales de los datos. La fase de validacin consiste en
verificar si esas actualizaciones conservan la consistencia de la base de datos. Si la
respuesta es positiva, los cambios se hacen globales (escritos en la base de datos
corriente). De otra manera, la transaccin es abortada y tiene que reiniciar.

Los mecanismos optimistas para control de concurrencia fueron propuestos
originalmente con el uso de estampas de tiempo. Sin embargo, en este tipo de
mecanismos las estampas de tiempo se asocian nicamente con las transacciones,
no con los datos. Ms an, las estampas de tiempo no se asignan al inicio de una
transaccin sino justamente al inicio de su fase de validacin. Esto se debe a que las
estampas se requieren nicamente durante la fase de validacin.

Cada transaccin Ti se subdivide en varias subtransacciones, cada una de las cuales
se puede ejecutar en nodos diferentes. Sea Tij una subtransaccin de Ti que se
ejecuta en el nodo j. Supongamos que las transacciones se ejecutan de manera
independiente y ellas alcanzan el fin de sus fases de lectura. A todas las
subtransacciones se les asigna una estampa de tiempo al final de su fase de lectura.
Durante la fase de validacin se realiza una prueba de validacin, si una transaccin
falla, todas las transacciones se rechazan.

La prueba de validacin se realiza con una de las siguientes reglas:


1) Si todas las transacciones Tk, tales que, ts( Tk ) < ts( Tij ), han terminado su
fase de escritura antes que Tij ha iniciado su fase de lectura entonces la
validacin tiene xito. En este caso la ejecucin de las transacciones es
completamente serial como se muestra en la (a).

2) Si existe alguna transaccin Tk, tal que, ts( Tk ) < ts( Tij ) y la cual completa su
fase de escritura mientras Tij est en su fase de lectura, entonces, la
validacin tiene xito si WS(Tk ) RS(Tij ) = . En este caso, las fases de
lectura y escritura se traslapan, como se muestra en la (b), pero Tij no lee
datos queson escritos por Tk.

3) Si existe alguna transaccin Tk, tal que, ts( Tk ) < ts( Tij ) y la cual completa su
fase de lectura antes que Tij termine su fase de lectura, entonces, la
validacin tiene xito si WS(Tk ) RS(Tij ) = y WS(Tk ) WS(Tij ) = . En
este caso, las fases de lectura se traslapan, como se muestra en la (c), pero
las transacciones no accesan datos comunes.



4.2.3 DISCIPLINAS DEL INTERBLOQUEO: PREVENCIN,
DETECCIN, ELIMINACIN Y RECUPERACIN

Un interbloqueo se produce cuando dos o ms tareas se bloquean entre
s permanentemente teniendo cada tarea un bloqueo en un recurso que las otras
tareas intentan bloquear.

Un interbloqueo es una condicin que se puede dar en cualquier sistema con varios
subprocesos, no slo en un sistema de administracin de bases de datos
relacionales, y puede producirse para recursos distintos a los bloqueos en objetos de
base de datos

Por ejemplo:
La transaccin A tiene un bloqueo compartido de la fila 1.
La transaccin B tiene un bloqueo compartido de la fila 2.
La transaccin A ahora solicita un bloqueo exclusivo de la fila 2 y se bloquea
hasta que la transaccin B finalice y libere el bloqueo compartido que tiene de
la fila 2.
La transaccin B ahora solicita un bloqueo exclusivo de la fila 1 y se bloquea
hasta que la transaccin A finalice y libere el bloqueo compartido que tiene de
la fila 1.

PREVENCIN DEL INTERBLOQUEO
Objetivo: Conseguir que sea imposible la aparicin de situaciones de interbloqueo.
Impedir que se produzca una de las cuatro condiciones necesarias para producirlo:
Exclusin mutua, Retencin y espera, No expropiacin, y Espera circular.
Condicionar un sistema para quitar cualquier posibilidad de ocurrencia
de interbloqueo.
Que no se cumpla una condicin necesaria
Exclusin mutua y sin expropiacin no se pueden relajar. Dependen de
carcter intrnseco del recurso.
Las otras dos condiciones son ms prometedoras.

RECUPERACIN DE INTERBLOQUEO
Limpiar un sistema de interbloqueos, una vez que fueron detectados.
Cuando se ha detectado que existe un interbloqueo, podemos actuar de varias
formas. Una posibilidad es informar al operador que ha ocurrido un interbloqueo y
dejar que el operador se ocupe de l manualmente. La otra posibilidad es dejar que
el sistema se recupere automticamente del interbloqueo. Dentro de esta
recuperacin automtica tenemos dos opciones para romper el interbloqueo: Una
consiste en abortar uno o ms procesos hasta romper la espera circular, y la
segunda es apropiar algunos recursos de uno o ms de los procesos bloqueados.

ELIMINAR INTERBLOQUEOS
Para eliminar interbloqueos abortando un proceso, tenemos dos mtodos; en ambos,
el sistema recupera todos los recursos asignados a los procesos terminados.


1) Abortar todos los procesos interbloqueados. Esta es una de las soluciones
ms comunes, adoptada por Sistemas Operativos. Este mtodo romper
definitivamente el ciclo de interbloqueo pero con un costo muy elevado, ya que
estos procesos efectuaron clculos durante mucho tiempo y habr que
descartar los resultados de estos clculos parciales, para quiz tener que
volver a calcularlos ms tarde.

2) Abortar un proceso en cada ocasin hasta eliminar el ciclo de interbloqueo. El
orden en que se seleccionan los procesos para abortarlos debe basarse en
algn criterio de costo mnimo. Despus de cada aborto, debe solicitarse de
nuevo el algoritmo de deteccin, para ver si todava existe el interbloqueo.
Este mtodo cae en mucho tiempo de procesamiento adicional.

Si ste se encuentra actualizando un archivo, cortarlo a la mitad de la operacin
puede ocasionar que el archivo quede en un mal estado.

Si se utiliza el mtodo de terminacin parcial, entonces, dado un conjunto de
procesos bloqueados, debemos determinar cul proceso o procesos debe terminarse
para intentar romper el interbloqueo. Se trata sobre todo de una cuestin econmica,
debemos abortar los procesos que nos representen el menor costo posible.

4.3 CONFIABILIDAD

La confiabilidad es otro requerimiento indiscutible y probablemente el ms
importante. Una base de datos no confiable es simplemente inutilizable. Para la
mayora de las aplicaciones empotradas, en especial las empleadas en sistemas de
tiempo real, la confiabilidad es una propiedad no negociable que deben tener todos
los componentes.

Un sistema de manejo de bases de datos confiable es aquel que puede continua
procesando las solicitudes de usuario an cuando el sistema sobre el que opera no
es confiable. En otras palabras, aun cuando los componentes de un sistema
distribuido fallen, un DDMBS confiable debe seguir ejecutando las solicitudes de
usuario sin violar la consistencia de la base de datos.

Un sistema de manejo de bases de datos confiable es aquel que puede continua
procesando las solicitudes de usuario an cuando el sistema sobre el que opera no
es confiable. En otras palabras, aun cuando los componentes de un sistema
distribuido fallen, un DDMBS confiable debe seguir ejecutando las solicitudes de
usuario sin violar la consistencia de la base de datos.

Se discutirn las caractersticas de un DDBMS confiable. La confiabilidad de un
DDBMS se refiere a la atomicidad y durabilidad de las transacciones. Se asume que
el sistema sobre el cual se ejecutan los mecanismos de control de concurrencia es
confiable. Se considerar el caso de que un sistema distribuido no sea confiable y,


particularmente desde el punto de vista de los DDMBS, se presentarn los protocolos
para recuperacin de informacin.

A lo largo de estas notas nos hemos referido a la confiabilidad y disponibilidad de la
base de datos sin definir esos trminos de manera precisa. En esta seccin daremos
sus definiciones generales para posteriormente elaborarlas de manera ms formal.
La confiabilidad se puede interpretar de varias formas. La confiabilidad se puede ver
como una medida con la cual un sistema conforma su comportamiento a alguna
especificacin. Tambin se puede interpretar como la probabilidad de que un sistema
no haya experimentado ninguna falla dentro de un periodo de tiempo dado. La
confiabilidad se utiliza tpicamente como un criterio para describir sistemas que no
pueden ser reparados o donde la operacin continua del sistema es crtica.

Disponibilidad, por otro lado, es la fraccin del tiempo que un sistema satisface su
especificacin. En otras palabras, la probabilidad de que el sistema sea operacional
en un instante dado de tiempo.

4.3.1 CONCEPTOS BSICOS DE CONFIABILIDAD

La confiabilidad engloba varias
actividades y una de ellas es el
planteamiento de modelos de
confiabilidad, esto es
fundamentalmente la probabilidad de
supervivencia del sistema.

Se expresa como una funcin de las
confiabilidades de los componentes o
subsistemas, que generalmente,
estos modelos se encuentran
dependiendo del tiempo.

En cualquier sistema de bases de datos, centralizado o distribuido, se debe ofrecer
garantas de que la informacin es confiable. As cada consulta o actualizacin de la
informacin se realiza mediante transacciones, las cuales tienen un inicio y fin. En
sistemas distribuidos, el manejo de la atomicidad y durabilidad de las transacciones
es aun ms complejo, ya que una sola transaccin puede involucrar dos o ms sitios
de la red. As, el control de la recuperacin en sistemas distribuidos debe asegurar
que el conjunto de agentes que participen es una transaccin realicen todos un
compromiso (commit) a unison o todos al mismo tiempo restablezcan la informacin
anterior (roll-back).



4.3.2 PROTOCOLOS REDO/UNDO

RECUPERACIN IN-PLACE
Dado que la actualizacin in-place hacen que los valores anteriores se pierdan, es
necesario mantener suficiente informacin de los cambios de estado en la base de
datos. Esta informacin se mantiene, por lo general, en el registro de la base de
datos (database log). As cada actualizacin, no solo cambia la base de datos, sino
es tambin guardada en el registro de la base de datos.

El registro de la base de datos contiene informacin que es utilizada por el proceso
de recuperacin para restablecer la base de datos a un estado consistente. Esta
informacin puede incluir entre otras cosas:

el identificador de la transaccin,
el tipo de operacin realizada,
los datos accesados por la transaccin para realizar la accin,
el valor anterior del dato (imagen anterior), y
el valor nuevo del dato (imagen nueva).

El DBMS inicia la ejecucin en el tiempo 0 y en el tiempo t se presenta una falla del
sistema. Durante el periodo [0,t] ocurren dos transacciones, T
1
y T
2
. T
1
ha sido
concluida (ha realizado su commit) pero T
2
no pudo ser concluida. La propiedad de
durabilidad requiere que los efectos de T
1
sean reflejados en la base de datos
estable. De forma similar, la propiedad de atomicidad requiere que la base de datos
estable no contenga alguno de los efectos de T
2
.



A pesar que T
1
haya sido terminada, puede suceder que el buffer correspondiente a
la pgina de la base de datos modificada no haya sido escrito a la base de datos
estable. As, para este caso la recuperacin tiene que volver a realizar los cambios
hechos por T
1
. A esta operacin se le conoce como REDO. La operacin de REDO
utiliza la informacin del registro de la base de datos y realiza de nuevo las acciones
que pudieron haber sido realizadas antes de la falla. La operacin REDO genera una
nueva imagen.

Por otra parte, es posible que el administrador del buffer haya realizado la escritura
en la base de datos estable de algunas de las pginas de la base de datos voltil
correspondientes a la transaccin T
2
. As, la informacin de recuperacin debe incluir
datos suficientes para permitir deshacer ciertas actualizaciones en el nuevo estado
de la base de datos y regrasarla al estado anterior. A esta operacin se le conoce
como UNDO. La operacin UNDO restablece un dato a su imagen anterior utilizando
la informacin del registro de la base de datos.

De forma similar a la base de datos voltil, el registro de la base de datos se
mantiene en memoria principal (llamada los buffers de registro) y se escribe al
almacenamiento estable (llamado registro estable). Las pginas de registro se
pueden escribir en el registro estable de dos formas: sncrona o asncrona. En forma
sncrona, tambin llamada un registro forzado, la adicin de cada dato en el registro
requiere que la pgina del registro correspondiente se mueva al almacenamiento
estable. De manera asncrona, las pginas del registro se mueven en forma peridica
o cuando los buffers se llenan.

Independientemente de que la escritura del registro sea sncrona o asncrona, se
debe observar un protocolo importante para el mantenimiento del registro de la base


de datos. Considere el caso donde las actualizaciones a la base de datos son
escritas en el almacenamiento estable antes de que el registro sea modificado en el
registro estable para reflejar la actualizacin. Si una falla ocurre antes de que el
registro sea escrito, la base de datos permanecer en forma actualizada, pero el
registro no indicar la actualizacin lo que har imposible recuperar la base de datos
a un estado consistente antes de la actualizacin. Por lo tanto, el registro estable
siempre debe ser actualizado antes de la actualizacin de la base de datos. A este
protocolo se le conoce como registro antes de la escritura (write-ahead logging) y se
puede especificar de la manera siguiente:

1) Antes de que la base de datos estable sea actualizada, las imgenes
anteriores deben ser almacenadas en el registro estable. Esto facilita la
realizacin de un UNDO.
2) Cuando la transaccin realiza un commit, las imgenes nuevas tienen que ser
almacenadas en el registro estable antes de la actualizacin de la base de
datos estable. Esto facilita la realizacin de una operacin REDO.

La interfaz completa del registro de la base de datos voltil y estable.

RECUPERACIN OUT-OF-PLACE
Las tcnicas de recuperacin ms comunes son de tipo in-place. Por lo tanto, aqu se
presenta solo una breve descripcin de las tcnicas out-of-place.

1) Shadowing: Cuando ocurre una actualizacin, no se cambia la pgina
anterior, sino se crea una pgina sombra con el nuevo valor y se escribe en la
base de datos estable. Se actualizan los caminos de acceso de manera que
los accesos posteriores se hacen a la nueva pgina sombra. La pgina
anterior se retiene para propsitos de recuperacin, para realizar una
operacin UNDO.

2) Archivos Diferenciales: Para cada archivo F se mantiene una parte de solo
lectura (FR), un archivo diferencial que consiste de la parte de inserciones
DF+ y la parte de supresiones DF-. As, el archivo completo consistir de la


unin de la parte de lectura ms la parte de inserciones y a todo esto se le
eliminan las supresiones realizadas.

F = (FR DF+) DF-

Todas las actualizaciones se tratan como la supresin de un valor anterior y la
insercin de un nuevo valor. Peridicamente, el archivo diferencial tiene que ser
mezclado con el archivo base de solo lectura.

4.3.3 PUNTOS DE VERIFICACIN (CHECKPOINTS)

Cuando ocurre una falla en el sistema es necesario consultar la bitcora para
determinar cules son las transacciones que necesitan volver a hacerse y cuando no
necesitan hacerse. Estos puntos de verificacin nos ayudan para reducir el gasto de
tiempo consultando la bitcora. El punto de verificacin es un registro que se genera
en la bitcora para concluir en todo lo que se encuentra antes de ese punto est
correcto y verificado.

Los checkpoints buscan reducir los tiempos extra en los procesos de bsqueda en la
bitcora. Al disparar un checkpoint el sistema realiza la siguiente secuencia de
acciones:

Grabar en memoria estable todos los registros de bitcora que estn en
memoria principal.
Grabar en disco los bloques modificados de los registros intermedios (buffer).
Grabar un registro de bitcora en memoria estable.

La operacin de recuperacin requiere recorrer todo el registro de la base de datos.
As, el buscar todas las transacciones a las cuales es necesario aplicarles un UNDO
o REDO puede tomar una cantidad de trabajo considerable. Para reducir este trabajo
se pueden poner puntos de verificacin (checkpoints) en el registro de la base de
datos para indicar que en esos puntos la base de datos est actualizada y
consistente. En este caso, un REDO tiene que iniciar desde un punto de verificacin
y un UNDO tiene que regresar al punto de verificacin ms inmediato anterior. La
colocacin de puntos de verificacin se realiza con las siguientes acciones:

Se escribe un "begin_checkpoint" en el registro de la base de datos.
Se recolectan todos los datos verificados en la base de datos estable.
Se escribe un "fin_de_checkpoint" en el registro de la base de datos.

Cuando ocurre un fallo del sistema es necesario consultar la bitcora para ver cuales
transacciones deben rehacerse y cuales deshacerse.

Pasos a seguir ante fallos:



Para cada transaccin Ti tal que aparece en la bitcora el registro antes del
registro, no es necesario ejecutar un REDO.

Despus de un fallo, se examina la bitcora para determinar cul fue la ltima
transaccin Ti que comenz a ejecutarse antes del ltimo checkpoint.

Esto se hace examinando la bitcora hacia atrs buscando el primer registro y cul
es el registro ms cercano.
Luego, se aplica un REDO o UNDO sobre Ti y todas las transacciones que le
suceden. Un punto de control (checkpoint). Es registrado en la bitcora
peridicamente en el momento que el sistema ha grabado en la BD en disco los
efectos de todas la operaciones de escritura de las transacciones confirmadas.

4.3.4 PROTOCOLO 2PC DE CONFIABILIDAD DISTRIBUIDA

El protocolo 2PC bsico un agente (un agente-DTM en el modelo) con un rol
especial. Este es llamado el coordinador; todos los dems agentes que deben hacer
commit a la vez son llamados participantes.
El coordinador es responsable de tomar la decisin de llevar a cabo un commit o
abort finalmente. Cada participante corresponde a una subtransaccin la cual ha
realizado alguna accin de escritura en su base de datos local.

Se puede asumir que cada participante est en un sitio diferente. Aun si un
participante y el coordinador se encuentran en el mismo sitio, se sigue el protocolo
como si estuvieran en distintos sitios.

La idea bsica del 2PC es determinar una decisin nica para todos los participantes
con respecto a hacer commit o abort en todas las subtransacciones locales.
El protocolo consiste en dos fases:

La primera fase tiene como objetivo alcanzar una decisin comn.
La meta de la segunda fase es implementar esta decisin.

El protocolo procede como sigue:

FASE UNO:
El coordinador escribe prepare en la bitcora y enva un mensaje donde
pregunta a todos los participantes si preparan el commit (PREPARE).
Cada participante escribe ready (y registra las subtransacciones) en su
propia bitcora si est listo o abort de lo contrario.
Cada participante responde con un mensaje READY o ABORT al coordinador.
El coordinador decide el commit o abort en la transaccin como un resultado
de las respuestas que ha recibido de los participantes. Si todos respondieron
READY, decide hacer un commit. Si alguno ha respondido ABORT o no ha
respondido en un intervalo de tiempo determinado se aborta la transaccin.


FASE DOS:
El coordinador registra la decisin tomada en almacenamiento estable; es
decir, escribe global_commit o global_abort en la bitcora.
El coordinador enva mensaje de COMMIT o ABORT segn sea el caso para
su ejecucin.
Todos los participantes escriben un commit o abort en la bitcora basados en
el mensaje recibido del coordinador (desde este momento el procedimiento de
recuperacin es capaz de asegurar que el efecto de la subtransaccin no ser
perdido).

FINALMENTE:
Todos los participantes envan un mensaje de acuse de recibo (ACK) al
coordinador, y ejecutan las acciones requeridas para terminar (commit) o
abortar (abort) la subtransaccin.
Cuando el coordinador ha recibido un mensaje ACK de todos los participantes,
escribe un nuevo tipo de registro en la bitcora, llamado un registro
completo.

UNIDAD 4 Recuperacion de Informacion en Ambientes de BDD ANTOLOGIA

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

UNIDAD 4 Recuperacion de Informacion en Ambientes de BDD ANTOLOGIA

Încărcat de

Drepturi de autor:

Formate disponibile

REDES Y SISTEMAS DISTRIBUIDOS / Bases De Datos Distribuidas

INGENIERA EN SISTEMAS COMPUTACIONALES PGINA 1

S-ar putea să vă placă și