4.

3 CONFIABILIDAD

Un sistema de manejo de bases de datos confiable es aquel que puede continuar

procesando las solicitudes de usuario aún cuando el sistema sobre el que opera
no es confiable. En otras palabras, aun cuando los componentes de un sistema
distribuido fallen, un DBMS confiable debe seguir ejecutando las solicitudes de
usuario sin violar la consistencia de la base de datos. La confiabilidad de un DBMS
se refiere a la atomicidad y durabilidad de las transacciones. El sistema sobre el
cual se ejecutan los mecanismos de control de concurrencia debe de ser
confiable.

PROPIEDADES:

ATOMICIDAD: Se refiere cuando las operaciones de una transacción se ejecutan

todas o ninguno.

DURABILIDAD: Después de que una transacción se ejecutó con éxito, los

cambios en la BD persisten, más allá de las fallas del sistema.

La confiabilidad se refiere a la consistencia de los resultados. La confiabilidad se

busca que los resultados de un cuestionario concuerden con los resultados del
mismo cuestionario en otra ocasión. Si esto ocurre se puede decir que hay un alto
grado de confiabilidad. Un sistema de manejo de base de datos confiables aquel
que puede continuar procesando las solicitudes de usuario aun cuando el sistema
sobre el que opera no es confiable en otras palabras, aun cuando los
componentes de un sistema distribuido fallen un DDMBS confiable debe seguir
ejecutándose las solicitudes de usuario sin violar la consistencia de la base de
datos.

Protocolos REDO/UNDO.

El registro de la base de datos contiene información que es utilizada por el

proceso de recuperación para restablecer la base de datos a un estado
consistente. Esta información puede incluir entre otras cosas:
  Identificador de la transacción
 Tipo de operación realizada
 Los datos acezados por la transacción para realizar la acción
 El valor anterior del dato
 El valor nuevo del dato

El DBMS inicia la ejecución en el tiempo 0 y en el tiempo t se presenta una falla

del sistema. Durante el periodo [0, t] ocurren dos transacciones, T1 y T2. T1 ha
sido concluida (ha realizado su commit) pero T2 no pudo ser concluida.

La propiedad de durabilidad requiere que los efectos de T1 sean reflejados en la

base de datos estable. De forma similar, la propiedad de atomicidad requiere que
la base de datos estable no contenga alguno de los efectos de T2.

Puntos de verificación (checkpoints).

Cuando ocurre una falla en el sistema es necesario consultar la bitácora para

determinar cuáles son las transacciones que necesitan volver a hacerse y cuando
no necesitan hacerse. Estos puntos de verificación nos ayudan para reducir el
gasto de tiempo consultando la bitácora. El punto de verificación es un registro
que se genera en la bitácora para concluir en todo lo que se encuentra antes de
ese punto está correcto y verificado.

El protocolo 2PC básico un agente (un agente-DTM en el modelo) con un rol

especial. Este es llamado el coordinador; todos los demás agentes que deben
hacer commit a la vez son llamados participantes.

El coordinador es responsable de tomar la decisión de llevar a cabo un commit o

abort finalmente. Cada participante corresponde a una sub transacción la cual ha
realizado alguna acción de escritura en su base de datos local.
Se puede asumir que cada participante está en un sitio diferente. Aun si un
participante y el coordinador se encuentran en el mismo sitio, se sigue el protocolo
como si estuvieran en distintos sitios.

La idea básica del 2PC es determinar una decisión única para todos los
participantes con respecto a hacer commit o abort en todas las sub transacciones
locales.

El protocolo consiste en dos fases:

 La primera fase tiene como objetivo alcanzar una decisión común

 La meta de la segunda fase es implementar esta decisión.

El protocolo procede como sigue:

Fase uno:

• El coordinador escribe “prepare” en la bitácora y envía un mensaje donde

pregunta a todos los participantes si preparan el commit (PREPARE).

• Cada participante escribe “ready” (y registra las subtransacciones) en su propia

bitácora si está listo o “abort” de lo contrario.

• Cada participante responde con un mensaje READY o ABORT al coordinador.

• El coordinador decide el commit o abort en la transacción como un resultado de

las respuestas que ha recibido de los participantes. Si todos respondieron READY,
decide hacer un commit. Si alguno ha respondido ABORT o no ha respondido en
un intervalo de tiempo determinado se aborta la transacción.

Fase dos:

• El coordinador registra la decisión tomada en almacenamiento estable; es decir,

escribe “global_commit” o “global_abort” en la bitácora.
• El coordinador envía mensaje de COMMIT o ABORT según sea el caso para su
ejecución.

• Todos los participantes escriben un commit o abort en la bitácora basados en el

mensaje recibido del coordinador (desde este momento el procedimiento de
recuperación es capaz de asegurar que el efecto de la subtransacción no será
perdido).

Finalmente:

Todos los participantes envían un mensaje de acuse de recibo (ACK) al

coordinador, y ejecutan las acciones requeridas para terminar (commit) o abortar
(abort) la sub transacción.

Cuando el coordinador ha recibido un mensaje ACK de todos los participantes,

escribe un nuevo tipo de registro en la bitácora, llamado un registro “completo”.
REFERENCIAS

Bases de Datos Distribuidas. (s/f). Recuperado el 6 de junio de 2021, de

Blogspot.com website:

http://basesdatosdistribuidas.blogspot.com/2012/11/confiabilidad.html