6.3 RESPALDO Y RECUPERACIÓN.
En la practica el empleo de volver a leer la entrada de una transacción o la restauración mediante imágenes posteriores dependen de la disponibilidad de una copia de respaldo de una versión anterior de la base de datos. Si las versiones se utilizan como copias de respaldos pueden construirse volviendo a posicionare la señal actual de nivel máximo de otra manera, los respaldos se crean por copiado. Es posible generar periodicamente copias de respaldo y conservar una serie de versiones anteriores. Cada copia de respaldo estará identificada por tiempo y fecha y por la última transacción incluida. Una copia de respaldo debe generarse mientras la base de datos esta en reposo, ya que las actualizaciones durante el copiado pueden provocar que la copia se inconsistente. En la base de datos muy grandes puede no presentarse nunca un periodo de descanso lo suficientemente largo para realizar una copia de respaldo.
RECUPERACIÓN.
A continuación se presentaran una serie de pasos que podrán seguirse cuando se presente una falla en el sistema y se desee recuperar la información:
Detección del error.- el proceso de recuperación se inicia al detectar la existencia de un error. Es posible distinguir una variedad de puntos de entrada en le proceso de recuperación. Se considerarán fallas de sistemas detectadas por falta de acción del sistema o por verificaciones irrecuperables de redundancia y salida incorrecta observada por un usuario.
Determinación de la fuente del error.- para decidir cual es la mejor acción correctora es necesario determinar la extensión del daño. Desde luego este esfuerzo es muy relacionado con la determinación del tiempo y la causa del error. Después de una caida o cuando el procesamiento sea interrumpido debido a una señal de error, es necesario determinar tantos aquellas áreas del archivo de datos que sean sospechosas como cuál fue la transacción que no se concluyo.
Ubicación de errores secundarios.- cuando se ha detectado un error que provocó una modificación inadecuada a un archivo un rastreo a traves de las listas de actividad encontrara aquellas transacciones que emplearon el bloque correcto. Entonces es posible volver a introducir automáticamente el bloque correcto de lñas transacciones afectadas y rpoducir resultados correctos. Si se actualizaron bloques mediante transacciones que leyeron bloques incorrectos antes de existir es necesario restaurar a un más el archivo.
Aplicación de correcciones. Si la extensión del daño es limitada, puede utilizarse un proceso de volver a enrollar. Las porciones dañadas del archivo se restauran aplicando primero aquellas imágenes anteriores a los bloques en error reemplazando después de las transacciones incompletas. La salida proveniente de estas trasacciones se suprime de ser posible, para evitar duplicar resusltados que previamente se hayan enviado a los usuarios.
En la practica el empleo de volver a leer la entrada de una transacción o la restauración mediante imágenes posteriores dependen de la disponibilidad de una copia de respaldo de una versión anterior de la base de datos. Si las versiones se utilizan como copias de respaldos pueden construirse volviendo a posicionare la señal actual de nivel máximo de otra manera, los respaldos se crean por copiado. Es posible generar periodicamente copias de respaldo y conservar una serie de versiones anteriores. Cada copia de respaldo estará identificada por tiempo y fecha y por la última transacción incluida. Una copia de respaldo debe generarse mientras la base de datos esta en reposo, ya que las actualizaciones durante el copiado pueden provocar que la copia se inconsistente. En la base de datos muy grandes puede no presentarse nunca un periodo de descanso lo suficientemente largo para realizar una copia de respaldo.
RECUPERACIÓN.
A continuación se presentaran una serie de pasos que podrán seguirse cuando se presente una falla en el sistema y se desee recuperar la información:
Detección del error.- el proceso de recuperación se inicia al detectar la existencia de un error. Es posible distinguir una variedad de puntos de entrada en le proceso de recuperación. Se considerarán fallas de sistemas detectadas por falta de acción del sistema o por verificaciones irrecuperables de redundancia y salida incorrecta observada por un usuario.
Determinación de la fuente del error.- para decidir cual es la mejor acción correctora es necesario determinar la extensión del daño. Desde luego este esfuerzo es muy relacionado con la determinación del tiempo y la causa del error. Después de una caida o cuando el procesamiento sea interrumpido debido a una señal de error, es necesario determinar tantos aquellas áreas del archivo de datos que sean sospechosas como cuál fue la transacción que no se concluyo.
Ubicación de errores secundarios.- cuando se ha detectado un error que provocó una modificación inadecuada a un archivo un rastreo a traves de las listas de actividad encontrara aquellas transacciones que emplearon el bloque correcto. Entonces es posible volver a introducir automáticamente el bloque correcto de lñas transacciones afectadas y rpoducir resultados correctos. Si se actualizaron bloques mediante transacciones que leyeron bloques incorrectos antes de existir es necesario restaurar a un más el archivo.
Aplicación de correcciones. Si la extensión del daño es limitada, puede utilizarse un proceso de volver a enrollar. Las porciones dañadas del archivo se restauran aplicando primero aquellas imágenes anteriores a los bloques en error reemplazando después de las transacciones incompletas. La salida proveniente de estas trasacciones se suprime de ser posible, para evitar duplicar resusltados que previamente se hayan enviado a los usuarios.
No hay comentarios:
Publicar un comentario