<ul><li>PLANTEL CONALEP DR GUILLERMO FIGUEROA CARDENAS </li></ul><ul><li>CONSTRUCCION DE BASE DE DATOS </li></ul><ul><li>A...
<ul><li>3.1  Programa las transacciones en las bases de datos, para mantener la integridad de la información. </li></ul><u...
<ul><li>B.- Manejo de Concurrencia </li></ul><ul><ul><ul><li>Definición de concurrencia </li></ul></ul></ul><ul><ul><ul><l...
<ul><li>Conocer la problemática asociada a la concurrencia de transacciones en los sistemas de bases de datos </li></ul><u...
<ul><li>Los sistemas de bases de datos,  según el número de usuarios  que pueden utilizarlos de forma concurrente, se clas...
<ul><ul><li>Aumentar la productividad: número de transacciones ejecutadas por minuto. </li></ul></ul><ul><ul><li>Aumentar ...
<ul><li>porque pueden surgir   problemas  si las transacciones concurrentes se ejecutan de manera no controlada </li></ul>...
<ul><li>Ejemplo sencillo: sistema de bases de datos que permite hacer y anular reservas de plazas en vuelos de diferentes ...
<ul><li>Cada transacción comprende una secuencia de operaciones que incluyen acciones de lectura y escritura en la BD, que...
<ul><li>Para el control de la concurrencia (y recuperación de fallos) interesa prestar mayor atención a estas  operaciones...
<ul><li>Una  planificación no serie   P  es aquella en la que  las operaciones de un conjunto de transacciones concurrente...
<ul><li>Una  planificación   P  (no serie) es  serializable  si es  equivalente a  alguna  planificación serie de las mism...
<ul><li>Si dos transacciones  únicamente leen  un determinado  elemento  de datos, no entran en conflicto entre sí y el or...
<ul><li>En una planificación, 2  operaciones  están  en conflicto  si  </li></ul><ul><ul><li>pertenecen a  diferentes   tr...
<ul><li>Una  planificación  P  es  serializable por conflictos  si  equivale por conflictos a  alguna  planificación serie...
Planificación E Serializabilidad Ejemplo de planificación no serializable Transacción T1 leer_elemento(X); escribir_elemen...
Planificación F Serializabilidad Ejemplo de planificación serializable Transacción T1 leer_elemento(X); escribir_elemento(...
<ul><li>Métodos basados en la teoría de la serializabilidad, que definen un conjunto de  reglas  (o protocolo) tal que... ...
<ul><li>Uso de bloqueos para controlar el acceso concurrente a los elementos de datos almacenados en la base de datos </li...
Reglas de uso de los bloqueos 1.  T  debe emitir  bloquear_lectura(X)  o  bloquear_escritura(X)  antes de ejecutar una ope...
<ul><li>Cuando una transacción  T  solicita un bloqueo… </li></ul><ul><ul><li>Si el elemento no ha sido ya bloqueado por o...
<ul><li>Algunos sistemas permiten la  mejora  (o promoción) y la  reducción  (o degradación) de bloqueos </li></ul><ul><ul...
<ul><li>El uso de  bloqueos  para la programación de transacciones  no garantiza  la  serializabilidad  de las planificaci...
<ul><li>Es necesario seguir un  protocolo adicional  que indique  dónde colocar las operaciones de bloqueo y desbloqueo  d...
<ul><li>Si el sistema permite mejorar y reducir bloqueos… </li></ul><ul><ul><li>La mejora sólo puede tener lugar en la fas...
<ul><li>Si toda transacción  de una planificación  sigue  el  protocolo  de  bloqueo en dos fases , entonces  la planifica...
<ul><li>T  debe  bloquear todos los elementos  a los que tendrá acceso  (lectura o escritura)   antes de comenzar  a ejecu...
<ul><li>Situación en la que cada una de dos  (o más)  transacciones está esperando a que se libere un bloqueo establecido ...
<ul><li>Hay 3 técnicas generales para gestionar los interbloqueos </li></ul><ul><ul><li>Temporizaciones  de bloqueos </li>...
<ul><li>Una transacción que solicita un bloqueo sólo esperará durante un período de tiempo predefinido por el sistema </li...
Técnicas de control de concurrencia Prevención de interbloqueos <ul><li>Ordenar las transacciones usando  marcas temporale...
Técnicas de control de concurrencia Detección de interbloqueos <ul><li>Si el sistema está en un estado de interbloqueo, el...
<ul><li>Una transacción sufre  inanición  cuando es seleccionada para ser abortada ( víctima ) sucesivamente:  nunca termi...
Técnicas de control de concurrencia El problema del bloqueo indefinido <ul><li>El protocolo de control de concurrencia  nu...
<ul><li>Toda técnica de control de concurrencia supone que la base de datos está constituida por un  conjunto de   element...
<ul><li>En el contexto de los métodos de bloqueo, el tamaño del elemento de datos afecta al grado de concurrencia: </li></...
Upcoming SlideShare
Loading in …5
×

B. manejo de concurrencia

4,544 views

Published on

Published in: Education
1 Comment
0 Likes
Statistics
Notes
  • Be the first to like this

No Downloads
Views
Total views
4,544
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
103
Comments
1
Likes
0
Embeds 0
No embeds

No notes for slide
  • Simultáneo = Paralelo Razones para permitir la concurrencia: Aumentar la productividad: número de transacciones ejecutadas por minuto. Aumentar la utilización de la CPU (menos tiempo ociosa) y Control del disco. Reducir el tiempo medio de respuesta de transacciones (las ‘pequeñas’ no esperan a las ‘grandes’).
  • Simultáneo = Paralelo Razones para permitir la concurrencia: Aumentar la productividad: número de transacciones ejecutadas por minuto. Aumentar la utilización de la CPU (menos tiempo ociosa) y Control del disco. Reducir el tiempo medio de respuesta de transacciones (las ‘pequeñas’ no esperan a las ‘grandes’).
  • En este sistema de bases de datos, un programa para la reserva (o cancelación) de plazas en ciertos vuelos tendrá como parámetros de entrada los siguientes: número de los vuelos , sus fechas y el número de plazas que reservar (o cancelar). Así que un mismo programa puede usarse para ejecutar muchas transacciones : la ejecución específica de un programa  transacción.
  • En este sistema de bases de datos, un programa para la reserva (o cancelación) de plazas en ciertos vuelos tendrá como parámetros de entrada los siguientes: número de los vuelos , sus fechas y el número de plazas que reservar (o cancelar). Así que un mismo programa puede usarse para ejecutar muchas transacciones : la ejecución específica de un programa  transacción.
  • Nomenclatura: Planificación = Plan Serializabilidad = Seriabilidad = Secuencialidad Planificación Serializable = Planificación Seriable = Planificación Secuenciable
  • Las operaciones en una planificación tienen como subíndice un número indicativo de la transacción a la que pertenecen. Por ejemplo, con l 2 (X) nos referimos a una operación de lectura del elemento X realizado por la transacción T 2 .
  • La planificación C no es correcta, por el problema de actualización perdida La planificación D sí es correcta Nos interesa, por tanto, saber cómo detectar las planificaciones no serie que SIEMPRE dan un resultado correcto .
  • Una planificación no serie pero serializable es correcta por ser equivalente a una planificación serie (que se considera correcta) Para definir la EQUIVALENCIA entre dos planificaciones, mejor no suponer nada acerca del tipo de operaciones que se ejecutan, sino forzar a que dichas operaciones, sean las que sean, se apliquen en el mismo orden en ambas planificaciones. Pero entonces ¿Cuándo son equivalentes dos planificaciones? Si las operaciones sobre cada elemento de datos se aplican en el mismo orden en ambas Así, el resultado de las dos planificaciones será el mismo La equivalencia por conflictos es la más utilizada.
  • Introducción…
  • Es interesante remarcar que una planificación no serie es correcta si se ejecuta de forma equivalente a ALGUNA planificación serie (a cualquiera de las posibles). Esto está asegurado si el orden de las operaciones en conflicto en la planificación no serie coincide con el orden en que se ejecutarían en alguna planificación serie. Nótese que las operaciones en conflicto entre T i son las que pueden afectar al resultado pues consisten en escrituras/lecturas de los mismos elementos por parte de transacciones diferentes. Si dos operaciones en conflicto se aplican en orden diferente en dos planificaciones, el efecto de dichas planificaciones puede ser distinto (sobre las transacciones o sobre la BD) así que estas planificaciones NO serían equivalentes por conflictos.
  • La demostración de que un plan no en serie P es equivalente a otro plan en serie S es que podríamos reordenar las operaciones del plan P que no están en conflicto (nótese que éstas son las únicas que podemos ejecutar en cualquier orden) hasta llegar a ponerlas en el mismo orden en que se ejecutan en el plan S. Cada dos operaciones (consecutivas y de distintas transacciones) que no están en conflicto pueden intercambiar su orden, de forma que, poco a poco, se llega a la planificación serie equivalente
  • No existe ninguna planificación serie equivalente a P E porque existen dos ciclos en el grafo de precedencia T 1 -&gt; T 2 -&gt; T 1 y T 1 -&gt; T 2 -&gt; T 3 -&gt; T 1 .
  • Existe una planificación serie equivalente a P F porque NO existen ciclos en el grafo de precedencia: T 3 -&gt; T 1 -&gt; T 2 .
  • La frase “...todas las transacciones las cumplen” significa que los programadores definen o programan dichas transacciones siguiendo determinadas reglas (normas o protocolo). Las reglas garantizan el aislamiento (no interferencia destructiva) de transacciones concurrentes. [Extractos del Capítulo 20 de [EN 2002] y 18 de [EN 1997] ]: Protocolos basados en Marcas de Tiempo : Una marca de tiempo es un identificador único generado por el sistema para cada transacción Se garantiza que operaciones cualesquiera en conflicto se ejecutarán en el orden de las marcas de tiempo de las transacciones Técnicas de Multiversión Uso de múltiples versiones de los elementos de información (empleado por Oracle, junto con los bloqueos) Protocolos Optimistas Uso del concepto de validación o certificación de una transacción. Comprueban las posibles violaciones de la serializabilidad una vez que las transacciones han terminado, pero antes de que sean confirmadas. [CB 2005, pág. 535] Basados en la premisa de que los conflictos son raros, por lo que se permite que las transacciones continúen de manera no sincronizada y sólo comprueban los conflictos al final, cuando una transacción se confirma.
  • Es la técnica más ampliamente utilizada para garantizar la serializabilidad de las transacciones concurrentes. Una transacción debe reclamar un bloqueo sobre un elemento de datos antes de ejecutar una operación de lectura o escritura en la base de datos.
  • Estas reglas deben obedecerlas todas las T afectadas, es decir, deben ser codificadas incluyendo las operaciones bloquear_lectura , bloquear_escritura y desbloquear tal y como se describe en las reglas anteriores. El SGBD puede imponer estas reglas. La implementacion consistiría en: 1. Tabla de bloqueos que contiene registros de tres campos (4 si se permite promoción/degradación); un registro por cada elemento bloqueado. 2. Cada registro contiene &lt;nombre-elemento-informacion, bloqueo, numero-lecturas&gt; 3. La tabla de bloqueos sólo debe almacenar los registros correspondientes a los elementos bloqueados. Una vez liberados, desaparece el registro de la tabla. 4. bloqueo puede tomar dos valores, por ejemplo: 1 (bloqueo compartido, para lectura) y 2 (bloqueo exclusivo, para escritura) 5. Cola para cada registro que almacena los identificadores de las T en espera de conseguir X (que está bloqueado en exclusiva) 6. Para permitir la Degradación y Promoción de candados es necesario guardar, para cada registro (correspondiente al elemento de datos X ): Transacciones que están leyendo X (si el bloqueo(X) = 1 , bloqueado para lectura) Transacción (sólo una) que está escribiendo X (si el bloqu e o(X) = 2 , bloqueado para escritura)
  • Conversión de bloqueos: mejora o promoción y reducción o degradación de bloqueos.
  • Ejemplo de una planificación no serie y no serializable, a pesar de que usa bloqueos. T 4 modifica X usando Y y T 5 modifica Y usando el valor de X . Si una lee Y , la otra modifica Y y la 1ª modifica X usando el valor ‘antiguo’ de Y , entonces ocurre el error. Esto sucede porque los elementos Y en T 4 y X en T 5 se desbloquean antes de tiempo; aunque pueda parecer que esto permite una mayor concurrencia, en realidad permite que las transacciones interfieran entre sí, lo que provoca una pérdida de la atomicidad y el aislamiento. Nota: se puede observar que las dos ejecuciones en serie no dan el mismo resultado, pero ambas son correctas.
  • Usar bloqueos no es suficiente para evitar planes incorrectos. Hay que usarlos ‘bien’… El protocolo más conocido, que permite emitir de forma adecuada las operaciones de bloqueo y desbloqueo, es el Protocolo de Bloqueo en Dos Fases ( Two-phase locking , 2PL).
  • Son las mismas transacciones de hace dos diapositivas, pero siguiendo el protocolo de bloqueo en dos fases.
  • Al imponer las reglas de bloqueo , también se impone la serializabilidad. El inferior nivel de concurrencia cuando se usa B2F es el precio que hay que pagar por garantizar la serializabilidad de todas las planificaciones, sin tener que examinarlas.
  • Los protocolos B2F estricto y riguroso aseguran planificaciones estrictas. La definición de una planificación estricta la estudiaremos en el tema siguiente, de Recuperación de Fallos. En una planificación estricta, una transacción T nunca lee/escribe elementos modificados por otras transacciones no completadas (confirmadas/abortadas). Una planificación estricta es una planificación recuperable y sin reversión en cascada . Diferencia entre el B2F conservador y el riguroso: En el B2F conservador, una T ya iniciada ya está en fase de contracción. En el B2F riguroso, una T está en fase de expansión durante toda su ejecución, hasta que libera todos sus bloqueos al finalizar.
  • Bloqueo mortal o Dead Lock. La gestión de interbloqueos resulta transparente al usuario, por ello, el SGBD reinicia automáticamente las transacciones abortadas para romper el interbloqueo.
  • En la práctica, se utiliza la detección. No suelen emplearse los protocolos de prevención, por utilizar suposiciones poco realistas o implicar posibles sobrecargas del sistema. Salvo el uso de tiempos predefinidos, que sí resultan más prácticos. A continuación veremos cada uno de estos enfoques con detalle.
  • Los dos algoritmos fueron propuestos por Rosenkrantz et al., en 1978. Si T1 se inicia antes que T2, entonces MT(T1) &lt; MT(T2). Es análoga a una fecha de nacimiento. El concepto de marca de tiempo es el mismo que el usado en los Protocolos basados en Marcas de Tiempo (OMT Básico, OMT estricto y Regla de Thomas), pero estos usan dicho concepto para ordenar las transacciones, de forma que aun intercalándose, las operaciones en conflicto se ejecuten en el orden específico del (único) plan en serie con iguales marcas de tiempo para las transacciones [EN2002 635-637]. Aquí se emplea este concepto como complemento al uso de bloqueos (implementando esquemas de espera justos).
  • T es abortada, se reinicia y cae en otro bloqueo mortal, y vuelve a ser seleccionada como víctima... T sufre de inanición : es una espera indefinida por el reinicio cíclico. Esperar-Morir y Herir-Esperar evitan la espera indefinida, porque cuando una T es abortada, se reinicia con la misma marca de tiempo, por lo que alguna vez se ejecutará.
  • Esquema de espera : método o técnica de gestión de la lista de transacciones en espera de elementos bloqueados. El protocolo de “Aumento de prioridad…” se usa, por ejemplo, en los protocolos de prevención del bloqueo mortal que utilizan marcas de tiempo ( Herir-Esperar y Esperar-Morir ).
  • En Oracle un elemento puede ser una fila (registro) en una tabla o una tabla completa (un segmento). Así, se permite el bloqueo de filas (automático) o de tablas completas (manual).
  • Una transacción representativa es una típica, un ‘modelo’ de las transacciones más comunes o habituales. Se han propuesto algunas técnicas que tienen un tamaño dinámico del elemento de datos. Con éstas, dependiendo de los tipos de transacción que se están ejecutando en cada momento, puede cambiarse el tamaño del elemento de datos para asignarle la granularidad que resulte más apropiada para cada transacción. Idealmente, el SGBD debe soportar un sistema de granularidad mixta, con bloqueos en el nivel de registro, página y fichero. Algunos sistemas mejoran automáticamente los bloqueos de nivel de registro o de página para asignarles nivel de fichero en aquellos casos en que la transacción está bloqueando más de un cierto porcentaje de los registros o páginas del fichero.
  • B. manejo de concurrencia

    1. 1. <ul><li>PLANTEL CONALEP DR GUILLERMO FIGUEROA CARDENAS </li></ul><ul><li>CONSTRUCCION DE BASE DE DATOS </li></ul><ul><li>Alumna: D.I.S.G </li></ul>
    2. 2. <ul><li>3.1 Programa las transacciones en las bases de datos, para mantener la integridad de la información. </li></ul><ul><li>3.1.1 Programa y ejecuta transacciones en la base de datos utilizando el protocolo de bloqueo de dos fases y control de concurrencia. </li></ul>
    3. 3. <ul><li>B.- Manejo de Concurrencia </li></ul><ul><ul><ul><li>Definición de concurrencia </li></ul></ul></ul><ul><ul><ul><li>Técnicas de bloqueo </li></ul></ul></ul><ul><ul><ul><li>Seriabilidad con el bloqueo en dos fases. </li></ul></ul></ul>
    4. 4. <ul><li>Conocer la problemática asociada a la concurrencia de transacciones en los sistemas de bases de datos </li></ul><ul><li>Entender el significado de la seriabilidad y su aplicación al control de la concurrencia </li></ul><ul><li>Comprender algunas técnicas para el control de la concurrencia empleadas por los sistemas gestores de bases de datos </li></ul>Objetivo de la sesión
    5. 5. <ul><li>Los sistemas de bases de datos, según el número de usuarios que pueden utilizarlos de forma concurrente, se clasifican en sistemas monousuario y multiusuario </li></ul><ul><li>Varios usuarios pueden usar un mismo equipo a la vez gracias a la multiprogramación : la computadora puede procesar al mismo tiempo varias transacciones </li></ul><ul><ul><li>Si el equipo tiene varias CPU , es posible el procesamiento simultáneo (paralelo) de transacciones </li></ul></ul><ul><ul><li>Si sólo hay una CPU , el SO de multiprogramación reparte el tiempo de CPU entre las transacciones: ejecución concurrente intercalada </li></ul></ul>Introducción
    6. 6. <ul><ul><li>Aumentar la productividad: número de transacciones ejecutadas por minuto. </li></ul></ul><ul><ul><li>Aumentar la utilización de la CPU (menos tiempo ociosa) y Control del disco. </li></ul></ul><ul><ul><li>Reducir el tiempo medio de respuesta de transacciones (las ‘pequeñas’ no esperan a las ‘grandes’). </li></ul></ul>Razones para permitir concurrencia
    7. 7. <ul><li>porque pueden surgir problemas si las transacciones concurrentes se ejecutan de manera no controlada </li></ul>problemas de la concurrencia ¿Por qué es necesario el control de la concurrencia?
    8. 8. <ul><li>Ejemplo sencillo: sistema de bases de datos que permite hacer y anular reservas de plazas en vuelos de diferentes compañías aéreas. </li></ul><ul><ul><li>Se almacena un registro por cada vuelo , que incluye, entre otras cosas, el número de asientos reservados en el vuelo </li></ul></ul><ul><ul><li>Sean dos transacciones T1 y T2 concurrentes : </li></ul></ul><ul><ul><ul><li>T1 transfiere N reservas realizadas en un vuelo X a otro vuelo Y </li></ul></ul></ul><ul><ul><ul><li>T2 reserva M plazas en el vuelo X </li></ul></ul></ul>problemas de la concurrencia ¿Por qué es necesario el control de la concurrencia?
    9. 9. <ul><li>Cada transacción comprende una secuencia de operaciones que incluyen acciones de lectura y escritura en la BD, que finaliza con una confirmación ( commit ) o anulación ( rollback ) </li></ul><ul><li>Una planificación P de n transacciones concurrentes T 1 , T 2 ... T n es una secuencia de las operaciones realizadas por dichas transacciones, sujeta a la restricción de que para cada transacción T i que participa en P , sus operaciones aparecen en P en el mismo orden en el que ocurren en T i </li></ul>Serializabilidad Planificación de transacciones
    10. 10. <ul><li>Para el control de la concurrencia (y recuperación de fallos) interesa prestar mayor atención a estas operaciones : </li></ul><ul><li>Ejemplos de planificaciones de transacciones </li></ul><ul><ul><li>El subíndice de cada operación indica la transacción que la realiza </li></ul></ul><ul><ul><li>P A : l 1 (X) ; e 1 (X) ; l 1 (Y) ; e 1 (Y) ; c 1 ; l 2 (X) ; e 2 (X) ; c 2 ; </li></ul></ul><ul><ul><li>P B : l 2 (X) ; e 2 (X) ; c 2 ; l 1 (X) ; e 1 (X) ; l 1 (Y) ; e 1 (Y) ; c 1 ; </li></ul></ul><ul><ul><li>P C : l 1 (X) ; l 2 (X) ; e 1 (X) ; l 1 (Y) ; e 2 (X) ; c 2 ; e 1 (Y) ; c 1 ; </li></ul></ul><ul><ul><li>P D : l 1 (X) ; e 1 (X) ; l 2 (X) ; e 2 (X) ; c 2 ; l 1 (Y) ; e 1 (Y) ; c 1 ; </li></ul></ul><ul><ul><li>P E : l 1 (X) ; e 1 (X) ; l 2 (X) ; e 2 (X) ; c 2 ; l 1 (Y) ; r 1 ; </li></ul></ul>Serializabilidad Planificación de transacciones operación abreviatura leer_elemento l escribir_elemento e commit c rollback r
    11. 11. <ul><li>Una planificación no serie P es aquella en la que las operaciones de un conjunto de transacciones concurrentes se ejecutan intercaladas </li></ul><ul><ul><li>P C : l 1 (X) ; l 2 (X) ; e 1 (X) ; l 1 (Y) ; e 2 (X) ; c 2 ; e 1 (Y) ; c 1 ; </li></ul></ul><ul><ul><li>P D : l 1 (X) ; e 1 (X) ; l 2 (X) ; e 2 (X) ; c 2 ; l 1 (Y) ; e 1 (Y) ; c 1 ; </li></ul></ul><ul><li>Hemos de determinar qué planificaciones no serie permiten llevar la BD a un estado al que pueda llegarse mediante una ejecución en serie </li></ul>Serializabilidad Planificación no serie Este es el objetivo de la Serializabilidad KO
    12. 12. <ul><li>Una planificación P (no serie) es serializable si es equivalente a alguna planificación serie de las mismas n transacciones </li></ul><ul><ul><li>Una planificación que no es equivalente a ninguna ejecución en serie, es una planificación no serializable </li></ul></ul><ul><li>Toda planificación serializable es correcta </li></ul><ul><ul><li>Produce los mismos resultados que alguna ejecución en serie </li></ul></ul><ul><li>Dos maneras de definir la equivalencia entre planificaciones: </li></ul><ul><ul><li>Equivalencia por conflictos </li></ul></ul><ul><ul><li>Equivalencia de vistas </li></ul></ul>Serializabilidad Planificación serializable
    13. 13. <ul><li>Si dos transacciones únicamente leen un determinado elemento de datos, no entran en conflicto entre sí y el orden de las operaciones no es importante </li></ul><ul><li>Si hay dos transacciones que leen o escriben elementos de datos independientes , no entran en conflicto entre sí y el orden de las operaciones no es importante </li></ul><ul><li>Si una de las transacciones escribe un elemento de datos y la otra lee o escribe el mismo elemento , entran en conflicto y el orden de las operaciones sí es importante </li></ul>Serializabilidad Equivalencia por conflictos
    14. 14. <ul><li>En una planificación, 2 operaciones están en conflicto si </li></ul><ul><ul><li>pertenecen a diferentes transacciones , </li></ul></ul><ul><ul><li>tienen acceso al mismo elemento X , </li></ul></ul><ul><ul><li>y al menos una de ellas es escribir_elemento (X) </li></ul></ul><ul><ul><li>Operaciones en conflicto en las planificaciones P C y P D : </li></ul></ul><ul><ul><ul><li>P C : l 1 (X) ; l 2 (X) ; e 1 (X) ; l 1 (Y) ; e 2 (X) ; c 2 ; e 1 (Y) ; c 1 ; </li></ul></ul></ul><ul><ul><ul><li>P D : l 1 (X) ; e 1 (X) ; l 2 (X) ; e 2 (X) ; c 2 ; l 1 (Y) ; e 1 (Y) ; c 1 ; </li></ul></ul></ul><ul><li>Dos planes son equivalentes por conflictos si el orden de cualesquiera dos operaciones en conflicto es el mismo en ambos planes </li></ul>Serializabilidad Equivalencia por conflictos
    15. 15. <ul><li>Una planificación P es serializable por conflictos si equivale por conflictos a alguna planificación serie S </li></ul><ul><ul><li>Podremos intercambiar cada dos operaciones de P consecutivas de transacciones distintas y sin conflicto, hasta obtener la planificación serie equivalente </li></ul></ul><ul><ul><ul><li>P D : l 1 (X) ; e 1 (X) ; l 2 (X) ; e 2 (X) ; c 2 ; l 1 (Y) ; e 1 (Y) ; c 1 ; </li></ul></ul></ul><ul><ul><ul><li>P D1 : l 1 (X) ; e 1 (X) ; l 2 (X) ; e 2 (X) ; l 1 (Y) ; c 2 ; e 1 (Y) ; c 1 ; </li></ul></ul></ul><ul><ul><ul><li>P D2 : l 1 (X) ; e 1 (X) ; l 2 (X) ; e 2 (X) ; l 1 (Y) ; e 1 (Y) ; c 2 ; c 1 ; </li></ul></ul></ul><ul><ul><ul><li>P D3 : l 1 (X) ; e 1 (X) ; l 2 (X) ; e 2 (X) ; l 1 (Y) ; e 1 (Y) ; c 1 ; c 2 ; </li></ul></ul></ul><ul><ul><ul><li>P D4 : l 1 (X) ; e 1 (X) ; l 2 (X) ; l 1 (Y) ; e 2 (X) ; e 1 (Y) ; c 1 ; c 2 ; </li></ul></ul></ul><ul><ul><ul><li>P D5 : l 1 (X) ; e 1 (X) ; l 2 (X) ; l 1 (Y) ; e 1 (Y) ; e 2 (X) ; c 1 ; c 2 ; </li></ul></ul></ul><ul><ul><ul><li>P D6 : l 1 (X) ; e 1 (X) ; l 2 (X) ; l 1 (Y) ; e 1 (Y) ; c 1 ; e 2 (X) ; c 2 ; </li></ul></ul></ul><ul><ul><ul><li>P D7 : l 1 (X) ; e 1 (X) ; l 1 (Y) ; l 2 (X) ; e 1 (Y) ; c 1 ; e 2 (X) ; c 2 ; </li></ul></ul></ul><ul><ul><ul><li>P D8 : l 1 (X) ; e 1 (X) ; l 1 (Y) ; e 1 (Y) ; l 2 (X) ; c 1 ; e 2 (X) ; c 2 ; </li></ul></ul></ul><ul><ul><ul><li>P D9 : l 1 (X) ; e 1 (X) ; l 1 (Y) ; e 1 (Y) ; c 1 ; l 2 (X) ; e 2 (X) ; c 2 ; </li></ul></ul></ul>Serializabilidad Planificación serializable por conflictos ¡Es una planificación serie! P D es serializable
    16. 16. Planificación E Serializabilidad Ejemplo de planificación no serializable Transacción T1 leer_elemento(X); escribir_elemento(X); leer_elemento(Y); escribir_elemento(Y); Transacción T2 leer_elemento(Z); leer_elemento(Y); escribir_elemento(Y); leer_elemento(X); escribir_elemento(X); Transacción T3 leer_elemento(Y); leer_elemento(Z); escribir_elemento(Y); escribir_elemento(Z); T1 leer_elemento(X); escribir_elemento(X); leer_elemento(Y); escribir_elemento(Y); T2 leer_elemento(Z); leer_elemento(Y); escribir_elemento(Y); leer_elemento(X); escribir_elemento(X); T3 leer_elemento(Y); leer_elemento(Z); escribir_elemento(Y); escribir_elemento(Z); Hay dos ciclos: T 1 ->T 2 ->T 1 y T 1 ->T 2 ->T 3 ->T 1 T 1 T 2 Y X T 3 Y,Z Y
    17. 17. Planificación F Serializabilidad Ejemplo de planificación serializable Transacción T1 leer_elemento(X); escribir_elemento(X); leer_elemento(Y); escribir_elemento(Y); Transacción T2 leer_elemento(Z); leer_elemento(Y); escribir_elemento(Y); leer_elemento(X); escribir_elemento(X); Transacción T3 leer_elemento(Y); leer_elemento(Z); escribir_elemento(Y); escribir_elemento(Z); T1 leer_elemento(X); escribir_elemento(X); leer_elemento(Y); escribir_elemento(Y); T2 leer_elemento(Z); leer_elemento(Y); escribir_elemento(Y); leer_elemento(X); escribir_elemento(X); T3 leer_elemento(Y); leer_elemento(Z); escribir_elemento(Y); escribir_elemento(Z); La planificación serie equivalente es T3 -> T1 -> T2 T 1 T 2 X,Y T 3 Y,Z Y
    18. 18. <ul><li>Métodos basados en la teoría de la serializabilidad, que definen un conjunto de reglas (o protocolo) tal que... </li></ul><ul><ul><li>si todas las transacciones las cumplen, o </li></ul></ul><ul><ul><li>el subsistema de control de concurrencia del SGBD las impone (automáticamente) </li></ul></ul><ul><ul><li>... se asegura la serializabilidad de toda planificación de transacciones </li></ul></ul><ul><li>Clasificación </li></ul><ul><ul><li>Métodos de bloqueo </li></ul></ul><ul><ul><li>Métodos de marca de tiempo </li></ul></ul><ul><ul><li>Técnicas de multiversión </li></ul></ul><ul><ul><li>Métodos optimistas </li></ul></ul>Técnicas de control de concurrencia
    19. 19. <ul><li>Uso de bloqueos para controlar el acceso concurrente a los elementos de datos almacenados en la base de datos </li></ul><ul><li>Reglas básicas del bloqueo: </li></ul><ul><ul><li>Bloqueo compartido : si una transacción tiene un bloqueo compartido sobre un elemento de datos, puede leer el elemento, pero no actualizarlo (escribir) </li></ul></ul><ul><ul><ul><li>Varias transacciones pueden mantener a la vez bloqueos compartidos sobre el mismo elemento </li></ul></ul></ul><ul><ul><li>Bloqueo exclusivo : si una transacción tiene un bloqueo exclusivo sobre un elemento de datos, puede leer y actualizar (escribir) el elemento </li></ul></ul><ul><ul><ul><li>Un bloqueo exclusivo proporciona acceso exclusivo al elemento </li></ul></ul></ul>Técnicas de control de concurrencia Métodos de bloqueo
    20. 20. Reglas de uso de los bloqueos 1. T debe emitir bloquear_lectura(X) o bloquear_escritura(X) antes de ejecutar una operación leer_elemento(X) 2. T debe emitir bloquear_escritura(X) antes de realizar una operación escribir_elemento(X) en T 3. T debe emitir desbloquear(X) una vez completadas todas las operaciones leer_elemento(X) y escribir_elemento(X) 4. Si T ya posee un bloqueo, compartido o exclusivo, sobre X no emitirá bloquear_lectura(X) ni bloquear_escritura(X) *esta regla puede permitir excepciones: mejora y reducción de bloqueos* 5. T no emitirá desbloquear(X) salvo si posee un bloqueo, compartido o exclusivo, sobre X Técnicas de control de concurrencia Métodos de bloqueo
    21. 21. <ul><li>Cuando una transacción T solicita un bloqueo… </li></ul><ul><ul><li>Si el elemento no ha sido ya bloqueado por otra transacción, se le concede el bloqueo </li></ul></ul><ul><ul><li>Si el elemento sí está bloqueado, el SGBD determina si la solicitud es compatible con el bloqueo existente: </li></ul></ul><ul><ul><ul><li>Si se pide un bloqueo compartido sobre un elemento que ya tiene un bloqueo compartido, el bloqueo será concedido a T </li></ul></ul></ul><ul><ul><ul><li>En otro caso, T debe esperar hasta que se libere el bloqueo existente </li></ul></ul></ul><ul><li>Una transacción que obtiene un bloqueo lo mantiene hasta que lo libera explícitamente o termina ( commit o rollback ) </li></ul><ul><ul><li>Sólo cuando se libera un bloqueo exclusivo los efectos de la escritura serán visibles para las demás transacciones </li></ul></ul>Técnicas de control de concurrencia Métodos de bloqueo
    22. 22. <ul><li>Algunos sistemas permiten la mejora (o promoción) y la reducción (o degradación) de bloqueos </li></ul><ul><ul><li>Aumenta el nivel de concurrencia del sistema </li></ul></ul><ul><li>Si T emitió bloquear_lectura(X) , más tarde puede mejorarlo a bloqueo exclusivo emitiendo bloquear_escritura(X) </li></ul><ul><ul><li>Si T es la única que tiene un bloqueo compartido sobre X , se le concede la solicitud </li></ul></ul><ul><ul><li>En otro caso, T debe esperar </li></ul></ul><ul><li>Si T emitió bloquear_escritura(X) , más tarde puede reducirlo a un bloqueo compartido emitiendo bloquear_lectura(X) </li></ul><ul><ul><li>Así permite que otras transacciones lean X </li></ul></ul>Técnicas de control de concurrencia Métodos de bloqueo
    23. 23. <ul><li>El uso de bloqueos para la programación de transacciones no garantiza la serializabilidad de las planificaciones </li></ul>Técnicas de control de concurrencia Métodos de bloqueo Transacción T4 bloquear_lectura(Y); leer_elemento(Y); desbloquear(Y); bloquear_escritura(X); leer_elemento(X); X:=X+Y; escribir_elemento(X); desbloquear(X); Transacción T5 bloquear_lectura(X); leer_elemento(X); desbloquear(X); bloquear_escritura(Y); leer_elemento(Y); Y:=X+Y; escribir_elemento(Y); desbloquear(Y); Valores iniciales: X=20, Y=30 Resultados de las planificaciones serie: T4->T5: X=50, Y=80 T5->T4: X=70, Y=50 Resultado de la planificación G: X=50, Y=50 (No serializable!) Planificación G T4 bloquear_lectura(Y); leer_elemento(Y); desbloquear(Y); bloquear_escritura(X); leer_elemento(X); X:=X+Y; escribir_elemento(X); desbloquear(X); T5 bloquear_lectura(X); leer_elemento(X); desbloquear(X); bloquear_escritura(Y); leer_elemento(Y); Y:=X+Y; escribir_elemento(Y); desbloquear(Y);
    24. 24. <ul><li>Es necesario seguir un protocolo adicional que indique dónde colocar las operaciones de bloqueo y desbloqueo dentro de las transacciones </li></ul><ul><li>El más conocido es el Bloqueo en Dos Fases (B2F) </li></ul><ul><li>Una transacción T sigue el protocolo de bloqueo en dos fases si todas las operaciones de bloqueo preceden a la primera operación de desbloqueo </li></ul><ul><li>De este modo, podemos ver T dividida en dos fases : </li></ul><ul><ul><li>Fase de expansión (o crecimiento) </li></ul></ul><ul><ul><ul><li>T puede adquirir bloqueos </li></ul></ul></ul><ul><ul><ul><li>T no puede liberar ningún bloqueo </li></ul></ul></ul><ul><ul><li>Fase de contracción </li></ul></ul><ul><ul><ul><li>T puede liberar bloqueos existentes </li></ul></ul></ul><ul><ul><ul><li>T no puede adquirir ningún bloqueo </li></ul></ul></ul>Técnicas de control de concurrencia Métodos de bloqueo: Bloqueo en dos fases
    25. 25. <ul><li>Si el sistema permite mejorar y reducir bloqueos… </li></ul><ul><ul><li>La mejora sólo puede tener lugar en la fase de expansión </li></ul></ul><ul><ul><li>La reducción sólo puede realizarse en la fase de contracción </li></ul></ul><ul><ul><li>En el código de T , un bloquear_lectura(X) puede aparecer en la fase de contracción de T sólo si reduce un bloqueo exclusivo a uno compartido </li></ul></ul>Técnicas de control de concurrencia Bloqueo en dos fases Transacción T4’ bloquear_lectura(Y); leer_elemento(Y); bloquear_escritura(X); desbloquear(Y); leer_elemento(X); X:=X+Y; escribir_elemento(X); desbloquear(X); Transacción T5’ bloquear_lectura(X); leer_elemento(X); bloquear_escritura(Y); desbloquear(X); leer_elemento(Y); Y:=X+Y; escribir_elemento(Y); desbloquear(Y);
    26. 26. <ul><li>Si toda transacción de una planificación sigue el protocolo de bloqueo en dos fases , entonces la planificación es serializable </li></ul><ul><li>Ventaja </li></ul><ul><ul><li>Ya no es necesario comprobar la serializabilidad de las planificaciones </li></ul></ul><ul><li>Inconvenientes </li></ul><ul><ul><li>El B2F puede limitar el grado de concurrencia en un plan </li></ul></ul><ul><ul><li>Emplear bloqueos puede provocar problemas de ... </li></ul></ul><ul><ul><ul><li>Interbloqueo (bloqueo mortal o abrazo mortal) </li></ul></ul></ul><ul><ul><ul><li>Bloqueo indefinido (o espera indefinida) </li></ul></ul></ul>Técnicas de control de concurrencia Bloqueo en dos fases
    27. 27. <ul><li>T debe bloquear todos los elementos a los que tendrá acceso (lectura o escritura) antes de comenzar a ejecutarse </li></ul><ul><ul><li>Si no es posible bloquear algún elemento, T no bloqueará ninguno y esperará para reintentarlo más tarde </li></ul></ul><ul><ul><li>Protocolo libre de interbloqueo </li></ul></ul>Técnicas de control de concurrencia Bloqueo en dos fases conservador o estático Bloqueo en dos fases estricto el más utilizado <ul><li>T no libera ningún bloqueo exclusivo hasta terminar (con COMMIT o ROLLBACK ) </li></ul><ul><ul><li>Ninguna transacción lee o escribe un elemento modificado por T , salvo si T se ha completado  planificación estricta </li></ul></ul><ul><ul><li>Puede sufrir interbloqueo (salvo si se combina con B2F conservador) </li></ul></ul>Bloqueo en dos fases riguroso más restrictivo que el B2F estricto <ul><li>T no libera ningún bloqueo compartido ni exclusivo hasta terminar (con COMMIT o ROLLBACK )  planificación estricta </li></ul>
    28. 28. <ul><li>Situación en la que cada una de dos (o más) transacciones está esperando a que se libere un bloqueo establecido por la otra transacción </li></ul>Técnicas de control de concurrencia El problema del interbloqueo T6 bloquear_escritura(X); leer_elemento(X); X:=X-10; escribir_elemento(X); bloquear_escritura(Y); [… en espera …] T7 bloquear_escritura(Y); leer_elemento(Y); Y:=Y+100; escribir_elemento(Y); bloquear_escritura(Y); [… en espera …] <ul><li>El SGBD ha de reconocer un interbloqueo y romperlo: </li></ul><ul><ul><li>Abortar una o más transacciones </li></ul></ul><ul><ul><ul><li>Se deshacen sus escrituras y se liberan sus bloqueos </li></ul></ul></ul><ul><ul><ul><li>Así, el resto de transacciones podrá continuar su ejecución </li></ul></ul></ul><ul><ul><li>Reiniciar automáticamente las transacciones abortadas </li></ul></ul>
    29. 29. <ul><li>Hay 3 técnicas generales para gestionar los interbloqueos </li></ul><ul><ul><li>Temporizaciones de bloqueos </li></ul></ul><ul><ul><li>Prevención de interbloqueos </li></ul></ul><ul><ul><li>Detección de interbloqueos </li></ul></ul><ul><li>Conviene detectar interbloqueos cuando se sabe que hay poca interferencia entre transacciones, es decir si... </li></ul><ul><ul><li>Las transacciones son cortas y bloquean pocos elementos, o </li></ul></ul><ul><ul><li>La carga de transacciones es pequeña </li></ul></ul><ul><li>En otro caso, conviene usar temporizaciones o técnicas de prevención </li></ul><ul><li>Es más difícil prevenir que utilizar temporizaciones o que detectarlos y romperlos, por lo que en la práctica los sistemas no suelen emplear las técnicas de prevención </li></ul>Técnicas de control de concurrencia El problema del interbloqueo
    30. 30. <ul><li>Una transacción que solicita un bloqueo sólo esperará durante un período de tiempo predefinido por el sistema </li></ul><ul><li>Si no se concede el bloqueo durante ese tiempo, se producirá un ‘fin de temporización’: el SGBD asumirá que la transacción está interbloqueada (aunque puede que no), la abortará y la reiniciará automáticamente </li></ul><ul><li>Es una solución muy sencilla y práctica </li></ul><ul><li>Pero puede hacer que sean abortadas y reiniciadas transacciones que en realidad no están en un interbloqueo </li></ul>Técnicas de control de concurrencia Temporizaciones de bloqueos
    31. 31. Técnicas de control de concurrencia Prevención de interbloqueos <ul><li>Ordenar las transacciones usando marcas temporales de transacción MT(T): </li></ul><ul><ul><ul><li>Identificador único para T </li></ul></ul></ul><ul><ul><ul><li>Las MT se ordenan según se inician las transacciones </li></ul></ul></ul><ul><ul><ul><li>La T más antigua tiene la MT(T) menor </li></ul></ul></ul><ul><li> Sea T j que intenta bloquear el elemento de datos X , pero X ya está bloqueado por T k con un candado en conflicto </li></ul><ul><li>Algoritmo Esperar - Morir </li></ul><ul><li>si MT(T j ) < MT(T k ) entonces T j puede esperar </li></ul><ul><li>si no, se aborta T j ( T j muere) y </li></ul><ul><li>se reinicia después con la misma marca de tiempo </li></ul><ul><ul><li>Una T j más antigua espera a que termine otra T k más reciente </li></ul></ul><ul><ul><li>Una T j más reciente que solicita un elemento bloqueado por una T k más antigua, es abortada (muere) y reiniciada </li></ul></ul>
    32. 32. Técnicas de control de concurrencia Detección de interbloqueos <ul><li>Si el sistema está en un estado de interbloqueo, el SGBD necesita abortar algunas transacciones... </li></ul><ul><li>¿ Cuáles ?  Selección de víctimas </li></ul><ul><ul><li>Es mejor abortar transacciones que lleven poco tiempo en ejecución </li></ul></ul><ul><ul><li>Es mejor abortar una transacción que haya hecho pocos cambios en la base de datos </li></ul></ul><ul><ul><li>Es mejor abortar una transacción que todavía debe hacer muchos cambios en la base de datos </li></ul></ul><ul><ul><ul><li>Puede que el SGBD no conozca esta información </li></ul></ul></ul><ul><li>Se trata de abortar las transacciones que supongan el mínimo coste </li></ul><ul><li>Es necesario evitar la inanición </li></ul>
    33. 33. <ul><li>Una transacción sufre inanición cuando es seleccionada para ser abortada ( víctima ) sucesivamente: nunca termina su ejecución </li></ul><ul><ul><li>Es similar al bloqueo indefinido </li></ul></ul><ul><li>La solución es asignar prioridades más altas a las transacciones abortadas varias veces, para no ser siempre las víctimas </li></ul>Técnicas de control de concurrencia Detección de interbloqueos: el problema de la inanición
    34. 34. Técnicas de control de concurrencia El problema del bloqueo indefinido <ul><li>El protocolo de control de concurrencia nunca selecciona a una transacción que está esperando para establecer un bloqueo , mientras otras transacciones continúan ejecutándose con normalidad </li></ul><ul><ul><li>Ocurre si el esquema de espera da más prioridad a unas transacciones que a otras  esquema de espera injusto </li></ul></ul><ul><li>Dos algoritmos de prevención de bloqueo indefinido </li></ul><ul><ul><li>Consiguen un esquema de espera justo </li></ul></ul><ul><ul><li>El primero que llega, es el primero en ser atendido </li></ul></ul><ul><ul><ul><li>Las transacciones puede bloquear el elemento X en el orden en que solicitaron su bloqueo </li></ul></ul></ul><ul><ul><li>Aumento de prioridad en la espera </li></ul></ul><ul><ul><ul><li>Cuanto más espera T , mayor es su prioridad </li></ul></ul></ul><ul><ul><ul><li>Cuando T tiene la prioridad más alta de todas, obtiene el bloqueo y continúa su ejecución </li></ul></ul></ul>
    35. 35. <ul><li>Toda técnica de control de concurrencia supone que la base de datos está constituida por un conjunto de elementos de datos con nombre </li></ul><ul><li>Normalmente, un elemento de datos será uno de estos: </li></ul><ul><ul><li>un valor de campo de un registro de la BD </li></ul></ul><ul><ul><li>un registro de la BD </li></ul></ul><ul><ul><li>una página (uno o varios bloques de disco) </li></ul></ul><ul><ul><li>un fichero </li></ul></ul><ul><ul><li>la BD completa </li></ul></ul><ul><li>Granularidad = tamaño del elemento de información </li></ul><ul><ul><li>Granularidad fina  elementos de tamaño pequeño </li></ul></ul><ul><ul><li>Granularidad gruesa  elementos grandes </li></ul></ul>Granularidad de datos Elementos de bases de datos y granularidad
    36. 36. <ul><li>En el contexto de los métodos de bloqueo, el tamaño del elemento de datos afecta al grado de concurrencia: </li></ul><ul><ul><li> tamaño(elemento)   Grado de concurrencia </li></ul></ul><ul><ul><li>Y también... </li></ul></ul><ul><ul><li>  número de elementos en la BD </li></ul></ul><ul><ul><li>  carga de trabajo para la gestión de bloqueos, y </li></ul></ul><ul><ul><li>  espacio ocupado por la información de bloqueo </li></ul></ul><ul><li>Pero... ¿Cuál es el tamaño adecuado para los elementos? </li></ul><ul><ul><li>Pues depende de la naturaleza de las transacciones: </li></ul></ul><ul><ul><li>Si una T representativa accede a pocos registros </li></ul></ul><ul><ul><ul><li>elegir granularidad de registro </li></ul></ul></ul><ul><ul><li>Si T accede a muchos registros de un mismo fichero </li></ul></ul><ul><ul><ul><li>elegir granularidad de página o de fichero </li></ul></ul></ul>Granularidad de datos Elección del tamaño adecuado del elemento de datos

    ×