DBMS distribuido - Fallo y compromiso
Un sistema de administración de bases de datos es susceptible a una serie de fallas. En este capítulo estudiaremos los tipos de fallas y los protocolos de confirmación. En un sistema de base de datos distribuida, las fallas pueden clasificarse ampliamente en fallas leves, fallas graves y fallas de red.
Fracaso suave
La falla de software es el tipo de falla que causa la pérdida en la memoria volátil de la computadora y no en el almacenamiento persistente. Aquí, la información almacenada en el almacenamiento no persistente como la memoria principal, búferes, cachés o registros se pierde. También se conocen como fallo del sistema. Los diversos tipos de fallas leves son los siguientes:
- Fallo del sistema operativo.
- Caída de la memoria principal.
- Error de transacción o aborto.
- Error generado por el sistema como desbordamiento de enteros o error de división por cero.
- Falla del software de soporte.
- Fallo de alimentación.
Fracaso duro
Una falla grave es el tipo de falla que causa la pérdida de datos en el almacenamiento persistente o no volátil, como el disco. La falla del disco puede causar corrupción de datos en algunos bloques de disco o falla en todo el disco. Las causas de una falla grave son:
- Fallo de alimentación.
- Fallos en los medios.
- Mal funcionamiento de lectura-escritura.
- Corrupción de información en el disco.
- Bloqueo del cabezal de lectura / escritura del disco.
La recuperación de fallas en el disco puede ser breve si hay un disco nuevo, formateado y listo para usar en reserva. De lo contrario, la duración incluye el tiempo que lleva obtener una orden de compra, comprar el disco y prepararlo.
Falla de red
Los fallos de red son frecuentes en las bases de datos distribuidas o de red. Estos comprenden los errores inducidos en el sistema de base de datos debido a la naturaleza distribuida de los datos y la transferencia de datos a través de la red. Las causas del fallo de la red son las siguientes:
- Fallo en el enlace de comunicación.
- Congestión en la red.
- Corrupción de la información durante la transferencia.
- Fallos del sitio.
- Partición de red.
Comprometer protocolos
Cualquier sistema de base de datos debe garantizar que las propiedades deseables de una transacción se mantengan incluso después de fallas. Si ocurre una falla durante la ejecución de una transacción, puede suceder que no se confirmen todos los cambios provocados por la transacción. Esto hace que la base de datos sea inconsistente. Los protocolos de confirmación evitan este escenario mediante el uso de deshacer transacciones (deshacer) o rehacer transacciones (avanzar).
Punto de compromiso
El momento en el que se toma la decisión de confirmar o abortar una transacción se conoce como punto de compromiso. A continuación se muestran las propiedades de un punto de compromiso.
Es un momento en el que la base de datos es coherente.
En este punto, las modificaciones provocadas por la base de datos pueden ser vistas por las otras transacciones. Todas las transacciones pueden tener una vista coherente de la base de datos.
En este punto, todas las operaciones de transacción se han ejecutado con éxito y sus efectos se han registrado en el registro de transacciones.
En este punto, una transacción se puede deshacer de forma segura, si es necesario.
En este punto, una transacción libera todos los bloqueos que tiene.
Deshacer transacción
El proceso de deshacer todos los cambios realizados en una base de datos mediante una transacción se denomina deshacer una transacción o deshacer una transacción. Esto se aplica principalmente en caso de falla leve.
Rehacer transacción
El proceso de volver a aplicar los cambios realizados en una base de datos mediante una transacción se denomina rehacer de transacción o avance de transacción. Esto se aplica principalmente para recuperarse de una falla grave.
Registro de transacciones
Un registro de transacciones es un archivo secuencial que realiza un seguimiento de las operaciones de transacción en los elementos de la base de datos. Dado que el registro es de naturaleza secuencial, se procesa secuencialmente desde el principio o desde el final.
Propósitos de un registro de transacciones -
- Para admitir protocolos de confirmación para confirmar o respaldar transacciones.
- Para ayudar a la recuperación de la base de datos después de una falla.
Por lo general, se guarda un registro de transacciones en el disco para que no se vea afectado por fallas leves. Además, el registro se respalda periódicamente en un almacenamiento de archivo como una cinta magnética para protegerlo también de fallas en el disco.
Listas en registros de transacciones
El registro de transacciones mantiene cinco tipos de listas según el estado de la transacción. Esta lista ayuda al administrador de recuperación a determinar el estado de una transacción. El estado y las listas correspondientes son los siguientes:
Una transacción que tiene un registro de inicio de transacción y un registro de confirmación de transacción, es una transacción confirmada, mantenida en la lista de confirmaciones.
Una transacción que tiene un registro de inicio de transacción y un registro de transacción fallida, pero no un registro de cancelación de transacción, es una transacción fallida, mantenida en la lista fallida.
Una transacción que tiene un registro de inicio de transacción y un registro de cancelación de transacción es una transacción cancelada, mantenida en la lista de cancelaciones.
Una transacción que tiene un registro de inicio de transacción y un registro de transacción antes de la confirmación es una transacción antes de la confirmación, es decir, una transacción en la que todas las operaciones se han ejecutado pero no confirmado, mantenido en la lista antes de la confirmación.
Una transacción que tiene un registro de inicio de transacción pero no registros de antes de comprometerse, confirmar, abortar o fallar, es una transacción activa, mantenida en la lista activa.
Actualización inmediata y actualización diferida
La actualización inmediata y la actualización diferida son dos métodos para mantener registros de transacciones.
En immediate updatemodo, cuando se ejecuta una transacción, las actualizaciones realizadas por la transacción se escriben directamente en el disco. Los valores antiguos y los valores de las actualizaciones se escriben en el registro antes de escribir en la base de datos en el disco. En la confirmación, los cambios realizados en el disco se vuelven permanentes. En la reversión, los cambios realizados por la transacción en la base de datos se descartan y los valores antiguos se restauran en la base de datos a partir de los valores antiguos almacenados en el registro.
En deferred updatemodo, cuando se ejecuta una transacción, las actualizaciones realizadas a la base de datos por la transacción se registran en el archivo de registro. En la confirmación, los cambios en el registro se escriben en el disco. En la reversión, los cambios en el registro se descartan y no se aplican cambios a la base de datos.