Universidad Veracruzana.Lic. En Sistemas Computacionales Administrativos.

Asignatura:Bases de Datos

Profesor:Luis Alberto López Cámara

Tema:Técnicas de recuperación de bases de datos

Numero de equipo:3

Integrantes de equipo:Gisela Padilla Bautista

Miguel Ángel García PimentelMarcos Alberto Díaz Rosas

Roberto Estrada OrozcoGerson García Mora

1 de Abril del 2011

Introducción.................................................................................................................................2

Técnicas de recuperación de bases de datos...............................................................................2

Recuperación basada en el registro histórico...............................................................................3

Modificación diferida de la base de datos....................................................................................3

Modificación inmediata de la base de datos................................................................................6

Puntos de revisión........................................................................................................................7

Técnicas de recuperación en sistemas de multibases de datos...................................................8

Interacción con el control de concurrencia..............................................................................8

Retroceso de transacciones.....................................................................................................9

Puntos de revisión....................................................................................................................9

Recuperación al reiniciar..........................................................................................................9

Conclusión..................................................................................................................................13

Bibliografía.................................................................................................................................14

Introducción.

Este trabajo abordara que es una recuperación de bases de datos, así como cuáles son las técnicas más usadas. Para lo cual analizaremos los pros y los contras de cada una de ellas. Y por último se analizaran la forma de hacer respaldos remotos de una base de datos, en caso de fallas catastróficas.

Técnicas de recuperación de bases de datos.

Una computadora, al igual que cualquier otro dispositivo eléctrico o mecánico, está sujeta a fallos. Éstos se producen por diferentes motivos como: fallos de disco, cortes de corriente, errores en el software, un incendio en la habitación de la computadora o incluso sabotaje. En cada uno de estos casos puede perderse información. Por tanto, el sistema de bases de datos debe realizar con anticipación acciones que garanticen que las propiedades de atomicidad y durabilidad de las transacciones, se preservan a pesar de tales fallos. Una parte integral de un sistema de bases de datos es un esquema de recuperación, el cual es responsable de la restauración de la base de datos al estado consistente previo al fallo. El esquema de recuperación también debe proporcionar alta disponibilidad; esto es, debe minimizar el tiempo durante el que la base de datos no se puede usar después de un fallo.

Una recuperación de bases de datos consisten en devolver a la base de datos a un estado consistente y con la menor pérdida de información y tiempo posible, en la cual se incluyen acciones durante el proceso normal de transacciones, y acciones después de un fallo.

Recuperación basada en el registro histórico.

La estructura más ampliamente utilizada para guardar las modificaciones de una base de datos es el registro histórico. El registro histórico es una secuencia de registros que mantiene un registro de todas las actividadesde actualización de la base de datos. Existen varios tipos de registros del registro histórico. Un registro de actualización del registro histórico describe una única escritura en la base de datos y tiene los siguientes campos:• El identificador de la transacción es un identificador único de la transacción que realiza la operación escribir.• El identificador del elemento de datos es un identificador único del elemento de datos que se escribe. Normalmente suele coincidir con la ubicación del elemento de datos en el disco.• El valor anterior es el valor que tenía el elemento de datos antes de la escritura.• El valor nuevo es el valor que tendrá el elemento de datos después de la escritura.

Existen otros registros del registro histórico especiales para registrar sucesos significativos durante el procesamiento de una transacción, tales como el comienzo de una transacción y el éxito o aborto de la misma. Denotaremoscomo sigue los diferentes tipos de registros del registro histórico:• <Ti iniciada>. La transacción Ti ha comenzado.• <Ti, Xj, V1, V2>. La transacción Ti ha realizado una escritura sobre el elemento de datos Xj. Xj tenía el valor V1 antes de la escritura y tendrá el valor V2 después de la escritura.• <Ti comprometida>. La transacción Ti se ha comprometido.• <Ti abortada>. La transacción Ti ha sido abortada.Cuando una transacción realiza una escritura es fundamental que se cree el registro del registro histórico correspondiente a esa escritura antes de modificar la base de datos. Una vez que el registro del registro histórico existe, se puede realizar la salida de la modificación a la base de datos si se desea. Además, es posible deshacer una modificación que ya haya salido a la base de datos. Se deshará utilizando el campo valor-anterior de los registros del registro histórico.Para que los registros del registro histórico sean útiles para recuperarse frente a errores del disco o del sistema, el registro histórico debe residir en almacenamiento estable. Obsérvese que en el registro histórico se tiene constancia de todas las actividades de la base de datos. Como consecuencia, el tamaño de los datos almacenados en el registro histórico puede llegar a ser extremadamentegrande.

Modificación diferida de la base de datos.

La técnica de la modificación diferida garantiza la atomicidad de las transacciones mediante el almacenamiento de todas las modificaciones de la base de datos en el registro histórico, pero retardando la ejecución de todas las operaciones escribir de una transacción hasta que la transacción se compromete parcialmente. Recuérdese que se dice que una transacción se compromete parcialmente una vez que se ejecuta la acción final de la transacción. En la versión de la técnica de modificación diferida que se describe en este apartado se supone que las transacciones se ejecutan secuencialmente.Cuando una transacción se compromete parcialmente, la información del registro histórico asociada a esa transacción se utiliza para la ejecución de las escrituras diferidas. Si el sistema cae antes de que la transacción complete su ejecución o si la transacción aborta, la información del registro histórico simplemente se ignora.La ejecución de una transacción Ti opera de esta manera: antes de que Ti comience su ejecución se escribe en el registro histórico un registro <Ti iniciada>. Una operación escribir(X) realizada por Ti se traduce en la escritura de un nuevo registro en el registro histórico. Finalmente, cuando Ti se ha comprometido parcialmente, se escribe en el registro histórico un registro<Ti comprometida>.Cuando Ti se compromete parcialmente, los registros asociados a ella en el registro histórico se utilizan para la ejecución de las escrituras diferidas. Como puede ocurrir un fallo mientras se lleva a cabo esta actualización, hay que asegurarse de que, antes del comienzo de estas actualizaciones, todos los registros del registro histórico se guardan en almacenamiento estable. Una vez que se ha hecho esto, la actualización real tiene lugar y la transacción pasa al estado comprometido. Obsérvese que la técnica de modificación diferida sólo requiere el nuevo valor de los elementos de datos.

Para ilustrar esto considere un sistema bancario simple. Sea T0 una transacción que transfiere 50 € desde la cuenta A a la cuenta B. Esta transacción se define de la manera siguiente:T0 : leer(A)A := A – 50escribir(A)leer(B)B := B + 50Escribir(B)Sea T1 una transacción que retira 100 € de la cuenta C.Esta transacción se define comoT1 : leer(C)C := C – 100Escribir(C)Supongamos que estas transacciones se ejecutan secuencialmente, primero T0

y después T1, y que los saldos de las cuentas A, B y C antes de producirse la ejecución eran 1.000, 2.000 y 700 € respectivamente. El fragmento del registro histórico que contiene la información relevante sobre estas dos transacciones se muestra a continuación.

<T0 iniciada>

<T0, A, 950><T0, B, 450><T0 comprometida><T1 iniciada><T1, C, 1100><T1 comprometida>

Las salidas reales que se producen en el sistema de bases de datos y en el registro histórico como consecuencia de la ejecución de T0 y T1 pueden seguir distintas ordenaciones. Una ordenación posible es la siguiente.

Registro histórico Base de datos

<T0 iniciada> <T0, A, 950><T0, B, 2050><T0 comprometida> A = 950 B = 2050 <T1 iniciada><T1, C, 600><T1 comprometida> C = 600

Nótese que el valor de A se cambia en la base de datos sólo después de que el registro <T0, A, 950> se haya introducido en el registro histórico.Mediante la utilización del registro histórico, el sistema puede manejar cualquier fallo que conduzca a la pérdida de información en el almacenamiento volátil.El esquema de recuperación usa el siguiente procedimiento de recuperación:• Rehacer (Ti) fija el valor de todos los elementos de datos actualizados por la transacción Ti a los valores nuevos.El conjunto de elementos de datos actualizados por Ti y sus respectivos nuevos valores se encuentran en el registro histórico.

La operación rehacer debe ser idempotente, esto es, el resultado de ejecutarla varias veces debe ser equivalente al resultado de ejecutarla una sola vez. Esta característica es fundamental para garantizar un correcto comportamiento incluso si el fallo se produce durante el proceso de recuperación.Después de ocurrir un fallo, el subsistema de recuperación consulta el registro histórico para determinar las transacciones que deben rehacerse. Una transacción Ti debe rehacerse si y sólo si el registro histórico contiene los registros <Ti iniciada> y <Ti comprometida>. Así, si el sistema cae después de que la transacción complete su ejecución, la información en el registro histórico se utiliza para restituir el sistema a un estado consistente anterior.

Modificación inmediata de la base de datos.

La técnica de modificación inmediata permite realizar la salida de las modificaciones de la base de datos a la propia base de datos mientras que la transacción está todavía en estado activo. Las modificaciones de datos escritas por transacciones activas se denominan modificaciones no comprometidas. En caso de una caída o de un fallo en la transacción, el sistema debe utilizar el campo para el valor anterior de los registros del registro histórico para restaurar los elementos de datos modificados a los valores que tuvieran antes de comenzar la transacción. Esta restauración se lleva a cabo mediante la operación deshacer descrita a continuación.Antes de comenzar la ejecución de una transacción Ti, se escribe en el registro histórico el registro <Ti iniciada>. Durante su ejecución, cualquier operación escribir (X) realizada por Ti, es precedida por la escritura en el registro histórico de un registro actualizado apropiado. Cuando Ti se compromete parcialmente se escribe en el registro histórico el registro <Ti comprometida>. Como la información del registro histórico se utiliza para reconstruir el estado de la base de datos, la actualización real de la base de datos no puede permitirse antes de que el registro del registro histórico correspondiente se haya escrito en almacenamiento estable. Por lo tanto, es necesario que antes de la ejecución de una operación de salida (B), se escriban en almacenamiento estable los registros del registro histórico correspondientes a B.Para ilustrarlo considérese de nuevo el sistema bancario simple con la ejecución ordenada de las transacciones T0 y T1, primero T0 y después T1. Las líneas del registro histórico que contienen la información relevante concerniente a estas dos transacciones se muestran a continuación. <T0 iniciada><T0, A, 1000, 950><T0, B, 2000, 2050><T0 comprometida><T1 iniciada><T1, C, 700, 600><T1 comprometida>

En la siguiente figura se describe una posible ordenación de las salidas reales que se producen en el sistema de bases de datos y en el registro histórico como consecuencia de la ejecución de T0 y T1. Nótese que esta ordenación no podría obtenerse con la técnica de modificación diferida.Mediante la utilización del registro histórico, el sistema puede manejar cualquier fallo que no genere una pérdida de información en el almacenamiento no volátil.El esquema de recuperación usa dos procedimientos de recuperación:• deshacer (Ti) restaura el valor de todos los elementos de datos actualizados por la transacción Ti a los valores anteriores.• rehacer (Ti) fija el valor de todos los elementos de datos actualizados por la transacción Ti a los nuevos valores.El conjunto de elementos de datos actualizados por Ti y sus respectivos anteriores y nuevos valores se encuentran en el registro histórico.

Las operaciones deshacer y rehacer deben ser idempotentes para garantizar un comportamiento correcto incluso en el caso de que el fallo se produzca durante el proceso de recuperación.Después de haberse producido un fallo, el esquema de recuperación consulta el registro histórico para determinar las transacciones que deben rehacerse y las que deben deshacerse.• Una transacción Ti debe deshacerse si el registro histórico contiene el registro <Ti iniciada>, pero no contiene el registro <Ti comprometida>.• Una transacción Ti debe rehacerse si el registro histórico contiene los registros <Ti iniciada> y <Ti comprometida>.

Puntos de revisión.

El registro histórico para determinar las transacciones que deben rehacerse y las que deben deshacerse. En principio es necesario recorrer completamente el registro histórico para hallar esta información. En este enfoque hay dos inconvenientes principales:1. El proceso de búsqueda consume tiempo.2. La mayoría de las transacciones que deben rehacerse de acuerdo con el algoritmo ya tienen escritas sus actualizaciones en la base de datos. Aunque el hecho de volver a ejecutar estas transacciones no produzca resultados erróneos, sí repercutirá en un aumento del tiempo de ejecución del proceso de recuperación.Para reducir este tipo de sobrecarga se introducen los puntos de revisión. Durante la ejecución, el sistema actualiza el registro histórico utilizando una de dos técnicas. Además, el sistema realiza periódicamente puntos de revisión, en los cuales tiene lugar la siguiente secuencia de acciones:1. Escritura en almacenamiento estable de todos los registros del registro histórico que residan en ese momento en memoria principal.2. Escritura en disco de todos los bloques de memoria intermedia que se hayan modificado.3. Escritura en almacenamiento estable de un registro del registro histórico <revisión>.Mientras se lleva a cabo un punto de revisión no se permite que ninguna transacción realice acciones de actualización, tales como escribir en un bloque de memoria intermedia o escribir un registro del registro histórico.La presencia de un registro <revisión> en el registro histórico permite que el sistema pueda hacer más eficiente su procedimiento de recuperación. Considérese una transacción Ti que se comprometió antes del punto de revisión. Para esa transacción el registro <Ti comprometida> aparece en el registro histórico antes que el registro <revisión>. Todas las modificaciones sobre la base de datos hechas por Ti se deben haber escrito en la base de datos antes del punto de revisión o formando parte del propio punto de revisión. Así, en el momento de la recuperación, no es necesario ejecutar una operación rehacer sobre Ti. Esta observación permite perfeccionar los esquemas anteriores de recuperación (sigue siendo válido el supuesto de que las transacciones se ejecutan secuencialmente).

Cuando se produce un fallo, el esquema de recuperación examina el registro histórico para determinar la última transacción Ti que comenzó su ejecución antes de que tuviera lugar el último punto de revisión. Para encontrar una transacción de este tipo se recorre el registro histórico hacia atrás, esto es, se empieza a buscar por el final del registro histórico hasta que se encuentra el primer registro <revisión> (como se va recorriendo el registro histórico hacia atrás, el registro encontrado corresponde al último registro <revisión> del registro histórico); después se continúa la búsqueda hacia atrás hasta que se encuentra el siguiente registro <Ti iniciada>. Este registro identifica a la transacción Ti.Una vez que ha sido identificada la transacción Ti sólo es necesario aplicar las operaciones rehacer y deshacer a la transacción Ti y a las transacciones Tj que comenzaron su ejecución después que Ti. Sea T este conjunto de transacciones. Puede ignorarse el resto del registro histórico (la parte del principio) y puede borrarse cuando se desee. El conjunto exacto de operaciones de recuperación que han de llevarse a cabo depende de si se está usando la técnica de modificación inmediata o la de modificación diferida.Si se emplea la técnica de modificación inmediata, las operaciones de recuperación deben ser las siguientes:• Ejecutar deshacer (Tk) para todas las transacciones Tk de T para las que no exista un registro <Tk comprometida> en el registro histórico.• Ejecutar rehacer (Tk) para todas las transacciones Tk de T para las que aparece un registro <Tk comprometida> en el registro histórico.Obviamente no es necesario aplicar la operación rehacer cuando se está utilizando la técnica de modificación diferida.

Técnicas de recuperación en sistemas de multibases de datos.

Interacción con el control de concurrenciaEl esquema recuperación depende en gran medida del esquema de control de concurrencia que se use. Para retroceder los efectos de una transacción fallida deben deshacerse las modificaciones realizadas por esa transacción.Supóngase que se debe retroceder una transacción T0 y que un dato Q, que fue modificado por T0, tiene que recuperar su antiguo valor. Si se está usandoun esquema basado en registro histórico para la recuperación, es posible restablecer el valor de Q utilizando la información contenida en el registro histórico.Supóngase ahora que una segunda transacción T1 realiza una nueva modificación sobre Q antes de retroceder T0. En este caso, al retroceder T0, se perdería la modificación realizada por T1. Es necesario, por tanto, que si una transacción T modifica el valor de un elemento de datos Q, ninguna otra transacción pueda modificar el mismo elemento de datos hasta que T se haya comprometido o se haya retrocedido.Este requisito puede satisfacerse fácilmente utilizando bloqueo estricto de dos fases, esto es, bloqueo de dos fases manteniendo bloqueos exclusivos hasta el final de la transacción.

Retroceso de transaccionesSe utiliza el registro histórico para retroceder una transacción Ti fallida. El registro histórico se explora hacia atrás; para cada registro del registro histórico de la forma <Ti, Xj, V1, V2>, se restablece el valor del elemento de datos Xj con su valor anterior: V1. La exploración del registro histórico termina cuando se encuentra el registro <Ti iniciada>.Es importante el hecho de recorrer el registro histórico empezando por el final, ya que una transacción puede haber actualizado más de una vez el valor de un elemento de datos. Como ejemplo, considérese este par de registros:<Ti, A, 10, 20><Ti, A, 20, 30>Estos registros del registro histórico representan una modificación del elemento de datos A por parte de la transacción Ti, seguida de otra modificación de A hecha también por Ti. Al recorrer el registro histórico al revés se establece correctamente el valor de A como 10. Si el registro histórico se recorriera hacia delante, A tomaría como valor 20, lo cual es incorrecto. Si para el control de concurrencia se utiliza el bloqueo estricto de dos fases, los bloqueos llevados a cabo por una transacción T sólo pueden ser desbloqueados después de que la transacción se haya retrocedido según se acaba de describir. Una vez que T (que se está retrocediendo) haya actualizado un elemento de datos, ninguna otra transacción podría haber actualizado el mismo elemento de datos debido a los requisitos del control de. Así pues, la restitución del valor anterior de un elemento de datos no borrará los efectos de otra transacción.

Puntos de revisión.Cuando las transacciones pueden ejecutarse concurrentemente, la situación se torna más complicada ya que varias transacciones pueden estar activas en el momento en que se produce el último punto de revisión. En un sistema de procesamiento de transacciones concurrente es necesario que el registro del registro histórico correspondiente a un punto de revisión sea de la forma <revisión L>, donde L es una lista con las transacciones activas en el momento del punto de revisión. De nuevo se supone que, mientras que se realiza el punto de revisión, las transacciones no efectúan modificaciones ni sobre los bloques de la memoria intermedia ni sobre el registro histórico.El requisito de que las transacciones no puedan realizar modificaciones sobre los bloques de la memoria intermedia ni sobre el registro histórico durante un punto de revisión puede resultar molesto, ya que el procesamiento de transacciones tendrá que parar durante la ejecución de un punto de revisión. Un punto de revisión durante el cual se permite que las transacciones realicen modificaciones incluso mientras los bloques de memoria intermedia se están guardando en disco, se denomina punto de revisión difuso.

Recuperación al reiniciar.El sistema construye dos listas cuando se recupera de una caída: la lista-deshacer, que consta de las transacciones que han de deshacerse, y la lista-rehacer, que está formada por las transacciones que deben rehacerse.Estas dos listas se construyen durante la recuperación de la siguiente manera. Al principio ambas están vacías. Luego se recorre el registro histórico hacia

atrás examinando cada registro hasta que se encuentra el primer registro <revisión>:• Para cada registro encontrado de la forma <Ti comprometida>, se añade Ti a la lista-rehacer.• Para cada registro encontrado de la forma <Ti iniciada>, si Ti no está en la lista-rehacer, entonces se añade Ti a la lista-deshacer.Una vez que se han examinado los registros apropiados del registro histórico, se atiende al contenido de la lista L en el registro punto de revisión. Para cada transacción Ti en L, si Ti no está en la lista-rehacer, entonces se añade Ti a la lista-deshacer.Cuando se terminan la lista-rehacer y la lista-deshacer, el proceso de recuperación procede de la siguiente manera:1. Se recorre de nuevo el registro histórico hacia atrás comenzando en el último registro y se realiza una operación deshacer por cada registro del registro histórico que pertenezca a una transacción Ti de la lista-deshacer. En esta fase se ignoran los registros del registro histórico concernientes a transacciones de la lista-rehacer. El recorrido del registro histórico termina cuando se encuentran registros <Ti iniciada> para cada transacción Ti de la lista-deshacer.2. Se localiza el último registro <revisión L> del registro histórico. Nótese que este paso puede necesitar de un recorrido del registro histórico hacia delante si el registro punto de revisión quedó atrás en el paso 1.3. Se recorre el registro histórico hacia delante desde el último registro <revisión L> y se realiza una operación rehacer por cada registro del registro histórico que pertenezca a una transacción Ti de la lista-rehacer. En esta fase se ignoran los registros del registro histórico concernientes a transacciones de la lista-deshacer.Es importante procesar el registro histórico hacia atrás en el paso 1 para garantizar que el estado resultante de la base de datos sea correcto. Después de haber deshecho todas las transacciones de la lista-deshacer se rehacen aquellas transacciones que pertenezcan a la lista-rehacer. En este caso es importante procesar el registro histórico hacia delante. Cuando se ha completado el proceso de recuperación, se continúa con el procesamiento normal de las transacciones. Es importante el hecho de deshacer las transacciones de la lista-deshacer antes de rehacer las transacciones de la lista-rehacer al utilizar los pasos 1 a 3 del algoritmo anterior. El siguiente problema podría ocurrir de no hacerse así. Supóngase que el elemento de datos A vale inicialmente 10. Supóngase también que una transacción Ti modifica el valor de A situándolo en 20 y aborta a continuación; el retroceso de la transacción devolvería a A el valor 10. Supóngase que otra transacción Tj cambia entonces a 30 el valor de A, se compromete y, seguidamente, el sistema cae. El estado del registro histórico en el momento de la caída es:<Ti, A, 10, 20><Tj, A, 10, 30><Tj comprometida>Si se rehace primero, A tomará el valor 30; y luego, al deshacer, A acabará valiendo 10, lo cual es incorrecto. El valor final de A debe ser 30, lo que puede garantizarse si se deshace antes de rehacer.

Sistemas remotos de copias de seguridad.

Los sistemas tradicionales de procesamiento de transacciones son sistemas centralizados o sistemas cliente-servidor. Esos sistemas son vulnerables frente a desastres ambientales como el fuego, las inundaciones o los terremotos. Hay una necesidad creciente de sistemas de procesamiento de transacciones que ofrezcan una disponibilidad elevada y que puedan funcionar pese a los desastres ambientales. Estos sistemas deben proporcionar una disponibilidad elevada, es decir, el tiempo en que el sistema no es utilizable debe ser extremadamente pequeño.Se puede obtener una disponibilidad elevada realizando el procesamiento de transacciones en un solo sitio, denominado sitio principal, pero tener un sitio remoto copia de seguridad, en el que se repliquen todos los datos del sitio principal. El sitio remoto copia de seguridad se denomina también a veces sitio secundario. El sitio remoto debe mantenerse sincronizado con el sitio principal, ya que las actualizaciones se realizan en el sitio principal. La sincronización se obtiene enviando todos los registros del registro histórico desde el sitio principal al sitio remoto copia de seguridad. El sitio remoto copia de seguridad debe hallarse físicamente separado del principal —por ejemplo, se puede ubicar en otra provincia— para que una catástrofe en el sitio principal no afecte al sitio remoto copia de seguridad.Cuando falla el sitio principal, el sitio remoto copia de seguridad asume el procesamiento. En primer lugar, sin embargo, lleva a cabo la recuperación utilizando su copia (tal vez anticuada) de los datos del sitio principal y los registros del registro histórico recibidos del mismo. En realidad, el sitio remoto copia de seguridad lleva a cabo acciones de recuperación que se hubieran llevado a cabo en el sitio principal cuando éste se hubiera recuperado. Se pueden utilizar los algoritmos estándar de recuperación para la recuperación en el sitio remoto copia de seguridad con pocas modificaciones. Una vez realizada la recuperación, el sitio remoto copia de seguridad comienza a procesar transacciones. La disponibilidad aumenta mucho en comparación con los sistemas con un solo sitio, dado que el sistema puede recuperarse aunque se pierdan todos los datos del sitio principal. El rendimiento de los sistemas remotos para copias de seguridad es mejor que el de los sistemas distribuidos con compromiso de dos fases. Varios aspectos que deben abordarse al diseñar sistemas remotos para copias de seguridad son los siguientes: • Detección de fallos. Al igual que en los protocolos para el manejo de fallos en sistemas distribuidos, es importante que el sistema remoto de copia de seguridad detecte que el sitio principal ha fallado. El fallo de las líneas de comunicación puede hacer creer al sitio remoto copia de seguridad que el sitio principal ha fallado. Para evitar este problema hay que mantener varios enlaces de comunicaciones con modos de fallo independientes entre el sitio principal y el sitio remoto copia de seguridad. Por ejemplo, además de la conexión de red puede haber otra conexión mediante módem por línea telefónica con servicio suministrado por diferentes compañías de telecomunicaciones. Estas conexiones pueden complementarse con la intervención manual de operadores, que se pueden comunicar por sistema telefónico.• Transferencia del control. Cuando el sitio principal falla, el sitio copia de seguridad asume el procesamiento y se transforma en el nuevo sitio principal.

Cuando el sitio principal original se recupera puede desempeñar el papel de sitio remoto copia de seguridad o volver a asumir el papel de sitio principal. En cualquiera de los casos, el sitio principal antiguo debe recibir un registro histórico de actualizaciones realizado por el sitio copia de seguridad mientras el sitio principal antiguo estaba fuera de servicio.La manera más sencilla de transferir el control es que el sitio principal antiguo reciba el registro histórico de operaciones rehacer del sitio copia de seguridad antiguo y se ponga al día con las actualizaciones aplicándolas de manera local.El sitio principal antiguo puede entonces actuar como sitio remoto copia de seguridad. Si hay que devolver el control, el sitio remoto copia de seguridad antiguo puede simular que ha fallado, lo que da lugar a que el sitio principal antiguo asuma el control.• Tiempo de recuperación. Si el registro histórico del sitio remoto copia de seguridad se hace grande, la recuperación puede tardar mucho. El sitio remoto copia de seguridad puede procesar de manera periódica los registros rehacer del registro histórico que haya recibido y realizar un punto de revisión de manera que se puedan borrar las partes más antiguas del registro histórico. Como consecuencia se puede reducir el retraso antes de que el sitio remoto copia de seguridad asuma el control. Una configuración de relevo en caliente puede hacer la toma del control por el sitio copia de seguridad casi instantáneo. En esta configuración el sitio remoto copia de seguridad procesa los registros rehacer del registro histórico según llegan, y aplica las actualizaciones de manera local. Tan pronto como se detecta el fallo del sitio principal, el sitio copia de seguridad completa la recuperación retrocediendo las transacciones incompletas y queda preparado para procesar las nuevas.• Tiempo de compromiso. Para asegurar que las actualizaciones de una transacción comprometida sean duraderas no se debe declarar comprometida una transacción hasta que sus registros del registro histórico hayan alcanzado el sitio copia de seguridad. Este retraso puede dar lugar a una espera más prolongada para comprometer la transacción y, en consecuencia, algunos sistemas permiten grados inferiores de durabilidad. Los grados de durabilidad pueden clasificarse de la manera siguiente. – Uno seguro. Las transacciones se comprometen tan pronto como sus registros de compromiso del registro histórico se escriben en un almacenamiento estable en el sitio principal. El problema de este esquema es que puede que las actualizaciones de una transacción comprometida no hayan alcanzado el sitio copia de seguridad cuando éste asuma el control del procesamiento.Por tanto, puede parecer que las actualizaciones se han perdido. Cuando se recupere el sitio principal, las actualizaciones perdidas no se pueden mezclar directamente, dado que pueden entrar en conflicto con actualizaciones posteriores llevadas a cabo en el sitio copia de seguridad. Por tanto, puede que se necesite la intervención humana para devolver a la base de datos a un estado consistente.– Dos muy seguro. Las transacciones se comprometen tan pronto como sus registros de compromiso del registro histórico se escriben en un almacenamiento estable en el sitio principal y en el sitio copia de seguridad.El problema de este esquema es que el procesamiento de transacciones no puede continuar si alguno de los puntos no está operativo. Por tanto, la

disponibilidad es realmente menor que en el caso de un solo sitio, aunque la posibilidad de la pérdida de datos es mucho más reducida.– Dos seguro. Este esquema es idéntico al esquema dos muy seguro si tanto el sitio principal como el sitio copia de seguridad están activos. Si sólo está activo el sitio principal se permite que la transacción se comprometa tan pronto como su registro de compromiso del registro histórico se escriba en un almacenamiento estable en el sitio principal.Este esquema proporciona mejor disponibilidad que el esquema dos muy seguro al tiempo que evita el problema de las transacciones perdidas afrontado por el esquema uno seguro. Da lugar a un compromiso más lento que el esquema uno seguro pero las ventajas generalmente superan los inconvenientes. Varios sistemas comerciales de disco compartido proporcionan un nivel de tolerancia de fallos intermedio entre el de los sistemas centralizados y el de los sistemas remotos para copias de seguridad. En estos sistemas el fallo de una UCP no da lugar al fallo del sistema. En lugar de ello, otra UCP asume el control y lleva a cabo la recuperación. Las acciones de recuperación incluyen el retroceso de las transacciones que se ejecutaban en la UCP que falló y la recuperación de los bloqueos mantenidos por dichas transacciones. Dado que los datos se hallan en un disco compartido, no hace falta transferir registros del registro histórico. Sin embargo, se deberían proteger los datos contra el fallo del disco utilizando, por ejemplo, una organización de discos RAID.Una forma alternativa de conseguir alta disponibilidad es usar una base de datos distribuida con los datos replicados en más de un sitio. Son necesarias transacciones para actualizar todas las réplicas de cualquier elemento de datos que actualicen.

Conclusión.

El esquema de recuperación es una parte integrante del sistema de base de datos el cual es responsable de la detección de fallos y del restablecimiento de un estado de la base de datos anterior al momento de producirse el fallo.En los esquemas basados en registro histórico todas las modificaciones se escriben en el registro histórico, el cual debe estar guardado en almacenamiento estable.— En el esquema de modificación diferida, durante la ejecución de una transacción, se difieren todas las operaciones escribir hasta que la transacción se compromete parcialmente, momento en el que se utiliza la información del registro histórico asociada con la transacción para ejecutar las escrituras diferidas.— Con la técnica de modificación inmediata, todas las modificaciones se aplican directamente sobre la base de datos. Si ocurre una caída se utiliza la información del registro histórico para conducir a la base de datos a un estado estable previo.Puede usarse la técnica de los puntos de revisión para reducir la sobrecarga que conlleva la búsqueda en el registro histórico y rehacer las transacciones.

También debemos recordad que para recuperarse de los fallos que resultan en la pérdida de almacenamiento no volátil debe realizarse un volcado periódicamente (por ejemplo, una vez al día) del contenido entero de la base de datos en almacenamiento estable. Se usará el último volcado para devolver a la base de datos a un estado consistente previo cuando ocurra un fallo que conduzca a la pérdida de algún bloque físico de la base de datos. Una vez realizada esta operación se utilizará el registro histórico para llevar a la base de datos al estado consistente más reciente.Y finalmente con las nuevas tecnologías se han creado sistemas remotos de copia de seguridad que proporcionan un alto nivel de disponibilidad, permitiendo que continúe el procesamiento de transacciones incluso si se destruye el sitio primario por fuego, inundación o terremoto.

Bibliografía.

Fundamentos de bases de datos.Silberschatz, AbrahamEditorial Mc Graw HillCuarta edición