Actividad#22 presentacion

Actividad#21 protocolos Redo/Undo

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:

• El identificador de la transacción,
• El tipo de operación realizada,
• Los datos accesados por la transacción para realizar la acción,
• El valor anterior del dato (imagen anterior), y
• El valor nuevo del dato (imagen nueva)

Operación REDO

Por otra parte, es posible que el administrador del buffer haya realizado la escritura en la base de datos estable de algunas de las páginas de la base de datos volátil correspondientes a la transacción T₂.

Así, la información de recuperación debe incluir datos suficientes para permitir deshacer ciertas actualizaciones en el nuevo estado de la base de datos y regrasarla al estado anterior. A esta operación se le conoce como UNDO y se muestra en la Figura de abajo. La operación UNDO restablece un dato a su imagen anterior utilizando la información del registro de la base de datos.

Operación UNDO

De forma similar a la base de datos volátil, el registro de la base de datos se mantiene en memoria principal (llamada los buffers de registro) y se escribe al almacenamiento estable (llamadoregistro estable). Las páginas de registro se pueden escribir en el registro estable de dos forma asíncrona. En forma síncrona, también llamada un registro forzado, la adición de cada dato en el registro requiere que la página del registro correspondiente se mueva al almacenamiento estable. De manera asíncrona, las páginas del registro se mueven en forma periódica o cuando los buffers se llenan.

Protocolo 2PC de confiabilidad distribuida

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 subtransacció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 subtransacciones 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 subtransacció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”.

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.

Aplicaciones

• Aerolíneas.
• Gestión de viajes.
• Gestión de financiera (sistemas interbancaria).
• Manufactura.
• Cadenas hoteleras.

Actividad#20 CONFIABILIDAD EN UN AMBIENTE DISTRIBUIDO (presentacion)

Actividad#19 Disciplinas de interbloqueo

DISCIPLINAS DE INTERBLOQUEO

Conjunto de procesos tal que cada uno está esperando un recurso que sólo puede liberar otro proceso del conjunto.

- Detección y recuperación: Se detecta y se recupera Coste de algoritmo + pérdida del trabajo realizado.

- Prevención: Asegura que no ocurre fijando reglas Infrautilización de rec. se deben pedir antes de necesitarlos.

- Predicción: Asegura que no ocurre basándose en conocimiento de necesidades futuras de los procesos

- Dificultad de conocer futuro

- Coste de algoritmo + Infrautilización de recursos

- Ignorar el problema:Utilizada por la mayoría de los SS.OO.

Detección del interbloqueo

Algoritmo que comprueba si se cumplen condiciones de interbl. Condiciones necesarias pero no suficientes (Coffman):

- Exclusión mutua.

- Retención y espera.

- Sin expropiación.

- Espera circular.

- Si restricciones (1 unid/rec), cond. son necesarias y suficientes:

Ejemplo 2: Ciclo en grafo → espera circular → interbloqueo

Ejemplo 1: Ciclo en grafo → espera circular → No interbloq.

Ejemplo 3: Ciclo en grafo → espera circular → interbloq.

○ Se necesita condición necesaria y suficiente para sist. general

Condición necesaria y suficiente

Proceso no bloqueado debería devolver recursos en el futuro:

- Recursos liberados desbloquearían otros procesos...

- Reducción (Red) del sistema por proceso P

- Si se pueden satisfacer necesidades de P con r. disponibles

- Nuevo estado hipotético donde P ha liberado todos sus rec.

Condición necesaria y suficiente:

∃ secuencia de Red desde estado actual ⊂ todos los procesos • Si no: procesos ⊄ están en interbloqueo x

Actividad #18 (Algoritmos de control de concurrencia)

CONTROL DE CONCURRENCIA 

el control de concurrencia es la actividad de coordinar accesos concurrentes a la base de datos, es decir, es la forma en que el DBMS maneja las ejecuciones paralelas en la base de datos.

° asegura que transacciones múltiples sometidas por usuarios diferentes no interfieran unas con otras de forma que se produzcan resultados incorrectos..

ejemplo:

El control de concurrencia en bdd es mas compleja que en sistemas centralizados. Un aspecto interesante del c.c es el manejo de interbloqueos, el sistema no debe permitir que dos o mas transacciones se bloqueen entre ellas.

el hecho de reservar un asiento en un avión mediante un sistema basado en aplicaciones web , cuando decenas de perdonas en el mundo pueden reservarlo también nos da una idea de lo importante  y crucial que es el control de concurrencia en un sistema de bd a mediana o gran escala.

ALGORITMO DE CONTROL DE CONCURRENCIA BASADOS EN EL BLOQUEO.

*Bloqueos

Un bloqueo en general es cuando una acción que debe ser realizada está esperando a un evento. Para manejar los bloqueos hay distintos acercamientos: prevención, detección, y recuperación. 

En el caso específico de las bases de datos distribuidas usar bloqueo de recursos, peticiones para probar, establecer o liberar bloqueos requiere mensajes entre los manejadores de transacciones y el calendarizador. Para esto existen dos formas básicas:

• Autónoma: cada nodo es responsable por sus propios bloqueos de recursos.
  • Una transacción sobre un elemento con n replicas requiere 5n mensajes
  • Petición del recurso
  • Aprobación de la petición
  • Mensaje de la transacción
  • Reconocimientos de transacción exitosa
  • Peticiones de liberación de recursos
• Copia Primaria: un nodo primario es responsable para todos los bloqueos de recursos
  • Una transacción sobre un elemento con n copias requiere 2n+3 mensajes
  • Una petición del recurso
  • Una aprobación de la petición
  • n mensajes de la transacción
  • n reconocimientos de transacción exitosa
  • Una petición de liberación de recurso

Podemos definir que dos operaciones entran en conflicto que debe ser resuelto si ambas acceden a la misma data, y una de ellas es de escritura y si fueron realizadas por transacciones distintas.

PRUEBAS DE VALIDACIÓN OPTIMISTAS

Los algoritmos de control de concurrencia discutidos antes son por naturaleza pesimistas. en otras palabras, ellos asumen que los conflictos entre transacciones son muy frecuentes y no permiten el acceso a un dato si existe una transacción conflictiva que accesa el mismo dato.

así la ejecución de cualquier operación de una transacción sigue la secuencia de fases: validación (v), lectura(r),computo(c), Y escritura(w). Los algoritmos optimistas por otra parte, 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.

actividad#17 (parte2)

Mecanismos de control de transacciones para una BDD

Una transacción de una sola instancia de Motor de base de datos que abarque dos o más bases de datos es, de hecho, una transacción distribuida. La instancia administra la transacción distribuida internamente; para el usuario funciona como una transacción local.

En la aplicación, una transacción distribuida al final de la transacción, la aplicación pide que se confirme o se revierta la transacción.

Fase de preparación

Cuando el administrador de transacciones recibe una solicitud de confirmación, envía un comando de preparación a todos los administradores de recursos implicados en la transacción. Cada administrador de recursos hace lo necesario para que la transacción sea duradera y todos los búferes que contienen imágenes del registro de la transacción se pasan a disco. A medida que cada administrador de recursos completa la fase de preparación, notifica si la preparación ha tenido éxito o no al administrador de transacciones.

Fase de confirmación

Si el administrador de transacciones recibe la notificación de que todas las preparaciones son correctas por parte de todos los administradores de recursos, envía comandos de confirmación a cada administrador de recursos. A continuación, los administradores de recursos pueden completar la confirmación. Si todos los administradores de recursos indican que la confirmación ha sido correcta, el administrador de transacciones envía una notificación de éxito a la aplicación. Si algún administrador de recursos informó de un error al realizar la preparación, el administrador de transacciones envía un comando para revertir la transacción a cada administrador de recursos e indica a la aplicación que se ha producido un error de confirmación.

Requiere:

Existe un agente raíz que inicia toda la transacción, así que cuando el usuario requiere la ejecución de una aplicación distribuida el agente raíz es iniciado; el sitio del agente raíz es llamado el sitio origen de la transacción.

El agente raíz tiene la responsabilidad de asegurar BEGIN-TRANSACTION, COMMIT O ROLLBACK de toda la transacción distribuida. 

Recuperación de transacciones distribuidas

·                     Para realizar la recuperación de transacción distribuidas se asume que cada sitio tiene su propio manejador de transacción local (LTM).

·                     Cada agente utiliza de manera local las primitivas asociadas a sus transacciones. Podemos llamar a los agentes subtransacciones, lo cual origina distinguir las primitivas BEGIN-TRANSACTION, COMMIT Y ROLLBACK asociado a la transacción distribuida de la primitivas locales utilizada por

·                     cada agente en LTM; para poder distinguir una de las otras, a las ultimas les llamaremos:

·                     LOCAL-BEGIN, LOCAL-COMMIT Y LOCALROLLBACK.

·                     Para propósito del manejador de transacciones distribuidas (DTM), requieren que los LTM se conformen de la siguiente manera:

1.                  Asegurar la atomicidad de su transacción.

2.                 Grabar en bitácora por ordenes de la transacción distribuida.

Para asegurar que todas las acciones de una transacción distribuida son ejecutadas o no ejecutadas dos condiciones son necesarias:

·                     En cada sitio todas las acciones son ejecutadas o ninguna es ejecutada.

·                     Todos los sitios deberán tomar la misma decisión respecto al COMMIT o ROLLBACK de la transición global.

Estados de una transacción 

• Activa: Durante su ejecución Ficheros y bases de datos 

• Parcialmente comprometida: Después de ejecutar su última instrucción. 

• Fallida: Imposible de continuar su ejecución normal. 

• Abortada: Transacción retrocedida y base de datos restaurada al estado anterior a su 

ejecución. Se puede reiniciar o cancelar. 

Diagrama de estados de una transacción: 

Actividad#17 Resumen (Transacciones)

TRANSACCIONES

Se define como transacción a una colección de operaciones que forman una unidad lógica de trabajo en una BD realizada por una o más sentencias SQL estrechamente relacionadas. En otras palabras es una unidad de la ejecución de un programa que lee y escribe datos a y desde la Base de Datos. Puede consistir en varias operaciones.

Una Transacción está delimitada por instrucciones de inicio transacción y fin transacción (la transacción consiste en todas las operaciones que se ejecutan entre inicio transacción y fin transacción). las transacciones agrupan una serie de operaciones de manera que es posible garantizar la integridad del resultado final. O todas las operaciones se ejecutan con éxito y se confirman o toda la transacción se considera no realizada.

PROPIEDADES DE LA TRANSACCIÓN

ACID (atomicidad, coherencia, aislamiento y durabilidad), para ser calificacada como transacción.

·         Atomicity: Una Transacción (Tx) se ejecuta completamente ó de otra manera se eliminan los cambios parciales realizados.

Begin Transaction - Programa - End Transaction

·         Coherencia: Asegura que los datos que observamos no cambian (por otros usuarios) hasta que termine la Transacción.

·         Aislamiento: Los efectos de una Tx no son visibles a otros usuarios mientras no se confirmen.

Una Transacción en ejecución no puede revelar sus resultados a otras transacciones concurrentes antes de finalizar.

·        Durabilidad: Si el sistema falla no debe permitir que se pierdan las operaciones realizadas por Tx ya confirmadas.

Control de transacciones en Oracle

° Inicio de transacción

Cuando no hay ya una transacción en progreso, y se ejecuta una sentencia LDD o LMD(interactivamente o dentro de una aplicación)

Cada sentencia LDD es tratada como una transacción N

° Fin de transacción

COMMIT: Finaliza la transacción actual y hace permanentes (confirma) los cambios realizados

ROLLBACK: Finaliza la transacción actual y deshace los cambios realizados

Sentencia COMMIT

Una sentencia COMMIT marca el final de una transacción correcta, implícita o definida por el usuario. COMMIT hace que todas las modificaciones efectuadas sobre los datos desde el inicio de la transacción sean parte permanente de la base de datos, y además, libera los recursos mantenidos por la conexión.

COMMENT sirve para comentar la transacción en un máximo 255 caracteres. FORCE fuera de modo manual una transacción dudosa y es de uso exclusivo en sistemas distribuidos de base de datos.

Sentencia SAVEPOINT

Esta sentencia permite crear un punto de restauración dentro de una transacción, es decir, un punto al que podremos retroceder deshaciendo todo lo hecho deshaciendo todo lo hecho desde él en adelante. Su sintaxis es la siguiente

SAVEPOINT nombrePuntoRestauración;

Sentencia ROLLBACK

Señala el final sin éxito de una transacción, elimina todas las modificaciones de datos realizadas desde el inicio de la transacción y también libera los recursos que retiene la transacción.

ROLLBACK [WORK] [TO SAVEPOINT nombrePuntoRestauración | FORCE 'texto'];

GRADOS DE CONSISTENCIA

Consistencia se define como la coherencia entre todos los datos de la base de datos.

Una transacción finalizada (confirmada parcialmente) puede no confirmarse definitivamente (consistencia).

La ejecución de una transacción debe conducir a un estado de la base de datos consistente (cumplir todas las restricciones de integridad definidas).

·         Si se confirma definitivamente el sistema asegura la persistencia de los cambios que ha efectuado en la base de datos.

·         De lo contrario los cambios que ha efectuado son deshechos.

Una transacción que termina con éxito se dice que está comprometida (commited).

 ° En cualquier momento una transacción sólo puede estar en uno de los siguientes estados.

·         Activa (Active): el estado inicial; la transacción permanece en este estado durante su ejecución.

·         Parcialmente comprometida (Uncommited): Después de ejecutarse la última transacción.

·         Fallida (Failed): tras descubrir que no se puede continuar la ejecución normal.

·         Abortada (Rolled Back): después de haber retrocedido la transacción y restablecido la base de datos a su estado anterior al comienzo de la transacción.

·         Comprometida (Commited): tras completarse con éxito.

Aspectos relacionados al 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. Así también, se requieren protocolos para la recuperación local y para efectuar los compromisos (commit) globales.

·         Algoritmos de control de concurrencia. Los 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. El control de réplicas se refiere a cómo garantizar la consistencia mutua de datos replicados. Por ejemplo se puede seguir la estrategia read-one-write-all (ROWA).

NIVELES DE AISLAMIENTO

El nivel de aislamiento para una sesión SQL establece el comportamiento de los bloqueos para las instrucciones SQL.

Control de los niveles de aislamiento de transacción:

·         Controla si se realizan bloqueos cuando se leen los datos y qué tipos de bloqueos se solicitan.

·         Duración de los bloqueos de lectura.

·         Si una operación de lectura que hace referencia a filas modificadas por otra transacción:

o    Se bloquea hasta que se libera el bloqueo exclusivo de la fila.

o    Recupera la versión confirmada de la fila que existía en el momento en el que empezó la instrucción o la transacción.

o    Lee la modificación de los datos no confirmados.

ANSI/ISO SQL define cuatro niveles de aislamiento transaccional en función de tres eventos que son permitidos o no dependiendo del nivel de aislamiento. Estos eventos son:

Lectura sucia. Las sentencias SELECT son ejecutadas sin realizar bloqueos, pero podría usarse una versión anterior de un registro.

Lectura norepetible. Una transacción vuelve a leer datos que previamente había leído y encuentra que han sido modificados o eliminados por una transacción cursada.

Lectura fantasma. Una transacción vuelve a ejecutar una consulta, devolviendo un conjuto de registros que satisfacen una condición de búsqueda y encuentra que otros registro que satisfacen la condición han sido insertadas por otra transacción cursada.

COMMIT Y ROLLBACK

Lecturas consistentes

Por default, las tablas InnoDB ejecutan un lectura consistente (consistent read). Esto significa que cuando una sentencia SELECT es ejecutada, MySQL regresa los valores presentes en la base de datos hasta la transacción más reciente que ha sido completada.

Si alguna transacción está en progreso, los cambios hechos por alguna sentencia DELETE, INSERT o UPDATE no serán reflejados. Sin embargo, existe una excepción: las transacciones abiertas si pueden ver sus propios cambios. Para demostrar esto, necesitamos establecer dos conexiones al servidor MySQL.

Observe el caso feliz de las transacciones. Sin violaciones de integridad referencial o otra clase de errores.

Por defecto, MySQL se ejecuta con el modo autocommit activado. Esto significa que en cuanto ejecute un comando que actualice (modifique) una tabla, MySQL almacena la actualización en disco.