unidad 4 recuperacion de informacion en ambientes de bdd antologia.docx

8/11/2019 UNIDAD 4 Recuperacion de Informacion en Ambientes de BDD ANTOLOGIA.docx

1/21

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 AUNIDAD IV

Recuperacin De Informacin En Ambientes De

BDD

Profesor:

Instituto TecnolgicoSuperior

Ingeniera En Sistemas
http://www.itsx.edu.mx/sistemascomputacionales.htmlhttp://www.itsx.edu.mx/sistemascomputacionales.html


2/21



UNIDAD IV

RECUPERACIN DE INFORMACIN ENAMBIENTES DE BDD

4.1 Transacciones.4.1.1 Estructura de transacciones4.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.


3/21



4.1 TRANSACCIONES

Una transaccin es un programa en ejecucin que constituye una unidad lgica delprocesamiento de una base de datos. Una transaccin incluye una o msoperaciones 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 unidadlgica de trabajo. Un sistema de base de datos debe asegurar que la ejecucin delas transacciones se realice adecuadamente a pesar de la existencia de fallos: o seejecuta la transaccin completa o no se ejecuta en absoluto. Adems debe gestionarla ejecucin concurrente de las transacciones evitando introducir inconsistencias.

Una transaccin es una unidad de la ejecucin de un programa que accede yposiblemente actualiza varios elementos de datos. Una transaccin se inicia por laejecucin 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 formainicio transaccin y fin transaccin. La transaccin consiste en todas las operacionesque 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 transaccindebe estar en uno de los estados siguientes:

Activa:El estado inicial; la transaccin permanece en este estado durante suejecucin.

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/21



4.1.1 ESTRUCTURA DE TRANSACCIONES

Las transacciones planas consisten de una secuencia de operaciones primitivasencerradas entre las palabras clave beginy end. Por ejemplo,

Begin_transactionReservacin. . .end.

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

Begin_transactionReservacin. . .Begin_transactionVuelo. . .

end. {Vuelo}. . .Begin_transactionHotel. . .end.. . .

end.

Una transaccin anidada dentro de otra transaccin conserva las mismaspropiedades que la de sus padres, esto implica, que puede contener as mismotransacciones dentro de ella. Existen restricciones obvias en una transaccin

anidada: debe empezar despus que su padre y debe terminar antes que l. Msan, el commit de una subtransaccin es condicional al commit de su padre, en otraspalabras, si el padre de una o varias transacciones aborta, las subtransacciones hijastambin sern abortadas.

Las transacciones anidadas proporcionan un nivel ms alto de concurrencia entretransacciones. Ya que una transaccin consiste de varios transacciones, es posibletener ms concurrencia dentro de una sola transaccin. As tambin, es posiblerecuperarse de fallas de manera independiente de cada subtransaccin. Esto limitael dao a un parte ms pequea de la transaccin, haciendo que costo de larecuperacin sea menor.

En el segundo punto de vista se considera el orden de las lecturas y escrituras. Si lasacciones 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 escritoentonces se tendrn transacciones restringidas. Si las transacciones son restringidasa que todas las acciones de lectura se realicen antes de las acciones de escrituraentonces se les conoce como de dos pasos. Finalmente, existe un modelo de accin


5/21



para transacciones restringidas en donde se aplica an ms la restriccin de quecada par 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 ausenciade interferencias o la propiedad de aislamiento de las transacciones que se ejecutansimultneamente. La mayora de estas tcnicas garantizan la serializacin de lasplanificaciones, utilizando protocolos (conjuntos de reglas) que garantizan esaserializacin. Un importante conjunto de protocolos emplea la tcnica del bloqueo delos elementos de datos para evitar que varias transacciones accedanconcurrentemente a los elementos; algunos protocolos de bloqueo, que se utilizan encasi todos los DBMSs comerciales. Otro conjunto de protocolos de control de laconcurrencia utilizan las marcas de tiempo. Una marca de tiempo es un identificadornico generado por el sistema para cada transaccin. Los protocolos de control de la

concurrencia que utilizan la ordenacin de marcas de tiempo para garantizar laserializacin. Los protocolos de control de la concurrencia multiversin, que utilizanvarias versiones de un elemento de datos. Presentamos un protocolo basado en elconcepto de validacin o certificacin de una transaccin despus de que hayaejecutado sus operaciones; estos protocolos se denominan a veces protocolosoptimistas.

Otro factor que afecta al control de la concurrencia es la granularidad de loselementos de datos (es decir, qu porcin de la base de datos es representada porun elemento de datos). Un elemento puede ser tan pequeo como el valor de unatributo (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 ejecucinconcurrente de transacciones estn basadas en el concepto de bloqueo deelementos de datos. Un bloqueo es una variable asociada a un elemento de datosque describe el estado de ese elemento respecto a las posibles operaciones que sele puedan aplicar. Generalmente, hay un bloqueo por cada elemento de datos de labase de datos. Los bloqueos se utilizan como un medio para sincronizar el acceso delas 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 unconjunto de transacciones T = { T1, T2, ..., Tn } y especifica un orden entrelazado dela ejecucin de las operaciones de las transacciones. La calendarizacin puede serespecificada como un orden parcial sobre T.


6/21



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 CommitUna 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 elmismo dato de la base de datos x se dice que estn en conflicto si al menos una deellas es una escritura. De esta manera, las operaciones de lectura no tienenconflictos consigo mismas. Por tanto, existen dos tipos de conflictos read-write (owrite-read) y writewrite. Las dos operaciones en conflicto pueden pertenecer a lamisma transaccin o a transacciones diferentes.

SERIABILIDAD EN SMBD DISTRIBUIDOSEn bases de datos distribuidas es necesario considerar dos tipos de historia parapoder generar calendarizaciones serializables: la calendarizacin de la ejecucin detransacciones en un nodo conocido como calendarizacin local y la calendarizacinglobal de las transacciones en el sistema. Para que las transacciones globales seanserializables se deben satisfacer las siguientes condiciones: cada historia local debeser serializable, y dos operaciones en conflicto deben estar en el mismo ordenrelativo en todas las historias locales donde las operaciones aparecen juntas.

La segunda condicin simplemente asegura que el orden de serializacin sea elmismo 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 * 5Write( x ) Write( x )Commit Commit

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


7/21



4.2.2 ALGORITMOS DE CONTROL DE CONCURRENCIA

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

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

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

Los algoritmos pesimistas sincronizan la ejecucin concurrente de las transaccionesen su etapa inicial de su ciclo de ejecucin. Los algoritmos optimistas retrasan lasincronizacin 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 ybasados en estampas de tiempo.


8/21



4.2.2.1 BASADOS EN BLOQUEO

Un bloqueo en general es cuando una accin que debe ser realizada est esperandoa 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 enlos 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 losmanejadores de transacciones y el calendarizador. Para esto existen dos formasbsicas:

Autnoma: Cada nodo es responsable por sus propios bloqueos derecursos.

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 losbloqueos derecursos.

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 siambas acceden a la misma data, y una de ellas es de escritura y si fueron realizadaspor 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. Enlugar de eso, ellos seleccionan un orden de serializacin a priori y ejecutan lastransacciones de acuerdo a ellas. Para establecer este ordenamiento, eladministrador de transacciones le asigna a cada transaccin Ti una estampa detiempo nica ts( Ti ) cuando sta inicia. Una estampa de tiempo es un identificadorsimple que sirve para identificar cada transaccin de manera nica. Otra propiedadde las estampas de tiempo es la monoticidad, esto es, dos estampas de tiempogeneradas por el mismo administrador de transacciones deben ser monotonicamente


9/21



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

Existen varias formas en que las estampas de tiempo se pueden asignar. Un mtodoes usar un contador global monotonicamente creciente. Sin embargo, elmantenimiento de contadores globales es un problema en sistemas distribuidos. Porlo tanto, es preferible que cada nodo asigne de manera autnoma las estampas detiempos basndose en un contador local. Para obtener la unicidad, cada nodo leagrega al contador su propio identificador. As, la estampa de tiempo es un par de laforma

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

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

lectura y escritura dex, 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 lastransacciones Ti y Tk, respectivamente, Oij es ejecutada antes de Okl, si ysolamente si, ts(Ti) < ts(Tk). En este caso Ti se dice ser un transaccin msvieja y Tk se dice ser una transaccin ms joven.


10/21



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

for Ri(x) do beginif ts(Ti) < wts(x ) then

reject Ri(x)elseaccept Ri(x)rts(x) ts(Ti)end

for Wi(x) do beginif ts(Ti) < rts(x) and

ts(Ti) < wts(x) thenreject Wi(x)elseaccept Wi(x)wts(x) ts(Ti)end

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

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

ORDENAMIENTO POR ESTAMPAS DE TIEMPO MLTIPLESPara prevenir la formacin de interbloqueos se puede seguir la estrategia siguiente.

Al hacer una operacin de escritura, no se modifican los valores actuales sino secrean nuevos valores. As, puede haber copias mltiples de un dato. Para crearcopias nicas se siguen las siguientes estrategias de acuerdo al tipo de operacin deque se trate:

Una operacin de lectura Ri(x) se traduce a una operacin de lectura de x deuna sola versin encontrando la versin dex, digamosxv, tal que, ts(xv) es laestampa 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 esaceptada 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 naturalezapesimistas. En otras palabras, ellos asumen que los conflictos entre transaccionesson muy frecuentes y no permiten el acceso a un dato si existe una transaccinconflictiva que accesa el mismo dato. As, la ejecucin de cualquier operacin de unatransaccin sigue la secuencia de fases: validacin (V), lectura (R), cmputo (C) y


11/21



escritura (W). Los algoritmos optimistas, por otra parte, retrasan la fase de validacinjusto antes de la fase de escritura. De esta manera, una operacin sometida a undespachador 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 inicialmentehace sus cambios en copias locales de los datos. La fase de validacin consiste enverificar si esas actualizaciones conservan la consistencia de la base de datos. Si larespuesta es positiva, los cambios se hacen globales (escritos en la base de datoscorriente). De otra manera, la transaccin es abortada y tiene que reiniciar.

Los mecanismos optimistas para control de concurrencia fueron propuestosoriginalmente con el uso de estampas de tiempo. Sin embargo, en este tipo demecanismos 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 unatransaccin sino justamente al inicio de su fase de validacin. Esto se debe a que lasestampas se requieren nicamente durante la fase de validacin.

Cada transaccin Ti se subdivide en varias subtransacciones, cada una de las cualesse puede ejecutar en nodos diferentes. Sea Tij una subtransaccin de Ti que seejecuta en el nodo j. Supongamos que las transacciones se ejecutan de maneraindependiente y ellas alcanzan el fin de sus fases de lectura. A todas lassubtransacciones 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 transaccinfalla, todas las transacciones se rechazan.

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


12/21



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

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

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


13/21



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

Un interbloqueo se produce cuando dos o ms tareas se bloquean entres 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 variossubprocesos, no slo en un sistema de administracin de bases de datosrelacionales, y puede producirse para recursos distintos a los bloqueos en objetos debase 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 dela fila 2.

La transaccin B ahora solicita un bloqueo exclusivo de la fila 1 y se bloqueahasta que la transaccin A finalice y libere el bloqueo compartido que tiene dela fila 1.

PREVENCIN DEL INTERBLOQUEOObjetivo: 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 INTERBLOQUEOLimpiar un sistema de interbloqueos, una vez que fueron detectados.Cuando se ha detectado que existe un interbloqueo, podemos actuar de variasformas. Una posibilidad es informar al operador que ha ocurrido un interbloqueo ydejar que el operador se ocupe de l manualmente. La otra posibilidad es dejar que

el sistema se recupere automticamente del interbloqueo. Dentro de estarecuperacin automtica tenemos dos opciones para romper el interbloqueo: Unaconsiste en abortar uno o ms procesos hasta romper la espera circular, y lasegunda es apropiar algunos recursos de uno o ms de los procesos bloqueados.

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


14/21



1) Abortar todos los procesos interbloqueados. Esta es una de las solucionesms comunes, adoptada por Sistemas Operativos. Este mtodo romperdefinitivamente el ciclo de interbloqueo pero con un costo muy elevado, ya queestos procesos efectuaron clculos durante mucho tiempo y habr quedescartar 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 enalgn criterio de costo mnimo. Despus de cada aborto, debe solicitarse denuevo 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 operacinpuede ocasionar que el archivo quede en un mal estado.

Si se utiliza el mtodo de terminacin parcial, entonces, dado un conjunto deprocesos bloqueados, debemos determinar cul proceso o procesos debe terminarsepara 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 msimportante. Una base de datos no confiable es simplemente inutilizable. Para lamayora de las aplicaciones empotradas, en especial las empleadas en sistemas de

tiempo real, la confiabilidad es una propiedad no negociable que deben tener todoslos componentes.

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

Un sistema de manejo de bases de datos confiable es aquel que puede continuaprocesando las solicitudes de usuario an cuando el sistema sobre el que opera no

es confiable. En otras palabras, aun cuando los componentes de un sistemadistribuido fallen, un DDMBS confiable debe seguir ejecutando las solicitudes deusuario sin violar la consistencia de la base de datos.

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


15/21



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

A lo largo de estas notas nos hemos referido a la confiabilidad y disponibilidad de labase 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 vercomo una medida con la cual un sistema conforma su comportamiento a algunaespecificacin. Tambin se puede interpretar como la probabilidad de que un sistemano haya experimentado ninguna falla dentro de un periodo de tiempo dado. Laconfiabilidad se utiliza tpicamente como un criterio para describir sistemas que nopueden ser reparados o donde la operacin continua del sistema es crtica.

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

4.3.1 CONCEPTOS BSICOS DE CONFIABILIDAD

La confiabilidad engloba variasactividades y una de ellas es elplanteamiento de modelos deconfiabilidad, esto esfundamentalmente la probabilidad desupervivencia del sistema.

Se expresa como una funcin de las

confiabilidades de los componentes osubsistemas, que generalmente,estos modelos se encuentrandependiendo del tiempo.

En cualquier sistema de bases de datos, centralizado o distribuido, se debe ofrecergarantas de que la informacin es confiable. As cada consulta o actualizacin de lainformacin se realiza mediante transacciones, las cuales tienen un inicio y fin. Ensistemas distribuidos, el manejo de la atomicidad y durabilidad de las transaccioneses aun ms complejo, ya que una sola transaccin puede involucrar dos o ms sitiosde 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 uncompromiso (commit) a unison o todos al mismo tiempo restablezcan la informacinanterior (roll-back).


16/21



4.3.2 PROTOCOLOS REDO/UNDO

RECUPERACIN IN-PLACEDado que la actualizacin in-place hacen que los valores anteriores se pierdan, esnecesario 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 dedatos (database log). As cada actualizacin, no solo cambia la base de datos, sinoes tambin guardada en el registro de la base de datos.

El registro de la base de datos contiene informacin que es utilizada por el procesode recuperacin para restablecer la base de datos a un estado consistente. Estainformacin 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 tse presenta una falla delsistema. Durante el periodo [0,t] ocurren dos transacciones, T1 y T2. T1 ha sidoconcluida (ha realizado su commit) pero T2no pudo ser concluida. La propiedad dedurabilidad requiere que los efectos de T1 sean reflejados en la base de datosestable. De forma similar, la propiedad de atomicidad requiere que la base de datosestable no contenga alguno de los efectos de T2.


17/21



A pesar que T1haya sido terminada, puede suceder que el buffer correspondiente ala pgina de la base de datos modificada no haya sido escrito a la base de datosestable. As, para este caso la recuperacin tiene que volver a realizar los cambioshechos por T1. A esta operacin se le conoce como REDO. La operacin de REDOutiliza 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 unanueva imagen.

Por otra parte, es posible que el administrador del buffer haya realizado la escrituraen la base de datos estable de algunas de las pginas de la base de datos voltilcorrespondientes a la transaccin T2. As, la informacin de recuperacin debe incluirdatos suficientes para permitir deshacer ciertas actualizaciones en el nuevo estadode la base de datos y regrasarla al estado anterior. A esta operacin se le conocecomo UNDO. La operacin UNDO restablece un dato a su imagen anterior utilizandola informacin del registro de la base de datos.

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

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


18/21



de datos. Considere el caso donde las actualizaciones a la base de datos sonescritas en el almacenamiento estable antes de que el registro sea modificado en elregistro estable para reflejar la actualizacin. Si una falla ocurre antes de que elregistro sea escrito, la base de datos permanecer en forma actualizada, pero elregistro 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 establesiempre debe ser actualizado antes de la actualizacin de la base de datos. A esteprotocolo se le conoce como registro antes de la escritura (write-ahead logging) y sepuede especificar de la manera siguiente:

1) Antes de que la base de datos estable sea actualizada, las imgenesanteriores deben ser almacenadas en el registro estable. Esto facilita larealizacin de un UNDO.

2) Cuando la transaccin realiza un commit, las imgenes nuevas tienen que seralmacenadas en el registro estable antes de la actualizacin de la base dedatos 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-PLACELas tcnicas de recuperacin ms comunes son de tipo in-place. Por lo tanto, aqu sepresenta solo una breve descripcin de las tcnicas out-of-place.

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

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


19/21



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

F = (FR DF+)DF-

Todas las actualizaciones se tratan como la supresin de un valor anterior y lainsercin de un nuevo valor. Peridicamente, el archivo diferencial tiene que sermezclado 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 paradeterminar cules son las transacciones que necesitan volver a hacerse y cuando nonecesitan hacerse. Estos puntos de verificacin nos ayudan para reducir el gasto detiempo consultando la bitcora. El punto de verificacin es un registro que se generaen 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 labitcora. Al disparar un checkpoint el sistema realiza la siguiente secuencia deacciones:

Grabar en memoria estable todos los registros de bitcora que estn enmemoria 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 UNDOo REDO puede tomar una cantidad de trabajo considerable. Para reducir este trabajose pueden poner puntos de verificacin (checkpoints) en el registro de la base dedatos para indicar que en esos puntos la base de datos est actualizada yconsistente. En este caso, un REDO tiene que iniciar desde un punto de verificaciny un UNDO tiene que regresar al punto de verificacin ms inmediato anterior. Lacolocacin 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 cualestransacciones deben rehacerse y cuales deshacerse.

Pasos a seguir ante fallos:


20/21



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

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

Esto se hace examinando la bitcora hacia atrs buscando el primer registro y cules el registro ms cercano.Luego, se aplica un REDO o UNDO sobre Ti y todas las transacciones que lesuceden. Un punto de control (checkpoint). Es registrado en la bitcoraperidicamente en el momento que el sistema ha grabado en la BD en disco losefectos 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 hacercommit a la vez son llamados participantes.El coordinador es responsable de tomar la decisin de llevar a cabo un commit oabort finalmente. Cada participante corresponde a una subtransaccin la cual harealizado alguna accin de escritura en su base de datos local.

Se puede asumir que cada participante est en un sitio diferente. Aun si unparticipante y el coordinador se encuentran en el mismo sitio, se sigue el protocolocomo 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 supropia 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 respondieronREADY, decide hacer un commit. Si alguno ha respondido ABORT o no harespondido en un intervalo de tiempo determinado se aborta la transaccin.


21/21



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 enel mensaje recibido del coordinador (desde este momento el procedimiento derecuperacin es capaz de asegurar que el efecto de la subtransaccin no serperdido).

FINALMENTE: Todos los participantes envan un mensaje de acuse de recibo (ACK) al

coordinador, y ejecutan las acciones requeridas para terminar (commit) oabortar (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 registrocompleto.

unidad 4 recuperacion de informacion en ambientes de bdd antologia.docx

Documents