DBMS - Recuperación de datos
Recuperación de accidentes
DBMS es un sistema muy complejo con cientos de transacciones que se ejecutan cada segundo. La durabilidad y solidez de un DBMS depende de su arquitectura compleja y de su hardware y software de sistema subyacentes. Si falla o se bloquea en medio de las transacciones, se espera que el sistema siga algún tipo de algoritmo o técnicas para recuperar los datos perdidos.
Clasificación de fallas
Para ver dónde ha ocurrido el problema, generalizamos una falla en varias categorías, de la siguiente manera:
Error de transacción
Una transacción tiene que abortar cuando no se ejecuta o cuando llega a un punto en el que no puede continuar. Esto se denomina error de transacción cuando solo se ven afectadas unas pocas transacciones o procesos.
Las razones de una transacción fallida podrían ser:
Logical errors - Cuando una transacción no se puede completar porque tiene algún error de código o alguna condición de error interno.
System errors- Donde el propio sistema de base de datos termina una transacción activa porque el DBMS no puede ejecutarla, o tiene que detenerse debido a alguna condición del sistema. Por ejemplo, en caso de punto muerto o falta de disponibilidad de recursos, el sistema aborta una transacción activa.
Fallo del sistema
Hay problemas, externos al sistema, que pueden hacer que el sistema se detenga abruptamente y provoque un bloqueo. Por ejemplo, las interrupciones en el suministro de energía pueden causar la falla del hardware o software subyacente.
Los ejemplos pueden incluir errores del sistema operativo.
Fallo de disco
En los primeros días de la evolución de la tecnología, era un problema común donde las unidades de disco duro o unidades de almacenamiento solían fallar con frecuencia.
Las fallas del disco incluyen la formación de sectores defectuosos, la imposibilidad de acceder al disco, el bloqueo del cabezal del disco o cualquier otra falla, que destruye todo o parte del almacenamiento del disco.
Estructura de almacenamiento
Ya hemos descrito el sistema de almacenamiento. En resumen, la estructura de almacenamiento se puede dividir en dos categorías:
Volatile storage- Como sugiere su nombre, un almacenamiento volátil no puede sobrevivir a las fallas del sistema. Los dispositivos de almacenamiento volátiles se colocan muy cerca de la CPU; normalmente están incrustados en el propio chipset. Por ejemplo, la memoria principal y la memoria caché son ejemplos de almacenamiento volátil. Son rápidos pero solo pueden almacenar una pequeña cantidad de información.
Non-volatile storage- Estos recuerdos están hechos para sobrevivir a fallos del sistema. Tienen una enorme capacidad de almacenamiento de datos, pero más lentos en accesibilidad. Los ejemplos pueden incluir discos duros, cintas magnéticas, memoria flash y RAM no volátil (con respaldo de batería).
Recuperación y atomicidad
Cuando un sistema falla, es posible que se ejecuten varias transacciones y se abran varios archivos para modificar los elementos de datos. Las transacciones se realizan a partir de varias operaciones, que son de naturaleza atómica. Pero de acuerdo con las propiedades ACID del DBMS, se debe mantener la atomicidad de las transacciones en su conjunto, es decir, o se ejecutan todas las operaciones o ninguna.
Cuando un DBMS se recupera de un accidente, debe mantener lo siguiente:
Debería comprobar el estado de todas las transacciones que se estaban ejecutando.
Una transacción puede estar en medio de alguna operación; el DBMS debe garantizar la atomicidad de la transacción en este caso.
Debe comprobar si la transacción se puede completar ahora o si debe revertirse.
No se permitiría ninguna transacción para dejar el DBMS en un estado inconsistente.
Hay dos tipos de técnicas que pueden ayudar a un DBMS a recuperar y mantener la atomicidad de una transacción:
Mantener los registros de cada transacción y escribirlos en un almacenamiento estable antes de modificar la base de datos.
Mantener la paginación en la sombra, donde los cambios se realizan en una memoria volátil y, posteriormente, se actualiza la base de datos real.
Recuperación basada en registros
El registro es una secuencia de registros que mantiene los registros de las acciones realizadas por una transacción. Es importante que los registros se escriban antes de la modificación real y se almacenen en un medio de almacenamiento estable, que es seguro.
La recuperación basada en registros funciona de la siguiente manera:
El archivo de registro se guarda en un medio de almacenamiento estable.
Cuando una transacción ingresa al sistema y comienza su ejecución, escribe un registro sobre ella.
<Tn, Start>Cuando la transacción modifica un artículo X, escribe registros de la siguiente manera:
<Tn, X, V1, V2>Lee T n ha cambiado el valor de X, de V 1 a V 2 .
- Cuando finaliza la transacción, se registra:
<Tn, commit>La base de datos se puede modificar utilizando dos enfoques:
Deferred database modification - Todos los registros se escriben en el almacenamiento estable y la base de datos se actualiza cuando se confirma una transacción.
Immediate database modification- Cada registro sigue una modificación real de la base de datos. Es decir, la base de datos se modifica inmediatamente después de cada operación.
Recuperación con transacciones concurrentes
Cuando se ejecuta más de una transacción en paralelo, los registros se intercalan. En el momento de la recuperación, sería difícil para el sistema de recuperación retroceder todos los registros y luego comenzar a recuperarse. Para aliviar esta situación, la mayoría de los DBMS modernos utilizan el concepto de "puntos de control".
Control
Mantener y mantener registros en tiempo real y en un entorno real puede llenar todo el espacio de memoria disponible en el sistema. A medida que pasa el tiempo, el archivo de registro puede crecer demasiado para poder manipularse. Checkpoint es un mecanismo en el que todos los registros anteriores se eliminan del sistema y se almacenan permanentemente en un disco de almacenamiento. Checkpoint declara un punto antes del cual el DBMS estaba en un estado consistente y todas las transacciones fueron confirmadas.
Recuperación
Cuando un sistema con transacciones concurrentes falla y se recupera, se comporta de la siguiente manera:
El sistema de recuperación lee los registros al revés desde el final hasta el último punto de control.
Mantiene dos listas, una lista para deshacer y una lista para rehacer.
Si el sistema de recuperación ve un registro con <T n , Start> y <T n , Commit> o simplemente <T n , Commit>, coloca la transacción en la lista de rehacer.
Si el sistema de recuperación ve un registro con <T n , Inicio> pero no se encuentra ningún registro de confirmación o cancelación, coloca la transacción en la lista de deshacer.
Todas las transacciones de la lista de deshacer se deshacen y sus registros se eliminan. Todas las transacciones en la lista de rehacer y sus registros anteriores se eliminan y luego se rehacen antes de guardar sus registros.