UNIDAD 4 Recuperacion de Informacion en Ambientes de BDD ANTOLOGIA.docx

REDES Y SISTEMAS DISTRIBUIDOS / Bases De Datos Distribuidas

Instituto Tecnológico Superior Ingeniería En Sistemas

Especialidad Redes Y Sistemas Distribuidos

Materia Base De Datos Distribuidas

ANTOLOGÍA UNIDAD IV “Recuperación De Información En Ambientes De BDD”

Profesor:

INGENIERÍA EN SISTEMAS COMPUTACIONALES

PÁGINA 1


UNIDAD IV RECUPERACIÓN RECUPERACIÓN DE INFORMACIÓN EN AMBIENTES DE BDD 4.1 Transacciones. 4.1.1 Estructura de transacciones 4.1.2 Ejecución de transacciones centralizada y distribuida. 4.2 Control de concurrencia. 4.2.1 Serialización 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 validación optimistas. 4.2.3 Disciplinas del Interbloqueo: prevención, detección, eliminación y recuperación. 4.3 Confiabilidad. 4.3.1 Conceptos básicos de confiabilidad. 4.3.2 Protocolos REDO/UNDO. 4.3.3 Puntos de verificación (checkpoints). 4.3.4 Protocolo 2PC de confiabilidad distribuida.


PÁGINA 2


4.1 TRANSACCIONES Una transacción es un programa en ejecución que constituye una unidad lógica del procesamiento de una base de datos. Una transacción incluye una o más operaciones de acceso a la base de datos (operaciones de inserción, eliminación, modificación o recuperación). Se llama transacción a una colección de operaciones que forman una única unidad lógica de trabajo. Un sistema de base de datos debe asegurar que la ejecución de las transacciones se realice adecuadamente a pesar de la existencia de fallos: o se ejecuta la transacción completa o no se ejecuta en absoluto. Además debe gestionar la ejecución concurrente de las transacciones evitando introducir inconsistencias. Una transacción es una unidad de la ejecución de un programa que accede y posiblemente actualiza varios elementos de datos. Una transacción se inicia por la ejecución de un programa de usuario escrito en un lenguaje de manipulación de datos de alto nivel o en un lenguaje de programación (por ejemplo SQL, COBOL, C, C++ o Java), y está delimitado por instrucciones (o llamadas a función) de la forma inicio transacción y fin transacción. La transacción consiste en todas las operaciones que se ejecutan entre inicio transacción y el fin transacción. Es necesario precisar qué se entiende por terminación con éxito de una transacción. Se establece por tanto un modelo simple abstracto de transacción. Una transacción debe estar en uno de los estados siguientes:     

Activa: El estado inicial; la transacción permanece en este estado durante su ejecución. Parcialmente Comprometida: Después de ejecutarse la última instrucción. Fallida: Tras descubrir que no puede continuar la ejecución normal. Abortada: Después de haber retrocedido la transacción y restablecido la base de datos a su estado anterior al comienzo de la transacción. Comprometida: Tras completarse con éxito.


PÁGINA 3


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 Reservación ... end. En las transacciones anidadas las operaciones de una transacción pueden ser así mismo transacciones. Por ejemplo,

Begin_transaction Reservación ... Begin_transaction Vuelo ... end. {Vuelo} ... Begin_transaction Hotel ... end. ... end. Una transacción anidada dentro de otra transacción 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 transacción anidada: debe empezar después que su padre y debe terminar antes que él. Más aún, el commit de una subtransacción es condicional al commit de su padre, en otras palabras, si el padre de una o varias transacciones ab orta, las subtransacciones hijas también serán abortadas.

Las transacciones anidadas proporcionan un nivel más alto de concurrencia entre transacciones. Ya que una transacción consiste de varios transacciones, es posible tener más concurrencia dentro de una sola transacción. Así también, es posible recuperarse de fallas de manera independiente de cada subtransacción. Esto limita el daño a un parte más pequeña de la transacción, haciendo que costo de la recuperación 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 restricción, entonces, a este tipo de transacciones se les conoce como generales. En contraste, si se restringe o impone que un dato deber ser leído antes de que pueda ser escrito entonces se tendrán 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 acción INGENIERÍA EN SISTEMAS COMPUTACIONALES

PÁGINA 4


para transacciones restringidas en donde se aplica aún más la restricción de que cada par tiene que ser ejecutado de manera atómica.

4.2 CONTROL DE CONCURRENCIA Las técnicas 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 simultáneamente. La mayoría de estas técnicas garantizan la serialización de las planificaciones, utilizando protocolos (conjuntos de reglas) que garantizan esa serialización. Un importante conjunto de protocolos emplea la técnica 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 transacción. Los protocolos de control de la concurrencia que utilizan la ordenación de marcas de tiempo para garantizar la serialización. Los protocolos de control de la concurrencia multiversión, que utilizan varias versiones de un elemento de datos. Presentamos un protocolo basado en el concepto de validación o certificación de una transacción después 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é porción de la base de datos es representada por un elemento de datos). Un elemento puede ser tan pequeño 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 técnicas que se utilizan para controlar la ejecución concurrente de transacciones están 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 SERIALIZACIÓN DE TRANSACCIONES TEORÍA DE LA SERIABILIDAD Una calendarización (schedule), también llamado una historia, se define sobre un conjunto de transacciones T = { T1, T2, ..., Tn } y especifica un orden entrelazado de la ejecución de las operaciones de las transacciones. La calendarización puede ser especificada como un orden parcial sobre T. 


PÁGINA 5


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 calendarización 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 están 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 transacción 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 calendarización de la ejecución de transacciones en un nodo conocido como calendarización local y la calendarización 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 condición simplemente asegura que el orden de serialización 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+5x←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 }


PÁGINA 6


4.2.2 ALGORITMOS DE CONTROL DE CONCURRENCIA Los algoritmos de control de concurrencia deben sincronizar la ejecución de transacciones concurrentes bajo el criterio de correctitud. La consistencia entre transacciones se garantiza mediante el aislamiento de las mismas. El criterio de clasificación más común de los algoritmos de control de concurrencia es el tipo de primitiva de sincronización. Esto resulta en dos clases: aquellos algoritmos que están basados en acceso mutuamente exclusivo a datos compartidos (candados) y aquellos que intentar ordenar la ejecución 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 ejecución concurrente de las transacciones en su etapa inicial de su ciclo de ejecución. Los algoritmos optimistas retrasan la sincronización de las transacciones hasta su terminación. El grupo de algoritmos pesimistas consiste de algoritmos basados en candados, algoritmos basados en ordenamiento por estampas de tiempo y algoritmos híbridos. El grupo de los algoritmos optimistas se clasifican por basados en candados y basados en estampas de tiempo.


PÁGINA 7


4.2.2.1 BASADOS EN BLOQUEO Un bloqueo en general es cuando una acción que debe ser realizada está esperando a un evento. Para manejar los bloqueos hay distintos acercamientos: prevención, detección, y recuperación. También es necesario considerar factores como que hay sistemas en los que permitir un bloqueo es inaceptable y catastrófico, y sistemas en los que la detección del bloqueo es demasiado costosa. En el caso específico 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 básicas:              

Autónoma: Cada nodo es responsable por sus propios bloqueos de recursos. Una transacción sobre un elemento con n replicas requiere 5n mensajes Petición del recurso Aprobación de la petición Mensaje de la transacción Reconocimientos de transacción exitosa Peticiones de liberación de recursos Copia Primaria: Un nodo primario es responsable para todos los bloqueos de recursos. Una transacción sobre un elemento con n copias requiere 2n+3 mensajes Una petición del recurso Una aprobación de la petición n mensajes de la transacción n reconocimientos de transacción exitosa Una petición de liberación 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 exclusión mutua. En lugar de eso, ellos seleccionan un orden de serialización a priori y ejecutan las transacciones de acuerdo a ellas. Para establecer este ordenamiento, el administrador de transacciones le asigna a cada transacción Ti una estampa de tiempo única ts( Ti ) cuando ésta inicia. Una estampa de tiempo es un identificador simple que sirve para identificar cada transacción 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 INGENIERÍA EN SISTEMAS COMPUTACIONALES

PÁGINA 8


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 método 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 autónoma las estampas de tiempos basándose 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 Note que el identificador de nodo se agrega en la posición 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 también una estampa de tiempo a todas las operaciones solicitadas por una transacción. Más aún, 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 más 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 transacción más vieja y Tk se dice ser una transacción más joven.


PÁGINA 9


Dado este orden, un conflicto entre operaciones se puede resolver de la siguiente forma: f o r Ri ( x ) d o b e g i n if ts(Ti ) < wts( x ) t h e n

reject Ri ( x )

f o r Wi ( x ) d o b e g i n if ts(Ti ) < rts( x ) a n d ts(Ti ) < wts( x ) t h e n

else

reject Wi ( x )

accept Ri ( x )

else accept W i ( x ) wts( x ) ¬ ts(T i)

rts( x ) ¬ ts(T i) end

en d

La acción de rechazar una operación, significa que la transacción que la envió necesita reiniciarse para obtener la estampa de tiempo más reciente del dato e intentar hacer nuevamente la operación sobre el dato.

ORDENAMIENTO CONSERVADOR POR ESTAMPAS DE TIEMPO El ordenamiento básico por estampas de tiempo trata de ejecutar una operación tan pronto como se recibe una operación. Así, la ejecución de las operaciones es progresiva pero pueden presentar muchos reinicios de transacciones. El ordenamiento conservador de estampas de tiempo retrasa cada operación hasta que exista la seguridad de que no será reiniciada. La forma de asegurar lo anterior es sabiendo que ninguna otra operación 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 creación de interbloqueos ( deadlocks). 

ORDENAMIENTO POR ESTAMPAS DE TIEMPO MÚLTIPLES Para prevenir la formación de interbloqueos se puede seguir la estrategia siguiente. Al hacer una operación de escritura, no se modifican los valores actuales sino se crean nuevos valores. Así, puede haber copias múltiples de un dato. Para crear copias únicas se siguen las siguientes estrategias de acuerdo al tipo de operación de que se trate: 





Una operación de lectura Ri ( x ) se traduce a una operación de lectura de x de una sola versión encontrando la versión de x , digamos xv , tal que, ts( xv ) es la estampa de tiempo más grande que tiene un valor menor a ts(Ti ). Una operación 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 VALIDACIÓN 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 transacción conflictiva que accesa el mismo dato. Así, la ejecución de cualquier operación de una transacción sigue la secuencia de fases: validación (V), lectura (R), cómputo (C) y INGENIERÍA EN SISTEMAS COMPUTACIONALES

PÁGINA 10


escritura (W). Los algoritmos optimistas, por otra parte, retrasan la fase de validación justo antes de la fase de escritura. De esta manera, una operación sometida a un despachador optimista nunca es retrasada. Las operaciones de lectura, cómputo y escrita de cada transacción se procesan libremente sin actualizar la base de datos corriente. Cada transacción inicialmente hace sus cambios en copias locales de los datos. La fase de validación 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 transacción 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. Más aún, las estampas de tiempo no se asignan al inicio de una transacción sino justamente al inicio de su fase de validación. Esto se debe a que las estampas se requieren únicamente durante la fase de validación. Cada transacción Ti se subdivide en varias subtransacciones, cada una de las cuales se puede ejecutar en nodos diferentes. Sea Tij una subtransacción 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 validación se realiza una prueba de validación, si una transacción falla, todas las transacciones se rechazan. La prueba de validación se realiza con una de las siguientes reglas: INGENIERÍA EN SISTEMAS COMPUTACIONALES

PÁGINA 11


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 validación tiene éxito. En este caso la ejecución de las transacciones es completamente serial como se muestra en la (a). 2) Si existe alguna transacción 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 validación 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 transacción 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 validación 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.


PÁGINA 12


4.2.3 DISCIPLINAS DEL INTERBLOQUEO: PREVENCIÓN, DETECCIÓN, ELIMINACIÓN Y RECUPERACIÓN Un interbloqueo se produce cuando dos o más tareas se bloquean entre sí permanentemente teniendo cada tarea un bloqueo en un recurso que las otras tareas intentan bloquear. Un interbloqueo es una condición que se puede dar en cualquier sistema con varios subprocesos, no sólo en un sistema de administración de bases de datos relacionales, y puede producirse para recursos distintos a los bloqueos en objetos de base de datos Por ejemplo:  La transacción A tiene un bloqueo compartido de la fila 1.  La transacción B tiene un bloqueo compartido de la fila 2.  La transacción A ahora solicita un bloqueo exclusivo de la fila 2 y se bloquea hasta que la transacción B finalice y libere el bloqueo compartido que tiene de la fila 2.  La transacción B ahora solicita un bloqueo exclusivo de la fila 1 y se bloquea hasta que la transacción A finalice y libere el bloqueo compartido que tiene de la fila 1.

PREVENCIÓN DEL INTERBLOQUEO Objetivo: Conseguir que sea imposible la aparición de situaciones de interbloqueo. Impedir que se produzca una de las cuatro condiciones necesarias para producirlo: Exclusión mutua, Retención y espera, No expropiación, y Espera circular. Condicionar un sistema para quitar cualquier posibilidad de ocurrencia de interbloqueo. Que no se cumpla una condición necesaria 

 

“Exclusión mutua” y “sin expropiación” no se pueden relajar. Dependen de

carácter intrínseco del recurso. Las otras dos condiciones son más prometedoras.

RECUPERACIÓN 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 automáticamente del interbloqueo. Dentro de esta recuperación automática tenemos dos opciones para romper el interbloqueo: Una consiste en abortar uno o más procesos hasta romper la espera circular, y la segunda es apropiar algunos recursos de uno o más de los procesos bloqueados. 

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


PÁGINA 13


1) Abortar todos los procesos interbloqueados. Esta es una de las soluciones más comunes, adoptada por Sistemas Operativos. Este método romperá definitivamente el ciclo de interbloqueo pero con un costo muy elevado, ya que estos procesos efectuaron cálculos durante mucho tiempo y habrá que descartar los resultados de estos cálculos parciales, para quizá tener que volver a calcularlos más tarde. 2) Abortar un proceso en cada ocasión hasta eliminar el ciclo de interbloqueo. El

orden en que se seleccionan los procesos para abortarlos debe basarse en algún criterio de costo mínimo. Después de cada aborto, debe solicitarse de nuevo el algoritmo de detección, para ver si todavía existe el interbloqueo. Este método cae en mucho tiempo de procesamiento adicional. Si éste se encuentra actualizando un archivo, cortarlo a la mitad de la operación puede ocasionar que el archivo quede en un mal estado. Si se utiliza el método de terminación parcial, entonces, dado un conjunto de procesos bloqueados, debemos determinar cuál proceso o procesos debe terminarse para intentar romper el interbloqueo. Se trata sobre todo de una cuestión económica, debemos abortar los procesos que nos representen el menor costo posible.

4.3 CONFIABILIDAD La confiabilidad es otro requerimiento indiscutible – y probablemente el más importante. Una base de datos no confiable es simplemente inutilizable. Para la mayoría 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 aún 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 aún 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 discutirán las características 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, INGENIERÍA EN SISTEMAS COMPUTACIONALES

PÁGINA 14


particularmente desde el punto de vista de los DDMBS, se presentarán los protocolos para recuperación de información. A lo largo de estas notas nos hemos referido a la confiabilidad y disponibilidad de la base de datos sin definir esos términos de manera precisa. En esta sección daremos sus definiciones generales para posteriormente elaborarlas de manera más 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 especificación. También 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 típicamente como un criterio para describir sistemas que no pueden ser reparados o donde la operación continua del sistema es crítica. Disponibilidad, por otro lado, es la fracción del tiempo que un sistema satisface su especificación. En otras palabras, la probabilidad de que el sistema sea operacional en un instante dado de tiempo.

4.3.1 CONCEPTOS BÁSICOS 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 función 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 garantías de que la información es confiable. Así cada consulta o actualización de la información 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 más complejo, ya que una sola transacción puede involucrar dos o más sitios de la red. Así, el control de la recuperación en sistemas distribuidos debe asegurar que el conjunto de agentes que participen es una transacción realicen todos un compromiso (commit) a unisonó o todos al mismo tiempo restablezcan la información anterior (roll-back).


PÁGINA 15


4.3.2 PROTOCOLOS REDO/UNDO RECUPERACIÓN IN-PLACE Dado que la actualización in-place hacen que los valores anteriores se pierdan, es necesario mantener suficiente información de los cambios de estado en la base de datos. Esta información se mantiene, por lo general, en el registro de la base de datos (database log). Así cada actualización, no solo cambia la base de datos, sino es también guardada en el registro de la base de datos. 

El registro de la base de datos contiene información que es utilizada por el proceso de recuperación para restablecer la base de datos a un estado consistente. Esta información puede incluir entre otras cosas:     

el identificador de la transacción, el tipo de operación realizada, los datos accesados por la transacción para realizar la acción, el valor anterior del dato (imagen anterior), y el valor nuevo del dato (imagen nueva).

El DBMS inicia la ejecución 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.


PÁGINA 16


A pesar que T 1 haya sido terminada, puede suceder que el buffer correspondiente a la página de la base de datos modificada no haya sido escrito a la base de datos estable. Así, para este caso la recuperación tiene que volver a realizar los cambios hechos por T 1. A esta operación se le conoce como REDO. La operación de REDO utiliza la información del registro de la base de datos y realiza de nuevo las acciones que pudieron haber sido realizadas antes de la falla. La operación 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 páginas de la base de datos volátil correspondientes a la transacción T 2. Así, la información de recuperación 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 operación se le conoce como UNDO. La operación UNDO restablece un dato a su imagen anterior utilizando la información del registro de la base de datos.

De forma similar a la base de datos volátil, 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 páginas de registro se pueden escribir en el registro estable de dos formas: síncrona o asíncrona. En forma síncrona, también llamada un registro forzado, la adición de cada dato en el registro requiere que la página del registro correspondiente se mueva al almacenamiento estable. De manera asíncrona, las páginas del registro se mueven en forma periódica o cuando los buffers se llenan. Independientemente de que la escritura del registro sea síncrona o asíncrona, se debe observar un protocolo importante para el mantenimiento del registro de la base INGENIERÍA EN SISTEMAS COMPUTACIONALES

PÁGINA 17


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 actualización. 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 actualización lo que hará imposible recuperar la base de datos a un estado consistente antes de la actualización. Por lo tanto, el registro estable siempre debe ser actualizado antes de la actualización 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 imágenes anteriores deben ser almacenadas en el registro estable. Esto facilita la realización de un UNDO. 2) Cuando la transacción realiza un commit, las imágenes nuevas tienen que ser almacenadas en el registro estable antes de la actualización de la base de datos estable. Esto facilita la realización de una operación REDO. La interfaz completa del registro de la base de datos volátil y estable.

RECUPERACIÓN OUT-OF-PLACE Las técnicas de recuperación más comunes son de tipo in-place. Por lo tanto, aquí se presenta solo una breve descripción de las técnicas out-of-place. 

1) Shadowing: Cuando ocurre una actualización, no se cambia la página anterior, sino se crea una página 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 página sombra. La página anterior se retiene para propósitos de recuperación, para realizar una operación 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 INGENIERÍA EN SISTEMAS COMPUTACIONALES

PÁGINA 18


unión de la parte de lectura más 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 supresión de un valor anterior y la inserción de un nuevo valor. Periódicamente, el archivo diferencial tiene que ser mezclado con el archivo base de solo lectura.

4.3.3 PUNTOS DE VERIFICACIÓN (CHECKPOINTS) Cuando ocurre una falla en el sistema es necesario consultar la bitácora para determinar cuáles son las transacciones que necesitan volver a hacerse y cuando no necesitan hacerse. Estos puntos de verificación nos ayudan para reducir el gasto de tiempo consultando la bitácora. El punto de verificación es un registro que se genera en la bitácora 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 búsqueda en la bitácora. Al disparar un checkpoint el sistema realiza la siguiente secuencia de acciones:   

Grabar en memoria estable todos los registros de bitácora que están en memoria principal. Grabar en disco los bloques modificados de los registros intermedios (buffer). Grabar un registro de bitácora en memoria estable.

La operación de recuperación 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 verificación (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 verificación y un UNDO tiene que regresar al punto de verificación más inmediato anterior. La colocación de puntos de verificación 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 bitácora para ver cuales transacciones deben rehacerse y cuales deshacerse. Pasos a seguir ante fallos:


PÁGINA 19

REDES Y SISTEMAS DISTRIBUIDOS / Bases De Datos Distribuidas 

Para cada transacción Ti tal que aparece en la bitácora el registro antes del registro, no es necesario ejecutar un REDO.



Después de un fallo, se examina la bitácora para determinar cuál fue la última transacción Ti que comenzó a ejecutarse antes del último checkpoint.

Esto se hace examinando la bitácora hacia atrás buscando el primer registro y cuál es el registro más 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 bitácora periódicamente 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 básico un agente (un agente-DTM en el modelo) con un rol especial. Este es llamado el coordinador; todos los demás agentes que deben hacer commit a la vez son llamados participantes. El coordinador es responsable de tomar la decisión de llevar a cabo un commit o abort finalmente. Cada participante corresponde a una subtransacción la cual ha realizado alguna acción 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 básica del 2PC es determinar una decisión ú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 decisión común.  La meta de la segunda fase es implementar esta decisión.

El protocolo procede como sigue:  

FASE UNO:



Cada participante escribe “ready” (y registra las subtransacciones) en su propia bitácora si está listo o “abort” d e lo contrario.



Cada participante responde con un mensaje READY o ABORT al coordinador. El coordinador decide el commit o abort en la transacción 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 transacción.



El coordinador escribe “prepare” en la bitácora y envía un mensaje donde

pregunta a todos los participantes si preparan el commit (PREPARE).


PÁGINA 20


 

FASE DOS: El coordinador registra la decisión tomada en almacenamiento estable; es decir, escribe “global_commit” o “global_abort” en la bitácora.

 

 



El coordinador envía mensaje de COMMIT o ABORT según sea el caso para su ejecución. Todos los participantes escriben un commit o abort en la bitácora basados en el mensaje recibido del coordinador (desde este momento el procedimiento de recuperación es capaz de asegurar que el efecto de la subtransacción no será perdido).

FINALMENTE: Todos los participantes envían un mensaje de acuse de recibo (ACK) al coordinador, y ejecutan las acciones requeridas para terminar (commit) o abortar (abort) la subtransacción. Cuando el coordinador ha recibido un mensaje ACK de todos los participantes, escribe un nuevo tipo de registro en la bitácora, llamado un registro “completo”.


PÁGINA 21

UNIDAD 4 Recuperacion de Informacion en Ambientes de BDD ANTOLOGIA.docx

Recommend Documents