Uni4

4.1 Transacciones
Transacción: colección de acciones que hacen transformaciones consistentes de los estados de un sistema preservando la consistencia del sistema.

Propiedades de una transacción:
1.-Atomicidad. Se refiere al hecho de que una transacción se trata como una unidad de operación. Por lo tanto, o todas las acciones de la transacción se realizan o ninguna de ellas se lleva a cabo.
2.-Consistencia (correctitud). una transacción es un programa correcto que lleva la base de datos de un estado consistente a otro con la misma característica.
3.-Aislamiento. Una transacción en ejecución no puede revelar sus resultados a otras transacciones concurrentes antes de su commit. Más aún, si varias transacciones se ejecutan concurrentemente, los resultados deben ser los mismos que si ellas se hubieran ejecutado de manera secuencial (seriabilidad).
4.-Durabilidad. Es la propiedad de las transacciones que asegura que una vez que una transacción hace su commit, sus resultados son permanentes y no pueden ser borrados de la base de datos.

4.1.1 Estructura de transacciones Las transacciones planas consisten de una secuencia de operaciones primitivas encerradas entre las palabras clave begin y end.
Transacción anidada dentro de otra transacción: conserva las mismas propiedades que la de sus padres, esto implica, que puede contener así mismo transacciones dentro de ella.
Restricciones de transacción anidada: debe empezar después que su padre y debe terminar antes que él.

Aspectos más importantes relacionados con el procesamiento de transacciones:
Modelo de estructura de transacciones. Es importante considerar si las transacciones son planas o pueden estar anidadas.
Consistencia de la base de datos interna. Los algoritmos de control de datos semántico tienen que satisfacer siempre las restricciones de integridad cuando una transacción pretende hacer un commit.
Protocolos de confiabilidad. En transacciones distribuidas es necesario introducir medios de comunicación entre los diferentes nodos de una red para garantizar la atomicidad y durabilidad de las transacciones.
Algoritmos de control de concurrencia: deben sincronizar la ejecución de transacciones concurrentes bajo el criterio de correctitud.
La consistencia entre transacciones se garantiza mediante el aislamiento de las mismas.
Protocolos de control de réplicas. se refiere a cómo garantizar la consistencia mutua de datos replicados.
El despachador: es responsable de implementar un algoritmo específico de control de concurrencia para sincronizar los accesos a la base de datos.
Los administradores de transacciones implementan una interfaz para los programas de aplicación que consiste de los comandos: Begin_transaction. Read. Write. Commit. Abort.

4.1.2. Ejecución de Transacciones Centralizadas y Distribuidas
4.2 Control de Concurrencia. Todos los mecanismos de control de concurrencia deben asegurar la consistencia de los objetos y cada transacción atómica será completada en un tiempo finito. Un método de control de concurrencia es correcto si es serializable, es decir existe una secuencia equivalente en que las operaciones de cada transacción aparecen antes o después de otra transacción pero no entremezcladas.
4.2.1 SERIALIZACIÓN DISTRIBUIDA
Si cada planificador de ejecución local es serializable y las órdenes locales serializadas son idénticas (es decir, respetan el orden de secuencia), entonces el planificador global es serializable.
Soluciones para el control de concurrencia en un ambiente distribuido:
- El bloqueo (lock) garantiza la ejecución concurrente. En este caso hay que tener cuidado de que no se produzcan interbloqueos.
- Las marcas de tiempo garantizan la ejecución concurrente según el orden fijado en las marcas de tiempo.

4.2.2. Algoritmos de Control de Concurrencia
4.2.2.1 Basados en Bloqueos
Protocolos de bloqueo (locking protocols) (2PLP): Se caracteriza por distribuir un gestor de bloqueo en cada nodo. Cada uno es responsable de la gestión de bloqueos de los datos que contiene en ese nodo.

2PLP distribuido: implementa una protocolo de control de replicas Read-One-Write-All.

4.2.2.2. Basado en Estampas de Tiempo

Protocolo de marcas de tiempo (timestamp protocols) Su objetivo es ordenar las transacciones globalmente de manera que transacciones con una marca de tiempo menor, obtengan la prioridad en el caso de conflicto.

Estampas de tiempo: son valores derivados de un dominio totalmente ordenado.

Identificador de nodo: se agrega en la posición menos significativa, de manera que, éste sirve solo en el caso en que dos nodos diferentes le asignen el mismo contador local a dos transacciones diferentes.

El administrador de transacciones asigna también una estampa de tiempo a todas las operaciones solicitadas por una transacción.

Dado este orden, un conflicto entre operaciones se puede resolver de la siguiente forma:

for Ri(x) do begin if ts(Ti) < wts( x ) then reject Ri(x) else accept Ri(x) rts(x) ¬ ts(Ti) end for Wi(x) do begin if ts(Ti) < rts(x) and ts(Ti) < wts(x) then reject Wi(x) else accept Wi(x) wts(x) ¬ ts(Ti) end Ordenamiento básico (conservador) por estampas de tiempo: trata de ejecutar una operación tan pronto como se recibe una operación. Así, la ejecución de las operaciones es progresiva pero pueden presentar muchos reinicios de transacciones.

Ordenamiento conservador de estampas de tiempo: retrasa cada operación hasta que exista la seguridad de que no será reiniciada.

Ordenamiento por estampas de tiempo múltiples

Estrategias para prevenir la formación de interbloqueos: Al hacer una operación de escritura, no se modifican los valores actuales sino se crean nuevos valores.

Estrategias Para crear copias únicas de acuerdo al tipo de operación de que se trate:

1.Una operación de lectura Ri(x): se traduce a una operación de lectura de x de una sola versión encontrando la versión de x, digamos xv.

2. Una operación de escritura: Wi(x) se traduce en una sola version, Wi(xw), y es aceptada si el despachador no ha procesado cualquier lectura Rj(xr).

4.2.2.3 Pruebas de Validación Optimistas
Los Algoritmos de control de concurrencia discutidos antes son por naturaleza pesimistas.
Algoritmos optimistas: retrasan la fase de validación justo antes de la fase de escritura. De esta manera, una operación sometida a un despachador optimista nunca es retrasada.

4.3 Confiabilidad: Un sistema de manejo de bases de datos confiable es aquel que puede continua procesando las solicitudes de usuario aún cuando el sistema sobre el que opera no es confiable.

4.3.1 Conceptos Básicos de de Confiabilidad

Sistema, estado y falla Un sistema: se refiere a un mecanismo que consiste de una colección de componentes y sus interacciones con el medio ambiente que responden a estímulos que provienen del mismo con un patrón de comportamiento reconocible.

Estado externo de un sistema: se puede definir como la respuesta que un sistema proporciona a un estímulo externo.

Sistema no confiable: es posible que el sistema caiga en un estado interno el cual no obedece a su especificación; a este tipo de estados se les conoce como estados erróneos.

La parte del estado interno que es incorrecta se le conoce como error del sistema.

Falta de sistema: es cualquier error en los estados internos de las componentes del sistema.

Las faltas del sistema se pueden clasificar como severas (hard) y no severas (soft):

Severas: casi siempre son de tipo permanente y conducen a fallas del sistema severas.
No severas: por lo general son transitorias o intermitentes.

Tipos de fallas que pueden ocurrir en un SMBD distribuido:

1.Fallas de transacciones: se pueden deber a un error debido a datos de entrada incorrectos así como a la detección de un interbloqueo.

2.Fallas del sistema: En este tipo de fallas se asume que el contenido de la memoria principal se pierde, pero el contenido del almacenamiento secundario es seguro.

3. Fallas del medio de almacenamiento: Se refieren a las fallas que se pueden presentar en los dispositivos de almacenamiento secundario que almacenan las bases de datos.

Fallas de comunicación: En un sistema distribuido son frecuentes. Estas se pueden manifestar como pérdida de mensajes lo que lleva en un caso extremo a dividir la red en varias subredes separadas.

4.3.2 Protocolos REDO/UNDO Recuperación in-place Dado que las actualización in-place hacen que los valores anteriores se pierdan, es necesario mantener suficiente información de los cambios de estado en la base de datos. Esta información puede incluir entre otras cosas:

Identificador de la transacción,
Tipo de operación realizada,
Los datos accesados por la transacción para realizar la acción,
El valor anterior del dato (imagen anterior),
El valor nuevo del dato (imagen nueva).

Operación de REDO: utiliza la información del registro de la base de datos y realiza de nuevo las acciones que pudieron haber sido realizadas antes de la falla. genera una nueva imagen.

Operación UNDO: restablece un dato a su imagen anterior utilizando la información del registro de la base de datos.