Control de concurrencia Vamos a discutir los conceptos de gestin de transacciones y el control de coherencia de base de datos.

Gestin de transacciones y su relacin con el procesamiento de transacciones en lnea (OLTP). El servicio de control de concurrencia es el servicio de DBE que es responsable de la consistencia de la base de datos. 5.1 TERMINOLOGA necesitamos tener una mejor comprensin de exactamente lo que una base de datos y una transaccin son: 5.1.1 Base de datos Una base de datos es una coleccin de elementos de datos que tienen un nombre y un valor. El conjunto D {i1, i2 , . . . , IN } representa una base de datos con elementos de datos N . Algunos de estos elementos de datos deben tener un valor, NO son NULL, y algunos pueden tener un valor, son NULL. Aunque esta definicin de la base de datos parece simplista, en realidad, es amplio y puede representar a las bases de datos relacionales, bases de datos orientadas a objetos, bases de datos jerrquicas, bases de datos de red, bases de datos de hojas de clculo y bases de datos de archivos planos . A pesar de que asuma cada elemento de datos tiene un nombre, en realidad, todo lo que estamos diciendo es que cada artculo sea accesible y / o direccionable. 5.1.1.1 Consistencia de BD Cada elemento de datos en la base de datos tiene una afirmacin correccin asociada. Por ejemplo, el nmero de seguro social para el empleado debe ser un valor nico , la edad para que un empleado tiene que ser un nmero positivo , un empleado debe trabajar para uno y slo un departamento , el saldo de una cuenta tiene que ser positiva y ms de $ 100 , y as sucesivamente .

5.1.2 Transaccin Una transaccin es un conjunto de operaciones realizadas en contra de los elementos de datos de la base de datos. Con el fin de saber lo que hace una transaccin, tenemos que saber cundo empieza y cuando termina. Lo hacemos por delinear los lmites de la transaccin, ya sea explcita o implcitamente. La propiedad de atomicidad de una transaccin indica que, o bien todas las operaciones de una transaccin se llevan a cabo o ninguno de ellos se llevan a cabo. Esta propiedad tambin se conoce como la propiedad de "todo o nada. La propiedad de consistencia de una transaccin requiere una transaccin para ser escritas correctamente. Es responsabilidad del programador para implementar el cdigo en el programa correctamente - de modo que el programa lleva a cabo la intencin de la transaccin. La propiedad de aislamiento de una transaccin requiere que la transaccin puede ejecutar sin interferencia de otras transacciones. El aislamiento garantiza que los cambios

de esta transaccin a la base de datos no se ven por ninguna otra transaccin hasta despus de esta transaccin se ha comprometido. La propiedad durabilidad de una transaccin requiere los valores que se confirma la transaccin a la base de datos a ser persistente. Este requisito se limita a establecer que los cambios de base de datos realizados por transacciones confirmadas son permanentes, incluso cuando ocurren fallas en el sistema. 5.1.2.1 Transaccin redefinida Previamente, definimos que una transaccin es un conjunto de operaciones en contra de los elementos de datos de una base de datos sin hablar de ninguna de las propiedades de la transaccin debe satisfacer. Jim Gray [Gray81] define una transaccin de la siguiente manera: Una transaccin es un conjunto de acciones de los usuarios asignados a las operaciones contra los elementos de datos de la base de datos que, si discurre de manera ininterrumpida por otras transacciones y por fallas en el sistema, transfiere la base de datos de un estado consistente a otro estado consistente. Si se anula la transaccin, no cambia el estado de la base de datos.

5.2 SISTEMAS DE PROCESAMIENTO MULTITRANSACTION Un sistema OLTP es un sistema con muchas de las transacciones que se ejecutan en cualquier punto dado del tiempo. Una caracterstica de estos sistemas es el hecho de que las transacciones en un entorno OLTP son transacciones de corta duracin y hacer muchos cambios a la base de datos. Estos sistemas son algo diferentes de procesamiento analtico (OLAP) los sistemas en lnea que apoyan el sistema de soporte de decisiones (DSS ) o el almacenamiento de datos . Las transacciones en los sistemas OLAP son de larga vida y pueden hacer pequeos cambios al almacn de datos. 5.2.1 Horario El horario es el orden total de operaciones para un conjunto de transacciones. Un horario veces se ha llamado una historia en la industria. 5.2.1.1 Programacin de serie Un horario de serie es aquel que contiene las transacciones cuyas operaciones no se solapen en el tiempo. Esto significa que en cualquier punto en el tiempo slo una transaccin se est ejecutando en el sistema. Este programa tambin se conoce como un programa secuencial. 5.2.1.2 Programacin Paralela Un programa paralelo es uno que pueda contener transacciones cuyas operaciones se traslapan en el tiempo. Esto significa que en cualquier punto en el tiempo no puede haber ms de una transaccin activa. Este calendario se llama
paralelo o concurrente.

5.2.2 conflictos Se produce un conflicto cuando dos transacciones en ejecucin realizan operaciones no compatibles en el mismo elemento de datos de la base de datos. Transacciones realizan ya sea leer o escribir operaciones con los elementos de datos en la base de datos. Un conflicto se produce cuando una transaccin escribe un artculo que otra transaccin est leyendo o escribiendo.

5.2.2.1 Lectura irrepetible En horario S1, la transaccin T1 lee dato X antes de la transaccin T2 escribe. El valor que se devuelve por R1 ( X) es el valor de X en la base de datos . El problema con este calendario es que puede dar lugar a lecturas irrepetibles. Supongamos que T1 emite una segunda lectura en X. Esto cambia el horario para "S1 = . . . R1 ( X ) , . . . , W2 ( X ) , . . . , R1 ( X). "Es fcil ver que T1 lee un valor diferente cuando se emite la segunda R1 ( X) a partir del valor se pone cuando se emite la primera R1 ( X). Esto se debe a T2 cambia el valor de X antes de T1 lee de nuevo . 5.2.2.2 Lectura no confirmada de datos En horario de S2, la transaccin T2 lee el valor de la transaccin T1 ha escrito . El problema con este calendario es que permite la transaccin T2 para ver el valor comprometido de las X, que fue modificada por la transaccin T1 . Esto puede conducir a programar " S2 = . . . W1 ( X ) , . . . , R2 ( X ) , . . . , W2 ( X ) , . . . , Commit T2, . . . , Abortar T1 " . En el horario modificado , T2 lee el valor de X escrito por T1, calcula un nuevo valor de X en base a este valor, la escribe en la base de datos y se compromete el nuevo valor a la base de datos . Esto est bien, siempre y cuando T1 tambin se compromete.
5.2.2.3 Sobrescrito Qu causa el problema est permitiendo las transacciones para escribir un artculo sin antes leerlo. Este tipo de escritura se conoce como escritura ciego. 5.2.3 Equivalencia Las transacciones que se ejecutan al mismo tiempo pueden causar conflictos que conducen a las anomalas antes mencionadas. Estas anomalas pueden destruir la consistencia de la base de datos. Por lo tanto, el planificador debe controlar las operaciones conflictivas de transacciones concurrentes. 5.2.4 Horarios serializables Un programa se dice que es serializable si es equivalente a un horario de serie. La comprobacin de la equivalencia planificacin secuencial se conoce como serializacin. A DBE garantiza la consistencia de la base de datos mediante la aplicacin de la secuencialidad. Para entender la secuencialidad, tenemos que centrarnos en cmo el DBE maneja los conflictos. Como se mencion antes, las operaciones programador programan para cada transaccin. Cuando una transaccin entra en el sistema, se le asigna a un monitor de transacciones (TM ) . Cada TM trabaja con el planificador para programar las operaciones de la transaccin que controla. A TM somete las operaciones

de la transaccin al programador una operacin a la vez. El planificador se determinar si la operacin solicitada desde un TM est en conflicto con cualquier otra operacin que ya ha concedido - las operaciones que forman parte de la programacin en este punto en el tiempo. Si la solicitud no est en conflicto con cualquier operacin ya programada , entonces el planificador otorga la operacin y aade que la operacin a la programacin. Si, por el contrario, la solicitud est en conflicto con una o ms de las operaciones ya concedidas, el programador slo concede la operacin si el programa resultante seguir siendo serializable. De lo contrario, la transaccin que solicita se revierte. No es ni prctico ni eficiente para el planificador para que busque slo para los horarios de serie que son equivalentes a los actuales horarios paralelos. Esto se debe a los horarios de serie pueden ralentizar CPUs incluso un servidor de base de datos de alta potencia. El planificador necesita para permitir que los horarios paralelas que son equivalentes a un horario de serie para ejecutar para promover la concurrencia y aumentar el rendimiento. El programador se centra en el impacto que los conflictos tienen sobre el auto de prisin de las transacciones en el horario.

Dos transacciones pueden entrar en conflicto ms de una vez, en funcin de los elementos de datos en cada uno y las operaciones que se realizan. Cada par de operaciones en conflicto en el Programa pone un requisito para el compromiso en las operaciones que soliciten las operaciones. Llamamos el auto de prisin que un par de operaciones en conflicto puesto en el sistema una orden de compromiso parcial (PCO). Sabemos que hay mltiples transacciones en el sistema y no puede haber muchos conflictos entre ellos. Teniendo en cuenta todos los OPC posibles para un horario, llegamos a la conclusin de que el horario es serializable si y slo si ninguna de las OPC son contradictorios. Podemos validar que no hay contradiccin entre los OPC mediante la formacin de un grfico que contiene todos los OPC y la comprobacin de la grfica de la no existencia de ciclo (s). Llamamos a este grfico el orden compromiso total (TCO) grfico. Para resumir la discusin anterior, decimos un horario es serializable si y slo si su TCO es acclico. 5.2.4.1 Serializabilidad en un sistema centralizado En un DBMS centralizado, un horario es serializable si y slo si es equivalente a un horario de serie. Los planificador comprueba conflictos entre cada par de operaciones de transaccin. Para cada conflicto se encuentra, se impone una orden de reclusin parcial (PCO). Poner todas las rdenes de compromiso parciales juntos, el sistema genera un grfico orden total compromiso. Existencia de un ciclo en este grfico indica que el horario no es serializable. De lo contrario, el programa se puede serializar a uno o posiblemente ms ejecuciones de serie de las transacciones en el horario. El planificador comprueba cada vez que una secuencialidad peticiones TM para programar una nueva operacin. Si la concesin de la operacin no da lugar a un ciclo en el orden compromiso total de todas las transacciones cuyas operaciones ya se han programado, se concede la operacin y est prevista la nueva operacin. De lo contrario, la transaccin que solicita se revierte.

5.2.4.2 Serializabilidad en un sistema distribuido En un sistema distribuido, las transacciones se ejecutan en uno o ms sitios. Por lo tanto, el calendario general consiste en una coleccin de sitio local de horarios -cada implicado tiene una programacin local que pueden o no ser serializables. Debera ser obvio que, en un sistema distribuido, si hay un programa local que no es serializable, entonces el programa global que contiene no es serializable. La pregunta que tenemos que abordar es si o no el calendario global es serializable cuando todos los horarios son locales. La respuesta depende de si o no la base de datos se replica. Debera ser bastante obvio que si la base de datos no se replica no hay requisito de coherencia mutua. El requisito de coherencia mutua establece que las copias de elementos de datos de una base de datos deben tener el mismo valor. En una base de datos no replicada, no hay requisito de coherencia mutua. Como resultado, siempre y cuando los horarios locales son serializables, el calendario global es serializable as. 5.2.4.5 Horarios recuperables Son los esquemas que permitan la recuperacin de la base de datos a un estado coherente despus del fracaso de una o varias operaciones. 5.2.4.6 Horarios Cascadeless Asumir en el horario " S = R1 ( X) , W1 (X ) , W1 (Y), R2 ( X) , W2 (X ) , R3 ( X) , W3 ( X) " que ninguna de las transacciones se han comprometido . En este punto en el tiempo, el calendario es recuperable de acuerdo con la definicin anterior. Sin embargo, si la transaccin T1 se deshace, se hace necesario hacer retroceder T2 y T3 tambin. La razn de esto es que T2 y T3 han usado lo que T1 ha escrito a la base de datos. Este tipo de rollback se llama un rollback en cascada, lo que requiere una cantidad significativa de trabajo. 5.2.5 Tipos de transaccin avanzada El modelo de transaccin que hemos discutido hasta ahora se utiliza para hacer cumplir las propiedades ACID. Este modelo de transaccin se destina a apoyar transacciones que tienen un corto perodo de tiempo (normalmente medido en segundos) para finalizar. Este tipo de operaciones se llaman operaciones de corta duracin (TRs). TRs forman la mayor parte de las transacciones en los sistemas informticos de hoy en da. Para SLT, la decisin de confirmar o anular la transaccin se realiza en un perodo relativamente corto de tiempo. Sin embargo, hay transacciones de larga duracin (LLTs) que llevar mucho tiempo (en comparacin con los SLT) para finalizar. LLTs pueden tardar minutos, horas o incluso das para terminar. 5.2.5.1 Sagas Garca-Molina introdujo el concepto de sagas para permitir la gestin de las transacciones largas. Una saga es una LLT que se escribe como una serie de transacciones que pueden ser intercalados con otras transacciones. Negocios jurdicos dentro de una saga deben llevarse a cabo en el orden especificado. Pero, una transaccin dentro de la saga puede ser cometido de forma intercalada con respecto a las otras transacciones fuera de la saga. Esto significa que los subresultados de una transaccin se liberan a otras transacciones o sagas. Tanto el concepto de una saga y su aplicacin son relativamente simples, pero tienen el potencial de mejorar significativamente el rendimiento para ciertas clases de aplicaciones.

5.2.5.2 contratos Reuter introdujo el concepto de contrato como extensin de las sagas, con el fin de hacer frente a algunas de las cuestiones que se encuentra en ejecucin larga de las transacciones. En un contrato, las transacciones incrustadas se definen como un conjunto de pasos anidados que pueden ser compensados de forma independiente. Adems, el flujo de control entre pasos no es. Los pasos dentro de un contrato son capaces de definir el flujo de control por s mismos. En un contrato, el fracaso de un paso puede ser compensado y el contrato puede continuar desde el punto de fracaso. Para ello es necesario el ahorro de la informacin de estado de los pasos (restas), que la BDE subyacente puede apoyar. Hay muchos otros modelos de transaccin que han sido discutidos y propuestos en la literatura para hacer frente a las transacciones de larga ejecucin , dirigindose a sus propiedades ACID y problemas de rendimiento . Algunos de estos modelos se han utilizado para hacer frente a los problemas de transacciones de gestin en los sistemas federados y multibase 5.2.6 Operaciones en sistemas distribuidos En un sistema distribuido, una transaccin puede ser una transaccin local o una mundial. Una transaccin local es una transaccin que realiza todo su trabajo en el sitio donde se origina. En otras palabras, una transaccin local no deja su sitio. Una transaccin global, por otra parte, es una transaccin que tiene que realizar el trabajo en uno o ms sitios diferentes de su sitio de origen. Una transaccin global se lleva a cabo como un conjunto de transacciones locales cada ejecutan como un agente de la transaccin global en un sitio dado. Cada transaccin local es un subtransaccin de una transaccin global. Este introduce un nuevo grado de dificultad en la confirmacin de una transaccin global. 5.3 DBE CENTRALIZADO DE CONTROL DE CONCURRENCIA Una transaccin se inicia en un sitio y se asigna a un monitor de transacciones (TM), la cual fue el encargado de ejecutar la transaccin. El TM es parte del procesador de aplicaciones (AP), como hemos comentado. El TM utiliza el planificador para programar su operacin de operaciones. El planificador genera un horario serializable para todas las transacciones que se ejecutan. 5.3.1 Bloqueo basados en algoritmos de control de concurrencia Utilizan una compatibilidad de bloqueos matriz para determinar si un elemento de datos puede ser bloqueado por ms de una transaccin al mismo tiempo. La matriz de bloqueo es una matriz que indica la compatibilidad de cerraduras en un elemento de datos por dos transacciones. 5.8 Reflejar el conflicto. Un elemento de datos debe estar bloqueado exclusivamente cuando est escribiendo, pero un artculo puede ser encerrado en un modo compartido cuando se est leyendo. puede utilizar ya sea de una sola fase o de dos fases de bloqueo . 5.3.1.1 Bloqueo de bloqueo de una sola fase (1PL) Una fase es un mtodo de bloqueo que requiere que cada transaccin para bloquear un artculo antes de que lo utiliza y liberar el bloqueo tan pronto ya que se ha terminado de utilizarlo.

5.3.1.2 bifsico de bloqueo de dos fases (2PL) Es un bloqueo en el que las transacciones no se intercalan su adquisicin de bloqueo y desbloqueo. El enfoque consiste de dos fases. En la primera fase, las transacciones slo adquieren bloqueos y no lo suelte ningn tipo de bloqueo hasta que todas las cerraduras que necesitan han sido concedidas. En la segunda fase, las transacciones comienzan a liberar los bloqueos y no solicitan ningn bloqueo. Por eso, la primera fase de este enfoque de bloqueo se conoce como fase de crecimiento, mientras que la segunda fase se conoce como contraccin de fase. Los trminos de crecimiento y la disminucin de reflejar el nmero de bloqueos de una transaccin es la celebracin en cualquier punto dado en el tiempo durante su ejecucin . 5.3.1.3 Bloqueo de Bases de Datos Relacionales Una base de datos relacional, las cerraduras pueden ser adquiridas por diferentes partes de la base de datos y a diferentes niveles de jerarqua de base de datos. La mayora de los MDMS relacionales permiten los siguientes principios de bloqueo: Bloqueo de conversin. Si la transaccin ya mantiene un bloqueo sobre un elemento de datos, lo que puede convertir en un modo de bloqueo a otro. Hay dos alternativas para bloquear la conversin Bloque de actualizacin. Esto ocurre cuando una operacin convierte un bloqueo de lectura a una escritura bloqueada. Cuando se emite la solicitud de bloqueo de escritura, el administrador de bloqueos otorga la actualizacin si la transaccin solicitante es el nico que mantiene un bloqueo de lectura en el elemento de datos. De lo contrario, la transaccin solicitante debe esperar a los lectores a liberar los bloqueos. Bloquear. Esto ocurre cuando una operacin convierte un bloqueo de escritura para una lectura bloqueada. No hay problema con el desde la transaccin, la degradacin es la nica transaccin que se mantiene el bloqueo en el elemento de datos. Extensin de bloqueo. Esto sucede cuando una transaccin trata de evitar la adquisicin muchos bloqueos de grano fino, solicitando para bloquear un grnulo grande. Esto podra ser solicitado por la transaccin o se puede aplicar de forma automtica por el DBMS. En este ltimo caso, el DBMS puede establecer un umbral de extensin de bloqueo. Mltiples granularidad de bloqueo (MGL). Este enfoque permite que las transacciones bloqueen artculos en mltiples niveles de la jerarqua. Cuando una transaccin bloquea un grnulo en un nivel superior de la jerarqua, la transaccin tambin se da el bloqueo a todos los grnulos en el subrbol debajo de ella. Los bloqueos pueden ser, como siempre, leer (comunitario), escribir (exclusivos) cerraduras, o de intencin. MGL se impone al exigir la transaccin que quiere fijar un grnulo para bloquear el ancestro (s) de l primero Bloqueo Intencin. Este es un mtodo en el que una transaccin debe informar al BDMS su intencin de bloquear antes de que realmente bloquea el grnulo. La intencin est representada por un bloqueo intencin. Intencin Modos de bloqueo. Hay cinco modos de bloqueo intencin: S: la transaccin se bloquea todo el subrbol en modo compartido (S) . X: la transaccin se bloquea todo el subrbol en modo exclusivo (X

ES: la operacin tiene la intencin de bloquear algn descendiente en el modo S . IX: la transaccin tiene la intencin de bloquear algn descendiente en el modo de X . SEIS ( = S + IX) : la transaccin se bloquea todo el subrbol en modo S ; propone para bloquear algn descendiente en el modo X . 5.3.1.4 Emisin Phantom El trmino "fantasma " se refiere a un problema que es especfico de la forma en que los BDMS relacionales utilizan el bloqueo de filas. Los Phantoms se producen cuando una transaccin de actualizaciones o inserciones cambia el alcance de las filas que otra transaccin que ha bloqueado. 5.3.2 Marca de tiempo de concurrencia Algoritmos de Control utilizan cerraduras para aislar a los elementos de datos que una transaccin est trabajando con otras transacciones de las cuales se les niega el acceso a esos elementos de datos bloqueados. La fecha y hora de la transaccin (edad) tambin puede utilizarse para coordinar el acceso simultneo a elementos de datos de la base de datos en una forma tal que el programa es conflicto Serializable. Este enfoque se conoce como solicitud de marca de tiempo (TO). 5.3.2.1 A Algoritmo de Control de concurrencia Bsico Hay tres reglas que se hacen cumplir . Regla de acceso. Cuando dos transacciones intentan acceder elemento de datos X , al mismo tiempo, con operaciones en conflicto, se da prioridad a la transaccin ms antigua. Regla Transaccin Tardo. Una transaccin de ms edad no se le permite leer o escribir un dato de funcin que ya ha sido escrito por una transaccin ms joven. Esta regla impide que la transaccin mayor tenga que comprometerse despus de la transaccin ms joven que le haya confiado, lo que sera una violacin de la orden de la edad si lo permitiramos Menor Regla Espera Transaccin. Se permite una operacin ms joven para leer o escribir un elemento de datos que ya ha sido escrito por una operacin mayor. 5.3.2.2 Conservador A Algoritmo Una variacin del BASIC para el control de concurrencia que puede eliminar algunos de los reinicios innecesarios se conoce como conservador a pedido. En la conservadora al algoritmo, el control de concurrencia no cursa a solicitud de una operacin mucho ms joven hasta que el sistema haya procesado solicitudes de un nmero suficientemente grande de las transacciones mayores. Por lo tanto, cualquier conflicto de una transaccin ms joven con las transacciones de ms edad se detecta antes de que el sistema confirma una transaccin mucho ms joven. 5.3.2.3 Multiversin algoritmo de control de concurrencia se utilizan sobre todo en la ingeniera en bases de datos, en el que el sistema necesita para mantener la historia de cmo un elemento de datos tiene cambiado con el tiempo .