4.

3 CONFIABILIDAD
Un sistema de manejo de bases de datos confiable es aquel que puede continuar procesando las
solicitudes de usuario an 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 transaccin se ejecutan todas o ninguno.
DURABILIDAD: Despus de que una transaccin se ejecut con xito, los cambios en la BD
persisten, ms 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
ocasin. 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
ejecutndoselas solicitudes de usuario sin violar la consistencia de la base de datos.
4.3.1CONCEPTOS BSICOS DE CONFIABILIDADSISTEMA, ESTADO Y FALLA:
Un sistema se refiere a un mecanismo que consiste de una coleccin de componentes y sus
interacciones con el medio ambiente que responden a estmulos que provienen del mismo con un
patrn de comportamiento reconocible. Un estado externo de un sistema se puede definir como
la respuesta que un sistema proporciona a un estmulo externo. Por lo tanto, es posible hablar de
un sistema que se mueve dentro de estados externos de acuerdo a un estmulo proveniente del
medio ambiente. Un estado interno es, por lo tanto, la respuesta del sistema a un estmulo
interno. Cualquier desviacin de un sistema del comportamiento descrito en su especificacin se
considera como una falla. Cualquier error en los estados internos de los componentes del sistema
se le conoce como una falta en el sistema. As, una falta causa un error lo que puede inducir una
falla del sistema. La confiabilidad de un sistema, R (t), se define como la siguiente probabilidad
condicional:
R(t) = Pr{ 0 fallas en el tiempo [0,t] | no hubo fallas en t = 0 }Si la ocurrencia de fallas sigue una
distribucin de Poisson, entonces, R(t) = Pr{ 0 fallas en el tiempo [0,t] }.
El clculo de la confiabilidad y disponibilidad puede ser tedioso. Por lo tanto, es acostumbrado
usar dosmtricas de un slo parmetro para modelar el comportamiento del sistema. Las dos
mtricas son el tiempo medio entre fallas (MTBF por sus siglas en ingls) y el tiempo medio para
reparaciones (MTTR). El MTBF puede ser calculado a partir de datos empricos de la funcin de
confiabilidad. La confiabilidad es una condicin necesaria, pero no suficiente para la validez. Las
evidencias de validez siempre han de ir de la mano con las evidencias de Confiabilidad. La
confiabilidad indica el grado de consistencia, pero no dice si las inferencias que Se hacen y las
decisiones que se toman partiendo del cuestionario son defendibles. La confiabilidad tambin se
refiere a la medida en la cual un instrumento de recopilacin de datos producir los mismos
resultados cada vez que se administra. En la investigacin cualitativa, la confiabilidad significa
hasta qu punto diferentes investigadores, al exponerse a la misma situacin, llegaran a las
mismas conclusiones. En trminos de confiabilidad lo que preocupa es la consistencia de los
resultados. Se necesita la confiabilidad para poder hablar de resultados vlidos, puesto que no es
posible evaluar algo que cambia continuamente.
4.3.2PROTOCOLOS REDO/UNDO
En un protocolo con escritura previa en bitcora, las entradas en la bitcora se dividen en dos
tipos: las necesarias para operaciones REDO (entradas write_tem conteniendo slo
nuevosvalores) y las necesarias para operaciones UNDO (entradas write_tem conteniendo los
valores viejo y nuevo, y entradas read_tem).Cuando se produce un fallo, el esquema de
recuperacin consulta a la bitcora para determinar que transacciones deben deshacerse o
rehacerse. UNDO (T): cuando la bitcora contiene el registro pero no contiene el registro .REDO
(T): cuando la bitcora contiene tanto el registro como el registro.El esquema de recuperacin usa
la operacin REDO rehacer usando informacin de la bitcora. En caso de que ocurra una cada o
fallo de una transaccin se debe recurrir a una operacin UNDO que deshace los cambios
hechos. Un do (T): restaura todos los datos que T actualiza a los valores que tena anteriormente.
Redo (T): asigna los nuevos valores a todos los datos que actualiza la transaccin T.


Es importante respetar el orden de ejecucin de las operaciones para la recuperacin. Las
operaciones UNDO deben realizarse antes que las operaciones REDO. Las operaciones de UNDO se
realizan recorriendo la bitcora desde abajo hacia arriba, esto es, en orden inverso al que se
ejecutaron. Las operaciones de REDO se realizan recorriendo la bitcora desde arriba hacia abajo,
esto es, en el mismo orden en que se actualiz. Ejemplo: Ti aborta pero Tj comete Si se realiza un
REDO primero, A quedar en 30 y el posterior UNDO dejar a A con 10. El valorfinal de A debera
ser 30, y eso es posible de alcanzar si se realiza primero el UNDO y luego el REDO. La operacin
redo utiliza la informacin del registro de la base de datos y realiza de nuevo las acciones que
pueden haber sido realizadas antes de la falla, la operacin redo genera nueva imagen.
Es posible que el administrador del buffer haya realizado la escritura en la base de datos estable
de algunas de las pginas de la base de datos voltil correspondientes a la transaccinT2.
As, la informacin de recuperacin debe incluir datos suficientes para permitir deshacer ciertas
actualizaciones en el nuevo estado de la base de datos y regresarla al estado anterior. La
operacin UNDO restablece un dato a su imagen anterior utilizando la informacin del registro de
bases de datos.
Independientemente de que la escritura del registro sea sncrona o asncrona, se debe observar un
protocolo importante para el mantenimiento del registro de la base de datos. Considere el caso
donde las actualizaciones a la base de datos son escritas en el almacenamiento estable antes de
que el registro sea modificado en el registro estable para reflejar la actualizacin. Si una falla
ocurre antes de que el registro sea escrito, la base de datos permanecer en forma actualizada,
pero el registro no indicar la actualizacin lo que har imposible recuperar la base de datos a un
estadoconsistente antes de la actualizacin.
4.3.3PUNTOS DE VERIFICACIN (CHECK POINTS)
Los checkpoints buscan reducir los tiempos extra en los procesos de bsqueda en la bitcora. Al
disparar un checkpoint el sistema realiza la siguiente secuencia de acciones:
Grabar en memoria estable todos los registros de bitcora que estn en memoria principal.
Grabar en disco los bloques modificados de los registros intermedios (buffer).
Grabar un registro de bitcora en memoria estable.
Cuando ocurre un fallo del sistema es necesario consultar la bitcora para ver cules transacciones
deben rehacerse y cules deshacerse.
PASOS A SEGUIR ANTE FALLOS:
1.- Para cada transaccin Ti tal que aparece en la bitcora el registro antes del registro , no es
necesario ejecutar un REDO.
2.- Despus de un fallo, se examina la bitcora para determinar cul fue la ltima transaccin Ti
que comenz a ejecutarse antes del ltimo checkpoint.
*Esto se hace examinando la bitcora hacia atrs buscando el primer registro y cul es el registro
ms cercano.
*Luego, se aplica REDO o UNDO sobre Ti y todas las transacciones que le suceden. Un punto de
control (checkpoints).Es registrado en la bitcora peridicamente en el momento en que el
sistema ha grabado en la BD en disco los efectos de todas las operaciones de escritura de las
transacciones confirmadas. En un esquema sin concurrencia, en elproceso de recuperacin
solamente se consideraban:
*Aquellas transacciones que comenzaron despus del checkpoint ms reciente.
*La nica transaccin (si exista) que estaba activa al momento del ms reciente checkpoint. En un
esquema concurrente puede haber ms de una transaccin activa al momento del checkpoint.
Las operaciones de recuperacin requieren recorrer todo el registro de la base de datos. As, el
buscar todas las transacciones a las cuales es necesario aplicarles un UNDO o REDO puede tomar
una cantidad de trabajo considerable. Para reducir este trabajo se pueden poner puntos de
verificacin (checkpoints) en el registro de la base de datos para indicar que en esos puntos la
base de datos est actualizada y consistente. En este caso, un REDO tiene que iniciar desde un
punto de verificacin y un UNDO tiene que regresar al punto de verificacin ms inmediato
anterior. La colocacin de puntos de verificacin se realiza con las siguientes acciones: Se escribe
un begin_checkpoint en el registro de la base de datos. Se recolectan todos los datos verificados
en la base de datos estable. Se escribe un fin_de_checkpoint en el registro de la base de datos.
Estos puntos de verificacin nos ayudan para reducir el gasto de tiempo consultando la bitcora. El
punto de verificacin en un registro que se genera en la bitcora para concluir en todo lo que se
encuentraantes de ese punto esta correcto y verificado. Si el sistema se llega a caer se realiza la
bitcora buscando del final al inicio el primer registro check point ya encontrado se procesan los
registros que se encuentran despus del check point.
4.3.4PROTOCOLOS 2PC DE CONFIABILIDAD DISTRIBUIDA
Es un protocolo que consume un gran volumen de tiempo en la ejecucin de una Transferencia
durante el procesamiento normal se puede eliminar accesos a disco o el nmero de mensajes en el
proceso de la transaccin la pertenencia 2pcpodra ser mejorado. El 2pc es conocido tambin
como el protocolo que no resume nada para que trata todas las transacciones de la misma
forma sin importar si las mismas cometen o abortan.
En el protocolo de bloqueo de dos fases estricto cada sub transaccin debe informar a las otras
sub transacciones de que ha requerido todos los bloqueos. Una transaccin T que fue iniciada en
un sitio S y dividida en varias sub transacciones ejecutndose en diferentes sitios. Las sub
transaccin se ordenan en un coordinador y las otras participantes.
Cada sub transaccin Ti decide si cometer o abortar, y enva al coordinador un mensaje . El
coordinador toma la decisin final en funcin de las votaciones de todos los participantes.
Cuando se presentan fallas en la red, este protocolo puede llevar a estados de bloqueo, esto es,
una sub transaccin en un sitio queno fall no puede cometer ni abortar hasta que se repare la
falla en el sitio de origen.
PROTOCOLO DE COMPROMISO DE 2 FASES:
Mejora: Cada sub transaccin mide el tiempo mximo de espera por una respuesta.
Un participante que alcanza el tiempo mximo pasa al estado de intentar recuperarse.
Para ello enva un mensaje de ayuda helpme a los otros participantes. Ante el pedido de
ayuda, otros participantes segn su estado contestan:
Si est en estado cometida, le enva un mensaje commit.
Si est en estado abortado, le enva un mensaje abort.
Si est en estado decidiendo (no vot an) decide abortar y enva abort T al coordinador.
Si est en estado dispuesta a comenter, no puede ayudar.
En la siguiente figura se presentan las dos fases de comunicacin para realizar un commit en
sistemas distribuidos. El esquema presentado en la figura se conoce como centralizado ya que la
comunicacin es solo entre el coordinador y los participantes; los participantes no se comunican
entre ellos.
Replicacin nerge Esta permite la replicacin de tablas y procedimientos almacenados. Las
modificaciones pueden hacerse en el Publisher o bien en las copias mantenidas por los
suscriptores. Para mantener la integridad de los datos replicados el proceso de sincronizacin se
encarga de actualizar las modificaciones realizadas en las copias de los suscriptores y viceversa.