Recuperacion-Eq3

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 Pimentel
Marcos Alberto Díaz Rosas
Roberto Estrada Orozco
Gerson 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 actividades
de 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. Denotaremos
como 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 extremadamente
grande.
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 – 50
escribir(A)
leer(B)
B := B + 50
Escribir(B)
Sea T1 una transacción que retira 100 € de la cuenta C.
Esta transacción se define como
T1 : leer(C)
C := C – 100
Escribir(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 concurrencia
El 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á usando
un 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 transacciones
Se 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 listadeshacer, que consta de las transacciones que han de deshacerse, y la listarehacer, 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, Abraham
Editorial Mc Graw Hill
Cuarta edición