Capitulo 19

CAPITULO 19 Ll Conceptos sobre procesamiento de transacciones El concepto de transaccién proporciona un mecanismo para describir las unidades l6gicas del.procesamiento de una base de datos. Los sistemas de procesamiento de transacciones son sistemas con grandes bases de datos y cientos de usuarios concurrentes que estén ejecutando transacciones de base de datos. Algunos ejemplos de dichos sistemas son los de reservas, banca, proceso de tarje~ tas de crédito, mercado de valores, cajas de supermercados y otros sistemas similares. Estos sistemas requieren una alta disponibilidad y buen tiempo de respuesta para cientos de usuarios concu- mrentes. En este capitulo presentamos los conceptos que son necesarios en los sistemas de procesamiento de transacciones. Definimos el concepto de transaccién que se utiliza para represen- tar una unidad l6gica de procesamiento de base de datos que debe terminarse completamente para asegurar su correccién. Analizamos el problema del control de Ja concurrencia, que acttia cuando interfieren entre sf mltiples transacciones introducidas por varios usuarios produciendo resultados incorrectos. También estudiamos la recuperacién después de fallar una transaccién: La Seccién 19.1 explica da manera informal por qué son necesarios el control de concurrencia y la recuperaci6n de un sistema de base de datos. La Seccién 19.2 presenta el concepto de transaccin y examina conceptos adicionales relacionados con el procesamiento de transacciones de los sistemas de bases de datos. La Seccién 19.3 presenta los conceptos de atomicidad, conservacién de la consistencia, aislamiento y durabilidad o permanencia (las llamadas propiedades ACID) que se consideran deseables en las transacciones. La Seccién 19.4 presenta el concepto de planes (0 historias) de transacciones en ejecuci6n y caracteriza la recoverability de los planes. En la Seccidn 19.5 se trata el concepto de serializability de las ejecuciones de transacciones concurrentes, que se puede utilizar para definir las secuencias correctas de ejecucién (0 planes) de las transacciones concurrentes. La Seccién 19.6 presenta los recursos que soportan el concepto de transaccién en SQL2. Los dos capftulos siguientes continvian con més detalles sobre las técnicas usadas para soportar el procesamiento de transacciones. El Capitulo 20 describe las técnicas basicas para el control de concurrencia y el Capitulo 21 presenta un panorama sobre las técnicas de recuperacién.598 Fundamentos de sistemas de bases de datos 9.1. Introduccion al procesamiento CMa rts ta celts) En esta seccién presentaremos de manera informal los conceptos de ejecucién concurrente de transacciones y de recuperacién después de fallar una transaccién. En la Seccién 19.1.1 compararemos los sistemas de bases de datos de uno y los de varios usuarios y mostraremos cémo puede darse la ejecucién concurrente de transacciones en un sistema multiusuario. La Seccién 19.1.2 define el concepto de transaccién y presenta un modelo simple de ejecucién de transacciones, basado en operaciones de lectura y escritura de la base de datos, con que se formalizan los conceptos de control de concurrencia y recuperacién. En la Seccién 19.1.3 mostramos con la ayuda de ejemplos informales por qué en los sistemas multiusuario son necesarias las técnicas de control de concurrencia. Por iltimo en la Seccién 19.1.4, para analizar las razones por las que se requieren técnicas que hagan posible recuperarse de fallos, presentaremos las diferentes formas en que pueden fallar Tas transacciones durante su ejecucién. 19.1.1. Sistemas monousuario frente a sistemas multiusuario Un criterio para clasificar los sistemas de bases de datos es por el niimero de usuarios que pueden utilizarlos concurrentemente, es decir, al mismo tiempo. Un SGBD es monousuario si, como mé- ximo, un solo usuario a la vez puede utilizarlo, y es multiusuario si muchos usuarios pueden utilizarlo (y por tanto acceder a la base de datos) al mismo tiempo. Los SGBD monousuario suelen estar restringidos a algunos sistemas de microcomputador, y casi todos los demas SGBD son multiusuario. Por ejemplo, el sistema para reservar vuelos en una Iinea aérea da servicio a cientos de agentes de viajes y empleados de reservas de forma concurrente. En los sistemas de los bancos, de las agencias aseguradoras, de los mercados de valores, supermercados, etc., también operan muchos usuarios que introducen el sistema de transacciones de manera concurrente. EI que muchos usuarios puedan acceder a las bases de datos y utilizar los sistemas de computador al mismo tiempo, se debe al concepto de multiprogramacién, que permite al computador ejecutar simulténeamente varios programas (0 procesos). Si solo hay una unidad central de proceso (UCP), en realidad solo se puede procesar un programa a la vez. Sin embargo, los sistemas opera- tivos de multiprogramacién ejecutan algunas instrucciones de un proceso, luego suspenden ese proceso y ejecutan algunas ordenes del siguiente proceso, y asf sucesivamente. Cuando a un programa le llega el turno de usar la UCP otra vez, se reanuda Ja ejecucién en el punto en el que se suspendi6. Asf pues la ejecucién concurrente de los programas es en realidad intercalada, como se ilustra en la Figura 19.1, donde se muestra Ja ejecucién concurrente de dos procesos A y B de manera intercalada. La intercalacién mantiene ocupada a la UCP cuando un proceso requiere una operacién de entrada o de salida (E/S), como leer un bloque de disco. La UCP se conmuta para gjecutar otro programa en vez de permanecer ociosa durante el tiempo de E/S. La intercalacién ademis evita que los procesos largos retarden los demds procesos. Si el sistema de computador cuenta con miiltiples procesadores (UCP) en hardware, es posible el procesamiento en paralelo de varios procesos, como lo ilustran los procesos Cy D de la Figura 19.1. Casi toda la teoria sobre el control de concurrencia de las bases de datos se ha desarrollado en términos de concurrencia intercalada, por lo que para el resto de este capitulo supondremos este modelo. En un SGBD multiusuario, los elementos de informacién almacenados son los recursos primarios a los que pueden tener acceso concurrente usuarios interactivos o programas de apli- cacién, que constantemente obtienen y modifican informacién de la base de datos.Conceptos sobre procesamiento de transacciones 599 ucP, ucr,, ss Tiempo Figura 19.1. Procesamiento intercalado frente a procesamiento en paralelo de transacciones concurrentes. 19.1.2. Transacciones, operaciones de lectura y escritura, y bufers del SGBD Una transaccién es una unidad légica de procesamiento de la base de datos que incluye una o mis operaciones de acceso a la base de datos, que pueden ser de insercidn, eliminacién, modificacién 0 recuperaci6n. Las operaciones de la base de datos que forman una transaccién pueden estar inser- tadas dentro de un programa de aplicacién 0 pueden especificarse interactivamente a través de un Ienguaje de consulta de alto nivel como SQL. Una forma de especificar los limites de las transacciones es mediante las sentencias explicitas begin transaction (comenzar transacci6n) y end transaction (terminar transaccién) en un programa de aplicacién; en ese caso, todas las operaciones de acceso a la base de datos entre ambas, se consideran parte de una misma transaccién. Un programa de aplicacién sencillo puede contener més de una transaccién si contiene varios delimitadores de transaccién. Si las operaciones de la base de datos en la transacci6n no actualizan la base de datos, sino que sélo recuperan datos, la transaccién se denomina transaccién de sélo lectura. El modelo de base de datos que se utiliza para explicar los conceptos del procesamiento de transacciones esta muy simplificado. Una base de datos se representa bsicamente mediante una coleccién de elementos de datos con nombre. El tamafio de un elemento de datos se denomina granularidad y puede ser un campo de un registro de la base de datos o puede ser una unidad mayor como un registro o incluso un bloque de disco completo. Sin embargo, los conceptos que explicamos son independientes de la granularidad del elemento de los datos. Utilizando este modelo de base de datos simplificado las operaciones basicas de acceso a la base de datos que una tran- saccién puede incluir son: # Leerelemento(X): lee un elemento de la base de datos Hlamado X y lo coloca en una varia ble de programa. Para simplificar nuestra notacién, supondremos que a variable de programa también se lama X. * escribir elenento(X): escribe el valor de Ia variable de programa X en el elemento de la base de datos llamado X. Como vimos en el Capitulo 5, un bloque es la unidad basica de transferencia de datos del disco ala memoria principal del computador. La ejecuci6n de una instruccién leer-elemento(X) incluye los siguientes pasos: 1. Encontrar la direccién del bloque de disco que contiene ¢l elemento X.600 —_ Fundamentos de sistemas de bases de datos 2. Copiar ese bloque de disco en un almacenamiento intermedio (biifer) dentro de a memoria principal (si es que ese bloque no est4 ya en algtin biifer de la memoria principal). 3. Copiar el elemento X del almacenamiento intermedio en la variable de programa llamada X. La ejecucién de una instruccién escribir_elemento(X) incluye los siguientes pasos: 1. Encontrar la direcci6n del bloque del disco que contiene el elemento X. Copiar ese bloque de disco en un biifer dentro de la memoria principal (si es que ese bloque no esté ya en algin bifer de la memoria principal). 3. Copiar el elemento X desde la variable del programa llamada X en el lugar correcto dentro del biifer. 4, Almacenar el bloque actualizado desde el biifer al disco (ya sea de inmediato 0 en algdn momento posterior). El paso 4 es el que de hecho actualiza la base de datos del disco. En algunos casos el biifer no se transfiere de inmediato al disco, por si fuera necesario hacer cambios adicionales en el bifer. Por lo regular, la decisién de cudndo almacenar en disco un bloque modificado que esté en un biifer de la memoria principal corresponde al gestor de recuperacién del SGBD en cooperacién con el sistema operativo subyacente. El SGBD generalmente mantendré un niimero de bufers en la memoria principal que contienen bloques de disco con los elementos de la base de datos que se estén procesando. Cuando dichos bufers estén todos ocupados, y se tiene que copiar en la memoria bloques adicionales de la base de datos, se utiliza alguna politica de reemplazo de bufers para es- coger cules de los bufers actuales deben ser reemplazados. Si el buifer escogido ha sido modificado, debe volverse a escribir en el disco antes de volverse a usar.! Una transaccién deberd incluir funciones leer-elemento y escribir_elemento para tener acceso y actualizar la base de datos. La Figura 19.2 muestra ejemplos de dos transacciones muy simples. El conjunto lectura de una transaccién es el conjunto de todos los elementos que lee la transaccién y el conjunto escritura es el conjunto de todos los elementos que la transaccién escribe. Por ejemplo, el conjunto lectura de 7, en la Figura 19.2 es {X, ¥} y el conjunto escritura es también {X, Y}. Los mecanismos de control de concurrencia y recuperacién se ocupan principalmente de las instrucciones de acceso a la base de datos incluidas en una transaccién. Las transacciones introducidas por los diversos usuarios se podrfan ejecutar de manera concurrente y podrfan acceder y actualizar los mismos elementos de la base de datos. Si esta ejecucién concurrente no se conirola, puede provocar problemas tales como que la base de datos no sea consistente. En la siguiente sec- cién presentaremos de forma informal tres de los problemas que pueden presentarse. @) th o) Te tead_item (X); read_item (X); XaXN; X=X+M; write_item (X); waite_item (X); read_item (Y); Yin YaN; write_item (Y); Figura 19.2. Dos transacciones de ejemplo. (a) Transaccién T,. (b) Transaccién T>. * No analizaremos aqut las politicas de sustitucién de bufers, ya que normalmente se explican en los libros de sistemas operatives,Conceptos sobre procesamiento de transacciones 601 19.1 Por qué es necesario el control de concurrencia Pueden surgir varios problemas cuando las transacciones concurrentes se ejecutan de manera no controlada. Ilustraremos algunos de ellos con referencia a una base de datos simple para hacer reservas en una linea aérea, en la que se almacene un registro por cada vuelo. Cada registro incluye el mimero de asientos reservados por cada vuelo como elemento de informacién con nombre, entre otras informaciones. La Figura 19.2(a) muestra una transacci6n T;, que transfiere N reservas de un vuelo, cuyo niimero de asientos reservados est almacenado en el elemento de la base de datos Hamado X, a otro vuelo, cuyo mimero de asientos reservados est4 almacenado en el elemento de Ja base de datos llamado Y. La Figura 19.2(b) muestra una transaccién mas simple, 7, que se limita a reservar M asientos en el primer vuelo (X) al que hace referencia la transaccién 7,.? Para simplificar nuestro ejemplo, no mostraremos otras partes de las transacciones, como seria la comprobacién de si un vuelo tiene suficientes asientos disponibles antes de reservar més asientos. a) read_item(X); x: Tiempo write_item(X); read jtem(Y); - ee El elemento X tiene un valor incorrecto porque la actualizacién realizada por T; se ha "perdido" (sobreescrito) YN; write_tem(Y); (0) write_itom(x); Time read_item(X); XinXeM; write_item(X); read item(Y); La transaccién T, fllay debe restaurar X a su = aniiguo valor; mientras tanto Tha leido ol valor "Yemporalincorecto de X. Figura 19.3. Algunos problemas que ocurren cuando no se controla la ejecucion concurrente. (a) El problema de la actu ‘én perdida. (b) El problema de la actualizacién 2 Un ejemplo similar, que se usa habitualmente, es el de una base de datos bancaria con una transaccin que realiza la transferencia de fondos de una cuenta X a una cuenta Y, y otra transaccién que realiza tun depésito en la cuenta X.602 Fundamentos de sistemas de bases de datos Cuando se escribe un programa para esta base de datos, tiene como pardmetros los ntimeros de vuelo, sus fechas y el mimero de asientos que se reservarin; por tanto, se puede usar el mismo programa para ejecutar muchas transacciones, cada una con diferentes vuelos y ntimeros de asiento por reservar. En lo que a control de concurrencia concierne, una transaccién es una ejecucién espe- céfica de un programa sobre una fecha, un vuelo y un némero de asientos especfficos. En la Figura 19.2(a) y (b) las transacciones T, y T, son ejecuciones especificas de los programas que hacen referencia a los vuelos especfficos cuyos nimeros de asiento estan almacenados en los elementos de informacién X e Y de la base de datos. Ahora veremos los tipos de problemas a los que podemos enfrentarnos con estas dos transacciones si se ejecutan concurrentemente. El problema de la actualizaci6n perdida. Esto ocurre cuando las transacciones que tienen acceso a los mismos elementos de la base de datos tienen sus operaciones intercaladas de modo que hacen incorrecto el valor de algiin elemento. Supongamos que las transacciones T, y T; se introducen aproximadamente al mismo tiempo, y que.sus operaciones se intercalan como se muestra en la Figura 19.3(a); en tal caso, el valor final del elemento X es incorrecto, porque T, lee el valor de X antes de que T, lo modifique en la base de datos, con lo que se pierde el valor actualizado que resulta de T,. Por ejemplo, si X = 80 al principio (originalmente habfa 80 reservas en el vuelo), N= 5((f, transfiere 5 reservas de asientos del vuelo que corresponde a X al vuelo que corresponde a Y) y M = 4 (Ty reserva 4 asientos en X), el resultado final deberia ser X = 79; sin embargo, en la intercalacién de operaciones de la Figura 19.3(a) es X = 84, porque la actualizacién de T, que eli- miné los 5 asientos de X se ha perdido. El problema de la actualizacién temporal (0 lectura sucia). Esto ocurre cuando una transac- cién actualiza un elemento de la base de datos y Iuego la transaccién falla por alguna raz6n (véase la Seccién 19.1.4). Otra transaccién tiene acceso al elemento actualizado antes de que se restaure a su valor original. La Figura 19.3(b) muestra un ejemplo en el que 7, actualiza el elemento X y después falla antes de completarse, asf que el sistema debe cambiar X otra vez a su valor original. write_tarn(X); readl_hem(X); Tlee X después de restarle N yleeY antes de sumérsele N, asi que el resultado es un resumen incorrecto (disorepancia de N). < Figura 19.3. Algunos problemas que ocurren cuando no se controla la ejecucién concurrent. (c) El problema del resumen incorrecto.Conceptos sobre procesamiento de transacciones 603 Antes de que pueda hacerlo, sin embargo, la transaccién T; lee el valor «temporal» de X, que no se grabaré permanentemente en la base de datos debido al fallo de T,. El valor del elemento X que T, lee se denomina dato sucio, porque fue creado por una transaccién que no se ha completado ni confirmado todavfa; por ello, este problema se conoce también como problema de lectura sucia. Problema del resumen incorrecto. Si una transaccién est calculando una funcién agregada de resumen sobre varios registros mientras otras transacciones estan actualizando algunos de ellos, puede ser que la funcién agregada calcule algunos valores antes de que se actualicen y otros des- pués de actualizarse. Por ejemplo, supongamos que una transaccién 7; esté calculando el nimero total de reservas de todos los vuelos; mientras tanto se esté ejecutando la transacci6n 7. Si ocurre la intercalacién de operaciones que se muestra en la Figura 19.3(c), el resultado de T; serd erréneo por una cantidad N porque T; lee el valor de X después de que se le han restado N asientos; pero lee el valor de Y antes de que se le sumen esos N asientos. Otro problema que puede presentarse es el de la lectura no repetible, en el que una transac- cién T lee un elemento dos veces y otra transaccién 7’ modifica el elemento entre las dos lecturas. Ast, T recibe diferentes valores en sus dos lecturas del mismo elemento. Esto puede ocurrir, por ejemplo, si durante una transaccién de reserva de Iineas aéreas, un cliente esta preguntando sobre Ia disponibilidad de asientos en varios vuelos. Cuando el cliente se decide por un vuelo concreto, entonces la transacci6n lee por segunda vez el ntimero de asientos de dicho vuelo antes de comple- tar la reserva. Por qué es necesaria la recuperacién 19.1 Siempre que se introduce una transaccién a un SGBD para ejecutarla, el sistema tiene que asegu- rarse de que (1) todas las operaciones de la transaccién se superen con éxito y su efecto quede registrado permanentemente en la base de datos, o que (2) la transaccién no tenga efecto alguno sobre la base de datos ni sobre cualquier otra transaccién. El SGBD no debe permitir que se apli- quen a la base de datos algunas operaciones de una transaccién T y otras operaciones de T no lo hagan. Esto puede suceder si una transacci6n falla después de ejecutar algunas de sus operaciones, pero antes de ejecutarlas todas. Tipos de fallos. Los fallos generalmente se clasifican como fallos de la transacci6n, del sistema y de los medios. Hay varias razones por las que una transaccién puede fallar mientras se esta ejecutando: 1. Un fallo del computador (caida del sistema): durante Ja ejecucién de una transaccién se produce un error de hardware, software o de red en el sistema del computador. Los fallos del hardware normalmente son fallos de los medios, por ejemplo, un fallo de la memoria principal. 2. Un error de la transaccién o del sistema: alguna operacién de la transaccién puede hacer que ésta falle, por ejemplo un desbordamiento (overflow) de enteros 0 una division entre cero. También puede haber un fallo de transaccién debido a valores erréneos de los pardmetros o a un error légico de programacién.* Ademés, puede suceder que el usuario interrumpa a propésito la transaccién durante su ejecucién. 3. Errores locales 0 condiciones de excepcién detectadas por la transaccién: durante la eje- cucién de transacciones pueden presentarse ciertas condiciones que requieran la cancela- > En general, una transaccién deberfa probarse completamente para asegurar que no tiene bugs (errores lgicos de pro- gramaci6n).604 Fundamentos de sistemas de bases de datos cién de la transaccién. Por ejemplo, puede que no se encuentren los datos para la transaccidn. Notese que una condicién de excepcién;* como un saldo insuficiente en una base de datos bancaria, puede hacer que se cancele una transaccién, como un reintegro de fondos. Esta excepci6n podria programarse en la propia transaccién y por lo tanto no constituiria un fallo. 4. Imposicién de control de concurrencia: el método de control de concurrencia (véase el Ca- pitulo 20) puede decidir que se aborte la transaccién, para reiniciarla después, porque viola la seriabilidad (véase la Seccién 19.5) 0 porque varias transacciones se encuentran en un estado de abrazo mortal (deadlock). 5. Fallo del disco: algunos bloques de disco pueden perder sus datos por un mal funciona- miento de lectura 0 de escritura o por un fallo de una cabeza de lectura/escritura. Esto puede suceder durante una operacién de lectura o de escritura de la transaccién. 6. Problemas fisicos y catdstrofes: esto se refiere a una interminable lista de problemas que incluyen interrupcién del suministro de energia o aire acondicionado, incendio, robo, sabo- taje, sobreescritura de discos o cintas por error o que el operador haya montado una cinta equivocada. Los fallos de tipo 1, 2, 3 y 4 son més comunes que los fallos de tipo 5 y 6. Siempre que ocurre un fallo del tipo 1 al 4, el sistema debe mantener suficiente informacién para recuperarse del fallo. Los fallos de disco 0 los catastréficos de tipo 5 6 6 no ocurren con frecuencia; si se dan, la re- cuperaci6n es una tarea bastante complicada. En el Capitulo 21 analizaremos la recuperacién de fallos EI concepto de transaccién es fundamental para muchas técnicas de control de concurrencia y de recuperacién de fallos. ah: Pre secs mac lierletedt lM eT ect En esta secci6n analizaremos més conceptos relevantes sobre el procesamiento de transacciones. La Seccién 19.2.1 describe los diferentes estados en los.que puede estar una transaccién y explica las operaciones importantes que son necesarias en el procesamiento de transacciones. La Seccién 19.2.2 explica el fichero diario (Jog) del sistema, que mantiene informacién necesaria para la recu- peraci6n, La Seccién 19.2.3 describe el concepto de puntos de confirmacién de las transacciones y por qué son importantes en el procesamiento de transacciones. 19.2.1. Estados de transacciones y operaciones adicionales Una transaccién es una unidad at6mica de trabajo que se realiza por completo o bien no se efectiia en absoluto. Para fines de recuperaci6n el sistema necesita mantenerse al tanto de cuando la tran- saccién se inicia, termina y se confirma o aborta (véase més adelante), As{ pues, el gestor de recu- peracién se mantiene al tanto de Jas siguientes operaciones: © BEGIN.TRANSACTION (inicio.de_transaccién): ésta marca el principio de la ejecucién de la transacci6n. © READ (leer) 0 WRITE (escribir): éstas especifican operaciones de lectura o escritura de elementos de la base de datos que se ejecutan como parte de la transaccién. * Las condiciones de excepcién, si se programan corectamente, no constituyen fallos de transacci6n,Conceptos sobre procesamiento de transacciones 605. © END_TRANSACTION (fin_de_transaccién): ésta specifica que las operaciones de LEER 0 ES- CRIBIR de la transaccién han terminado y marca el fin de la ejecucién de la transaccién. Sin embargo, en este punto puede ser necesario verificar si los cambios introducidos por la tran- sacei6n se pueden aplicar permanentemente a la base de datos (confirmar) o si la transaccién debe abortarse porque viola la seriabilidad (véase la Seccién 19.5) o por alguna otra raz6n. © COMMIT_TRANSACTION (confirmar_transaccién): ésta sefiala que la transaccién terminéd con éxito y que cualquier cambio (actualizaciones) ejecutado por ella se puede confirmar sin pe- ligro en la base de datos y que no se deshard, * ROLLBACK (restaurar) 0 ABORT (abortar): éstas seffales indican que la transaccién termind sin éxito y que cualquier cambio 0, efecto que pueda haberse aplicado a la base de datos se debe deshacer, La Figura 19.4 muestra un diagrama de transicin de estados que describe el paso de una tran- saccién por sus estados de ejecucién. Una transaccién entra en un estado activo inmediatamente después de que inicie su ejecucién y ahi puede emitir operaciones READ y WRITE. Cuando la tran- saccién termina, pasa al estado parcialmente confirmado. En este punto, algunos protocolos de recuperacién deben asegurar que un fallo en el sistema no provocar4 una incapacidad para registrar permanentemente los cambios hechos por la transaccién (normalmente registrando los cambios en el diario del sistema, del cual hablaremos en la siguiente secci6n).5 Una vez realizada con éxito esta verificacién, se dice que la transaccién ha llegado a su punto de confirmacién y pasa al estado confirmado. Los puntos de confirmacién se tratarén con mayor detalle en la Secci6n 19.2.3. Una vez que una transaccién est4 confirmada, ha concluido con éxito su ejecucién y todos sus cambios se han registrado permanentemente en la base de datos. Sin embargo, una transaccién puede pasar al estado falliido si una de las verificaciones falla 0 si la transacci6n se aborta mientras est en el estado activo. En tal caso es posible que deba hacerse un rollback de la transaccién para anular los efectos de sus operaciones WRITE sobre la base de datos. El estado terminado corresponde al abandono del sistema por parte de la transaccién. La informacién de la transaccién mantenida en Jas tablas del sistema mientras la transaccién se ha estado ejecutando se elimina cuando ésta finaliza. Las transacciones fallidas o abortadas pueden reiniciarse posteriormente, ya sea en forma automética 0 después de reintroducirse por el usuario como transacciones nuevas. Figura 19.4. Diagrama de transicién de estados que ilustra los estados para la ejecucién de transacciones. 5 Bl control de concurrencia optimista (véase la Seccién 20.4) también requiere que se realicen ciertas comprobaciones ‘en este punto con el objeto de asegurar que la transacci6n no ha interferido con otras transacciones que se estén ejecutando.606 Fundamentos de sistemas de bases de datos 19.2.2. El del sistema Para poderse recuperar de los fallos de transacciones, el sistema mantiene un diario (log)® que sigue la pista a todas las operaciones de transacciones que afectan a los valores de la base de datos. Esta informacién puede necesitarse para realizar Ia recuperacién en caso de fallos. El diario se mantiene en disco, de modo que no le afecta ningtin tipo de fallo, mas que los de disco y los catas- tr6ficos. Ademas, periGdicamente se realiza una copia de seguridad del diario en cinta para prote- gerse de los fallos catastréficos. A continuacién mencionaremos los tipos de entradas, denominadas registros del diario, que se escriben en el diario y la accién que realiza cada una de ellas. En estas entradas, T se refiere a un identificador de transacci6n tnico que el sistema genera automé- ticamente y que sirve para identificar cada transaccién: 1. [start-transaction, 7]: indica que se ha iniciado a ejecucién de la transaccién 7. 2. [write_item, 7, X, valor_anterior, nuevo_valor|;: indica que la transaccién T ha cambiado el valor del elemento de base de datos X del valor_anterior al nuevo_valor. [read_item, 7, X]: registra que la transaccién T ley6 el valor del elemento X de la base de datos. % 4. [commit, 7]: indica que la transaccién T terminé con éxito y establece que su efecto se puede confirmar (registrar permanentemente) en Ia base de datos. 5. fabort, 7]: indica que se aborté la transaccién T. Los protocolos de recuperacién que evitan la restauracién (rollback) en cascada (véase la Sec- cién 19.4.2), que son todos los protocolos pricticos, no requieren que las operaciones READ se re- gistren en el diario del sistema. Sin embargo, si el diario se utiliza para otros propésitos tales como auditorfa (mantener un registro de todas las operaciones sobre la base de datos), entonces deberian incluirse dichas entradas. Ademés, algunos protocolos de recuperacién necesitan entradas WRITE més simples que no incluyan nuevo_valor (véase la Seccién 19.4.2). Cabe sefialar que aquf estamos suponiendo que todos los cambios pérmanentes sobre la base de datos ocurren en las transacciones, por lo que la nocién de recuperarse de una transaccién equivale a deshacer 0 rehacer las operaciones de la transaccién individualmente a partir del diario. Si el sistema se cae, podemos recuperar la base de datos a un estado consistente examinando el diario y usando una de las técnicas descritas en el Capitulo 21. Dado que el diario contiene un registro por cada operacién WRITE que altere el valor del algin elemento de la base de datos, es posible desh: cer el efecto de estas operaciones WRITE de una transaccién T rastreando hacia atrds en el diario e iniciando todos los elementos alterados con una operacién WRITE de T con su valor_anterior. También puede ser necesario rehacer las operaciones de una transaccidn si todas sus actualizaciones se han grabado en el diario pero el fallo ocurrié antes de que estemos seguros de que todos esos nuevos_valores se han escrito permanentemente en la actual base de datos en disco.’ Para rehacer el efecto de las operaciones WRITE de una transaccién T debe rastrearse hacia adelante en el diario y cambiar todos les elementos modificados por una funcién ESCRIBIR de T a su nuevo.valor. 19.2.3. Punto de confirmacién de una transaccién Una transaccién 7 Hega a un punto de confirmacién cuando todas sus operaciones que tienen acceso a la base de datos se han ejecutado con éxito y el efecto de todas estas operaciones se ha registrado en el diario. Mas alld del punto de confirmacién, se dice que la transaccién esta confir- © El diario ha veces se denomina journal del SGBD. 7 Las operaciones deshacer y rehacer se explican més detalladamente en el Capitulo 21Conceptos sobre procesamiento de transacciones 607 mada y se supone que su efecto se registré permanentemente en la base de datos. En este momen- to la transacci6n escribe un registro [commit, T] en el diario. Si ocurre un fallo del sistema, busca- mos hacia atrés en el diario todas las transacciones T que han escrito una entrada [start_transac- tion, 7] en el diario pero no han escrito todavfa su entrada [conmit, T]; es posible que durante el proceso de recuperacién haya que restaurar (rollback) estas transacciones para deshacer su efecto sobre la base de datos. Las transacciones que ya escribieron su registro de confirmacién en el diario también deberén haber registrado en él todas sus operaciones WRITE, y por tanto su efecto sobre la base de datos puede rehacerse a partir de los registros del diario. Obsérvese que el fichero del diario debe mantenerse en disco. Como se explicé en el Capitulo 5, la actualizacién de un fichero en disco implica copiar el bloque apropiado del fichero del disco a un biffer de la memoria principal, actualizar el biifer en la memoria principal y copiar el biifer en el disco. Con frecuencia se mantiene uno o mas bloques del fichero diario en los bufers de la memoria principal hasta que se lena de entradas y luego se escribe una sola vez en el disco, en vez de escribirlo cada vez. que se afiade una entrada. Esto ahorra el gasto extra de escribir varias veces en disco el mismo bloque del fichero diario. Cuando se cae el sistema, s6lo las entradas del diario que se han escrito en disco se considera que estan en el proceso de recuperacién, porque puede haberse perdido el contenido de la memoria principal. Por ello, antes de que una transaccién Ilegue a su punto de confirmacién, cualquier porcién del diario que no se haya escrito en el disco todavia, se deberd grabar. Este proceso se denomina forzar la escritura del fichero diario antes de confirmar una transaccién. 19.3. Propiedades deseables en las transacciones Las transacciones atémicas deben poser varias propiedades. Estas se conocen como propiedades ACID (por sus iniciales en inglés) y su cumplimiento~debe estar asegurado por los métodos de control de concurtencia y de recuperacién del SGBD. Las propiedades ACID son: 1, Atomicidad: una transaccién es una unidad at6mica de procesamiento; 0 bien se realiza por completo © no se realiza en absoluto. 2. Conservacién de la consistencia: una transaccién conserva la consistencia si su ejecucién completa lleva la base de datos de un estado consistente a otro. 3. Aislamiento (en inglés /solation): una transaccién deberfa parecer que se esté ejecutando de forma aislada de las demés transacciones. Es decir, la ejecucién de una transaccién no deberfa interferir con otras transacciones que se ejecuten concurrentemente. 4. Durabilidad o permanencia: los cambios aplicados a la base de datos por una transaccién confirmada deben perdurar en la base de datos. Estos cambios no deben perderse por un fallo posterior. La propiedad de atomicidad requiere que ejecutemos una transaccién hasta completarla. Es ob- ligacién del subsistema de recuperacién del SGBD asegurar la atomicidad. Si por alguna raz6n una transacci6n no puede completarse, como por una caida del sistema a la mitad de su ejecucién, el método de recuperacién debe deshacer todos los efectos de la transaccién sobre la base de datos. En general, se considera que la propiedad de conservacién de la consistencia es responsabilidad de los programadores que escriben los programas de base de datos o del médulo del SGBD que asegura el cumplimiento de las restricciones de integridad. Recuérdese que un estado de la base de datos es una coleccién de todos los elementos de datos (valores) almacenados en la base de datos en un momento dado. Un estado consistente de Ia base de datos satisface las restricciones especificadas en el esquema, ademas de. cualquier otra restriccién que deba cumplirse en la base de608 19.4. Planes y recupera Fundamentos de sistemas de bases de datos datos. Los programas de base de datos deben elaborarse de modo que garanticen que, si la base de datos est en un estado consistente antes de ejecutar la transaccién, estard en un estado consistente después de la ejecucién completa de la transaccién, suponiendo que no haya interferencia con otras transacciones. EI aislamiento lo asegura el subsistema de control de concurrencia del SGBD.® Si todas las transacciones no hacen sus actualizaciones visibles a otras transacciones hasta que estén confirmadas, se asegura el cumplimiento de una forma de aislamiento que resuelve el problema de las actualizaciones temporales y elimina las restauraciones (rollback) en cascada (véase el Capitulo 21). Se ha intentado definir el nivel de aislamiento de una transaccién. Se dice que una transaccién tiene aislamiento de nivel 0 (cero) si no sobreescribe las lecturas sucias de transacciones de nivel mis alto, Una transaccién con nivel 1 (uno) de aislamiento no tiene actualizaciones perdidas; y el nivel de aislamiento 2 no tiene actualizaciones perdidas ni lecturas sucias. Por dltimo, el nivel de aislamiento 3 (también llamado aislamiento verdadero) tiene, ademds de las propiedades del grado 2, lecturas repetibles. Para terminar, la propiedad de durabilidad es responsabilidad del subsistema de recuperacién del SGBD. En el Capitulo 21, explicaremos cémo los protocolos de recuperacién refuerzan la durabilidad y la atomicidad. idad Cuando varias transacciones se ejecutan de manera concurrente ¢ intercalada, el orden de ejecucién de sus operaciones constituye lo que se conoce como plan (0 historia). En esta seccién definiremos primero el concepto de plan, y después caracterizaremos los tipos de planes que facilitan la recuperacién cuando ocurren fallos. En la Secci6n 19.5 caracterizaremos los planes en términos de las interferencias provocadas por las transacciones participantes, 1o que conduce a los criterios de seriabilidad y de planes serializables. 1. Planes (historias) de transacciones Un plan (0 historia) P de n transacciones T,, T,, ... T,, €8 un otdenamiento para las operaciones de las transacciones sujeto a la restriccin de que, para cada transaccién T, que participe en P, las operaciones de 7, en P deben aparecer en el mismo orden en que ocurren en T,, Cabe sefialar, sin embargo, que las operaciones de otras transacciones 7, se pueden intercalar con las operaciones de T, en P. Por ahora consideramos que el orden de las operaciones en P es un ordenamiento total, aunque en teoria es posible manejar planes cuyas operaciones formen drdenes parciales (como veremos més adelante). Para el objetivo de recuperacién y control de concurrencia, estamos principalmente interesa- dos en las operaciones de las transacciones read_item (leer_elemento) y write_item (es- cribir_elemento), asf como en las operaciones commit (confirmar) y abort (abortar). Una no- tacién abreviada para describir un plan usa los simbolos r, w, ¢ y a para las operaciones read_item, write_item, conmit y abort, respectivamente, afladiendo como subindice el identificador de la transaccién (ntimero de la transaccién) para cada operacién del plan. En esta notacién, el elemento X de la base de datos que se lee o escribe, sigue a las operaciones r y w entre parénte- ® Estudiaremos los protocolos de control de concurrencia en el Capftulo 20.Conceptos sobre procesamiento de transacciones 609 sis. Por ejemplo, el plan de la Figura 19.3(a), que lamaremos P,, se puede escribir como sigue después de afiadirle las operaciones de confirmacié Pa NOD; MOO; wi); 1); we; wi); De manera similar, el plan de Ia Figura 19.3(b), al que llamaremos P,, se puede escribir como sigue, suponiendo que la transaccién 7, abort6 después de su operacién read_item(Y): Py OD wiX)s ra(%)s wo); m5 a5 Se dice que dos operaciones de un plan estén en conflicto si satisfacen las tres siguientes condiciones: (1) pertenecen a diferentes transacciones; (2) tienen acceso al mismo elemento X; y (3) al menos una de las dos operaciones es write.item(X). Por ejemplo en el plan P,, las operaciones 7(X) y w,(X) estén en conflicto, lo mismo que r,(X) y w,(X), y que w,(X) y w,(X). Sin embargo, las operaciones r,(X) y r,(X) no estdn en conflicto porque ambas son operaciones de lectura; y las operaciones w,(X) y w,(¥) tampoco estén en conflicto, porque operan sobre diferentes elementos de datos, Xe ¥; y las operaciones r,(X) y w;(X) no estén en conflicto porque pertenecen a la misma transaccién. Se dice que un plan P de n transacciones T,, T>, ..., 7, es un plan completo si se cumplen las siguientes condiciones: 1. Las operaciones de P son exactamente las operaciones de T,, T>, ..., T,» incluidas una ope- racién de confirmar (commit) o de abortar (abort) como Ultima operacién de cada transaccidn en el plan. . 2. Para cualquier plan de operaciones de la misma transaccién 7,, su orden de aparicién en P es el mismo que su orden de aparicién en T,, 3. Para dos operaciones cualesquiera en conflicto, una de ellas debe ocurrir antes que la otra en el plan.” La tiltima condicién (3) permite que dos operaciones que no estén en conflicto ocurran en el plan sin definir cudl lo hace primero, dando lugar a la definicién de un plan como un orden par- cial de las operaciones de n transacciones.'® Sin embargo se debe especificar un orden total en el plan para cualquier par de operaciones en conflicto (condicién 3) y para cualquier par de operaciones en la misma transacci6n (condicién 2). La condicién 1 simplemente dice que todas las operaciones en las transacciones deben aparecer en el plan completo. Puesto que toda transaccién ha sido confirmada o abortada, un plan completo nunca contendré transacciones activas al final del plan. En general, es dificil encontrar planes completos en un sistema de procesamiento de transacciones, porque continuamente se estén introduciendo nuevas transacciones en el sistema. Por eso con- viene definir el concepto de proyeccién confirmada C(P) de un plan P, que incluye sélo las operaciones de P que pertenecen a transacciones confirmadas; es decir, transacciones T,, cuya ope- racién de confirmacién c, esté en P. 19.4.2. Caracterizacién de planes basados en su recuperal lad En algunos planes resulta fécil recuperarse de fallos de transacciones, pero en otros dicho proceso puede ser bastante complicado. Por ello, es importante caracterizar los tipos de planes en los cuales ° Te6ricamente no es necesario determinar un orden entre pares de operaciones que no estén en conflicto 1° En Ia prictica, In mayorfa de los planes tienen un orden total de las operaciones. Si se emplea procesamiento en paralelo, es te6ricamente posible tener planes con operaciones parcialmente ordenadas que no estén en conflicto,610 Fundamentos de sistemas de bases de datos es posible la recuperacién, asf como aquellos en los que la recuperacién es relativamente simple. Estas caracterizaciones realmente no proporcionan un algoritmo de recuperacién sino que tinica- mente intentan caracterizar tedricamente los diferentes tipos de planes. En primer lugar, nos gustaria estar seguros de que, una vez de que se ha confirmado una tran- saccién T, nunca ser4 necesario deshacerla (rollback). Los planes que tedricamente satisfacen este ctiterio se denominan planes recuperables y aquellos que no lo satisfacen se denominan no recuperables, y por tanto no se deben permitir. Un plan P es recuperable si ninguna transaccién T de P se confirma antes de se hayan confirmado todas las transacciones 7’ que han escrito un elemento que Tee. Una transaccién T lee de una transaccién T’ en un plan P si 7” escribe primero algtin elemento X y luego T'lo lee. Ademés, 7” no deberd haber sido abortada antes de que T lea el elemento X, y no deberia haber transacciones que escriban X después de que 7’ lo haya escrito y antes de que T lo lea (a menos que estas transacciones, de existir, se hayan abortado antes de que T lea X). Los planes recuperables requieren un complejo proceso de recuperacién como veremos, pero si se guarda la informacién necesaria (en el diario), se puede idear un algoritmo de recuperacién. Los planes (parciales) P, y P, de la seccién anterior son ambos recuperables, ya que satisfacen la defi- nicién anterior, Considérese el plan P’, siguiente, que es el mismo que el plan P, excepto que se le han afiadido dos operaciones de confirmaci6n: Pie QDs 2003 W005 (1s W200} e235 ws C4 P’,es recuperable incluso si sufre un problema de pérdida de actualizacién. Sin embargo consi- dérense los siguientes dos planes (parciales) P. y Pj: Poi (Xs W(X) 12005 11); W(X); €23 a3 Pa OD WiX)3 OO 71s ws WD5 e15 Crs PDs W303 Os WaX)s wis a5 a5 P, no es recuperable porque T; lee el elemento X de T,, y luego se confirma antes de que se confirme T,. Si T, aborta después de la operacién c, en P., el valor de X que T, lee ya no es valido y T, deberd abortar después de haberse confirmado, dando lugar a un plan que no es recuperable. Para que el plan sea recuperable, la operacién c, de P,, debe posponerse hasta después de que T, se confirme, como se muestra en P,; si T, aborta en lugar de confirmarse, entonces T, deberfa también abortar como se muestra en P,, porque el valor de X lefdo ya no es valido. En un plan recuperable, ninguna transaccién confirmada tiene que deshacerse jamAs. Sin em- argo, sf es posible que ocurra un fendmeno llamado restauracién (rollback) en cascada (0 abor- to en cascada), en el que una transaccién no confirmada tiene que deshacerse porque leyé un elemento de una transacci6n fallida, Esto se ilustra en el plan P., donde la transaccién 7; tiene que deshacerse porque leyé el elemento X de T,, y ésta aborté. Como la restauracién en cascada puede consumir mucho tiempo, pues podria ser preciso deshacer un gran mimero de transacciones (véase el Capitulo 21), es importante caracterizar los planes en los que se garantiza que este fendmeno no ocurriré. Se dice que un plan evita la restauracién en cascada (0 sin cascada), si toda transaccién del plan s6lo lee elementos escritos por transacciones confirmadas. En este caso, no se descartaré ningdn elemento leido, y no ocurrira ninguna res- tauracién en cascada, Para satisfacer este criterio, la orden r,(X) del plan P, deberd posponerse hasta después de que T, se haya confirmado (0 abortado), retrasiindose asf T, pero asegurindose que no habré restauracién en cascada si T, aborta. Por iiltimo, hay un tercer tipo de plan, mas restrictivo, llamado plan estricto, en el que las transacciones no pueden leer ni escribir un elemento X hasta que no se haya confirmado (0 aborta-Conceptos sobre procesamiento de transacciones 611 do) la tiltima transaccién que escribié X. Los planes estrictos simplifican el proceso de recupera- cién. En un plan estricto, el proceso de deshacer una operacién write_item(X) de una transaccién abortada consiste simplemente en restaurar la imagen anterior (valor_anterior) de un elemento de datos X. Este simple procedimiento funciona siempre correctamente para planes estrictos, pero puede no funcionar para planes recuperables o sin cascada. Por ejemplo, consideremos el plan P;: P, ¥4(X, 5); A(X, 8); a5 Supongamos que originalmente el valor de X era 9, lo cual es la imagen anterior almacenada en el diario del sistema junto con la operacién w,(X, 5). Si 7, aborta, como en P,, el procedimiento de recuperacién que restaura la imagen anterior de una operacién de escritura abortada restaurard el valor de X a 9, aunque Ja transaccin T, ya lo haya cambiado a 8, lo que da lugar a resultados potencialmente incorrectos. Aunque el plan P, es sin cascada, no es un plan estricto, pues permite a T, escribir el elemento X aunque la transaccién T, que fue la tiltima en escribir X todavia no se haya confirmado (0 abortado). Los planes estrictos no tienen este problem: Ya hemos caracterizado los planes de acuerdo con los siguientes términos: (1) que sean recuperables, (2) que eviten la restauracién en cascada, y (3) que sean estrictos. Por tanto, hemos visto que las propiedades de los planes son condiciones cada vez més rigurosas. Por tanto, la con- dici6n (2) implica a la condici6n (1) y la condicién (3) implica a ambas condiciones (2) y (1), pero lo contrario no es siempre cierto. BT-T ero) jad de los planes En la secci6n anterior, hemos caracterizado los planes baséindonos en sus propiedades de recuperabilidad. A continuacién, caracterizaremos los tipos de planes que se consideran correctos cuando se estan ejecutando transacciones concurrentes. Supongamos que dos usuarios, encargados de las reservas de vuelos en una Ifnea aérea, introducen en el SGBD las transacciones T, y T de la Figura 19.2 aproximadamente al mismo tiempo. Si no se permite la intercalacién de operaciones, slo hay dos posibles resultados: 1. Ejecutar todas las operaciones de la transaccién T, (en secuencia) seguidas de todas las operaciones de la transaccién T; (en secuencia). 2. Ejecutar todas las operaciones de la transaccién T; (en secuencia) seguidas de todas las operaciones de la transaccién 7, (en secuencia). Estas alternativas se muestran en las Figuras 19.5(a) y (b), respectivamente. Si se permite la intercalacién de operaciones, habré muchos érdenes posibles en los que el sistema podré ejecutar las operaciones individuales de las transacciones. En la Figura 19.5(c) se ilustran dos posibles planes. Se utiliza el concepto de seriabilidad de planes para identificar qué planes son correctos cuando las ejecuciones de las transacciones han intercalado sus operaciones en los planes. En esta seccién se define la seriabilidad de los planes, se presenta parte de esta teoria y se explica cémo puede usarse en la préctica. 19.5.1. Planes en serie, no en set y serializables por conflictos Los planes A y B de las Figuras 19.5(a) y (b) se denominan planes en serie porque las operaciones de cada transacciGn se ejecutan de manera consecutiva, sin operaciones intercaladas de la otra tran-612 Fundamentos de sistemas de bases de datos Plan c Pan Figura 19.5. Ejemplos de planes en serie y no en serie en los que intervienen las transacciones T, y Tp. {a) Plan en serie A: T, seguida de T,. (b) Plan en serie B: T, seguida de T,. (c) Dos planes Cy Dno en serie, con intercalacién de operaciones. saccién, En un plan en serie, se llevan a cabo transacciones completas en serie: T, y luego T; en la Figura 19.5(a), y 7; y luego T, en la Figura 19.5(b). Los planes C y D de la Figura 19.5(c) se denominan no en serie porque cada secuencia intercala operaciones de las dos transacciones. En términos formales, un plan P es en serie si, por cada transaccién T que participa en el plan, todas las operaciones de T se ejecutan consecutivamente en el plan; de lo contrario, el plan se denomina no en serie. Por tanto, en un plan en serie s6lo una transaccién est activa cada vez; la confirmacién (0 aborto) de la transaccién activa inicia la ejecucién de la siguiente transaccién. En un plan en serie no hay intercalacién. Una suposicién razonable que podemos hacer, si consideramos que las transacciones son independientes, es que todo plan en serie se considera correcto. La raz6n es que suponemos que toda transacci6n es correcta si se ejecuta por sf sola (por la propiedad de conservaci6n de consistencia de la Secci6n 19.3). Por ello, no importa qué transaccién se ejecuta primero. Siempre que todas las transacciones se ejecuten de principio a fin sin que la interfieran las operaciones de otras transacciones, obtendremos un resultado final correcto en la base de datos. El problema con los planes en serie es que limitan la concurrencia o la intercalacién de las operaciones, En un plan en serie, si una transaccién esta esperando a que se complete una operacién de E/S, no podremos conmutar el procesador a otra transaccién, desperdicidndose asf un tiempo valio- so de la UCP. Ademés, si una transaccién 7 es muy larga, el resto de transacciones deben esperar aConceptos sobre procesamiento de transacciones 613, que 7 complete todas sus operaciones antes de comenzar. Por tanto, generalmente los planes en serie se consideran inaceptables en la practica. Para ilustrar lo anterior, consideremos los planes de la Figura 19.5, y supongamos que los valores iniciales de los elementos de informacién son X = 90, ¥ = 90, y que N= 3 y M = 2. Después de ejecutar las transacciones T, y T;, esperariamos que los valores de la base de datos fueran X =89 e ¥ = 93, de acuerdo con el significado de las transacciones. Y asf es, la ejecucién de cual- quiera de los planes en serie A o B da los resultados correctos. Consideremos ahora los planes no en serie C y D. El plan C (que es el mismo que el de la Figura 19.3(a)) da los resultados X = 92 e Y = 93, donde el valor de X es errdneo, y el plan D da los resultados correctos. EI plan C produce un resultado erréneo debido al problema de la actualizaci6n perdida que vimos en la Seccién 19.1.3; la transacci6n T, lee el valor de X antes de que la transaccién T, lo modifique, asf que s6lo se refleja en la base de datos el efecto de T, sobre X. El efecto de 7, sobre X se pierde, pues T, lo sobreescribe, dando lugar al resultado incorrecto para el elemento X. No obstante, algunos planes no en serie producen el resultado esperado, como el plan D. Nos gustarfa determinar cudles de los planes no en serie dan siempre un resultado correcto y cudles pueden dar resultados erréneos. El concepto con el que se caracterizan planes de esta manera es el de la seriabilidad de un plan, Un plan P de x transacciones es serializable si es equivalente a algtin plan en serie de las mismas n transacciones. Definiremos enseguida el concepto de equivalencia de planes. Obsérvese que existen n! posibles planes en serie de n transacciones y muchos mis posibles planes no en serie. Podemos formar dos grupos disjuntos de planes no en serie: los que son equivalentes a uno (0c mAs) de los planes en serie y, por tanto, son serializables; y los que no son equivalentes a ningén plan en serie, y por tanto no son serializables. Decir que un plan P no en serie es serializable equivale a decir que es correcto, porque es equivalente a un plan en serie, que se considera correcto. La duda que queda es: ;cudindo se consideran «equivalentes» dos planes? Hay varias formas de definir la equivalencia entre planes. La definicién més simple, pero menos satisfactoria, implica comparar los efectos de los planes sobre Ia base de datos. Se dice que dos planes son equivalentes por resultados si producen el mismo estado final en la base de datos. Sin embargo, dos planes distintos pueden producir el mismo estado final por accidente. Por ejemplo, en la Figura 19.6, los planes P, y P, producen el mismo estado final si se ejecutan en una base de datos en la que el valor inicial de X es 100; pero para otros valores iniciales de X los dos planes no son equivalentes por resultados. Ademds, estos dos planes ejecutan diferentes transacciones, por lo que definitivamente no pueden considerarse equivalentes. Por eso la equivalencia por resultados no sirve para definir la equivalencia entre planes. El enfoque més seguro y general para definir la equivalencia de dos planes consiste en no hacer suposi- cin alguna sobre los tipos de operaciones que intervienen en las transacciones. Para que dos planes sean equivalentes, las operaciones que se aplican a cada uno de los elementos de datos afectados por los planes se deben aplicar a ese elemento en el mismo orden en ambos planes. Por lo regular, se aceptan dos definiciones de equivalencia de planes: equivalencia de conflictos y equivalencia por vistas. A continuaci6n haremos un andlisis de la equivalencia por conflictos, que es la definicién més utilizada habitualmente. P Pa Tead_ftem(X); read_item(X); X=X+10; 1A; write_item(X); vrite_item (X)}; Figura 19.6. Dos planes que son equivalentes en resultado por el valor inicial de X= 100, pero que no son equivalentes en general.614 Fundamentos de sistemas de bases de datos Se dice que dos planes son equivalentes por conflictos si el orden de dos operaciones cualesquiera en conflicto es el mismo en ambos planes. Recuérdese lo dicho en la Seccién 19.4.1 respec- to a que dos operaciones de un plan estén en conflicto si pertenecen a diferentes transacciones, tienen acceso al mismo elemento de la base de datos y al menos una de las dos operaciones es write item. Si dos operaciones en conflicto se aplican en diferente orden en dos planes, el efecto de los planes puede ser diferente, ya sea sobre la base de datos o sobre otras transacciones del plan, de modo que los dos planes no son equivalentes por conflictos. Por ejemplo, si una operaci6n de lectura y otra de escritura ocurren en el orden r,(X), w,(X) en un plan P,, y en el orden inverso w,(X), r(x) en un plan P,, el valor que ve la operacién r,(X) puede ser diferente en los dos planes. De manera similar, si dos operaciones de escritura se efectiian en el orden w,(X), w,(X) en un plan Py, y en el orden inverso w,(X), w,(X) en otro plan P2, es posible que la siguiente operacién r(X) de los dos planes lea valores distintos; o bien, si las dos operaciones de escritura son las ultimas que tienen acceso a X en los dos planes, el valor final del elemento X en la base de datos podré ser distinto. Con la nocién de equivalencia por conflictos, definiremos que un plan P es serializable por conflictos*? si es equivalente (por conflictos) a algtin plan en serie P’. En este caso podremos reordenar las operaciones de P que no estén en conflicto hasta formar el plan en serie equivalente P’. Segiin esta definicién, el plan D de la Figura 19.5(c) es equivalente al plan en serie A de la Figura 19.5(a). En ambos planes la operacién read_item(X) de T; lee el valor del elemento X que T, es- cribi6, mientras que las demas operaciones read_iten leen los valores del estado inicial de la base de datos. Ademas en ambos planes 7, es la tiltima transaccién que escribe el elemento Y y T, es la Ultima transaccién que escribe X. Como A es un plan en serie y el plan D es equivalente al A, D es un Plan serializable. Adviértase que las operaciones r,(¥)-y w,(¥) del plan D no estén en conflicto con las operaciones r,(X) y w,(X) ya que tienen acceso a diferentes elementos de datos. Asf pues, podemos ejecutar r,(¥), w,(¥) antes que r,(X), w2(X), dando lugar al plan en serie equivalente T,, T>. El plan C de la Figura 19.5(c) no es equivalente a ninguno de los dos planes en serie posibles A y B, y por tanto no es serializable. Si tratamos de reordenar las operaciones del plan C para encontrar un plan en serie equivalente, fracasaremos porque r,(X) y w,(X) estén en conflicto, lo que significa que no podemos mover r(X) hacia abajo para obtener el plan en serie equivalente T,, T,. De manera similar, como w,(X), w,(X) estén en conflicto, no podemos desplazar w,(X) hacia abajo para obtener el plan en serie equivalente T,, T,. En la Seccién 19.5.4 se examinaré otra definicién de equivalencia m4s compleja llamada equivalencia de vistas, que conduce al concepto de seriabilidad por vistas. 19.5.2. Prueba de seriabilidad por conflictos de un plan Existe un algoritmo sencillo para determinar si un plan es serializable por conflictos. La mayor parte de los métodos de control de concurrencia no comprueban realmente la seriabilidad. Mas bien, se elaboran protocols, o reglas, que garantizan que los planes sean serializables. Analizare- mos aqui el algoritmo para comprobar la seriabilidad por conflictos de los planes a fin de entender mejor dichos protocolos de control de concurrencia, que veremos en el Capitulo 20. El Algoritmo 19.1 puede servir para comprobar si un plan es serializable por conflictos. El algoritmo examina sdlo las operaciones read_item (leer_elemento) y write_item (escribir_ele- mento) del plan para construir un grafo de precedencia (o grafo de serializaci6n), que es un grafo dirigido G = (N, A) que consiste en un conjunto de nodos N = {T,, T», .., T,} ¥ un conjunto de arcos A = {ay, dy, ..., dy}. El grafo contiene un nodo por cada transaccién 7, del plan. Cada arco a, ** Utilizaremos serializable con el significado de serializable por conflictos. Otra definicién de serializable usada en la prictica (néase la Seccién 19.6) es tener lecturas repetitivas, no tener lecturas sucias, ni tampoco registros fantasma (véase la Seccién 20.7.1 para una explicacién sobre los fantasmas),Conceptos sobre procesamiento de transacciones 615 del grafo, tiene la forma (T) + T,), con 1 7;) en el grafo de precedencia, 3. Para cada caso en P en el que T, ejecuta write-item(X) después de que 7, ejecute read_item(X), crear un arco (T,— T,) en el grafo de precedencia 4. Para cada paso en P en el que 7, ejecuta una orden write item(X) después de que 7, ejecute una orden write_item(X), crear un arco (T,—>T,) en el grafo de precedencia. 5. El plan P es serializable si y s6lo si el grafo de precedencia no tiene ciclos. El grafo de precedencia se construye como describe el Algoritmo 19.1. Si hay un ciclo en el grafo de precedencia, el plan P no es serializable (por conflictos); si no hay ciclos, P es serializable. Un ciclo en un grafo dirigido es una secuencia de arcos C = ((T,>T,), (Ty>Ty)s =» (TT) con la propiedad de que el nodo inicial de cada arco, con excepcién de la primera, es el mismo que el nodo final del arco anterior y el nodo inicial de la primera flecha es el mismo que el nodo final de la dltima flecha (la secuencia comienza y termina en el mismo nodo). En el grafo de precedencia, un arco de 7, a T, indica que la transaccién T, debe ir antes que la transaccién 7, en cualquier plan en serie que sea equivalente a P, porque dos operaciones en conflicto aparecen en el plan en ese orden. Si no hay ciclos en el grafo de precedencia, podemos crear un plan en serie equivalente P’ que sea equivalente a P, ordenando las transacciones que participan en P como sigue: iempre que en el grafo de precedencia haya un arco de T, a T,, T, deberd aparecer antes que T, en el plan en serie equivalente a P’."? Obsérvese que los arcos (T, > 7}) en un grafo de precedencia se pueden etiquetar también con el nombre 0 nombres de los elementos de datos que originaron Ia creacién de la flechas. La Figura 19.7 muestra dichas etiquetas en las flechas. Figura 19.7. Construccién de los grafos de precedencia para los planes A a D de la Figura 19.5, con el fin de comprobar la seriabilidad por conflictos. (a) Grafo de precedencia del plan en serie A. (b) Grafo de precedencia del plan B. (c) Grafo de precedencia del plan C (no serializable). {d) Grafo de precedencia para el plan D (serializable, equivalente al plan A). "2 Este proceso de ordenar los nodos de un grafo aciclico se conoce como ordenacién topol6gica.616 — Fundamentos de sistemas de bases de datos © T transaccién 7, ‘wansaccion Tp transaccién Ts read _ttem (X); read item (Y); te itom (X); read tem (Z); read item (Y); ‘wrte_ter (Y);, te. item (¥); wrte_ter (2); (©) transaccién T, ‘ransaccion Ty transaccién Ty read tem (2); read tem (Y); ‘wite_ter (Y); read tem (¥); read tem (2); read item (X); Tiempo | wite_item (X); vwate_itern (¥); | witeitem (2); read item (x); read item (Y) vwarte_item (¥); waite_item (X); Plan E (© wansaccién 7, transaccion Tp transaccion T, read item (Y); read item (2); read iter (X); Tiempo | wite_tem (x; wate item (¥); wte_tem (Z); read, tem (Z); read item (Y); wite_tem(Y); | read item (Y); wite_tem (Y); read item (X); wite_item (X); Plan F Figura 19.8. Otro ejemplo de prueba de seriabilidad. (a) Las operaciones READ y WRITE de tres transacciones T,, T; y Ts, (b) Plan E. (c) Plan F. Generalmente, varios planes en serie pueden ser equivalentes a P si el grafo de precedencia de P no tiene ciclos. Sin embargo, si el grafo de precedencia tiene un ciclo es facil mostrar que no podemos crear ningiin plan en serie equivalente, por lo que el plan P serd no serializable. Los gra-Conceptos sobre procesamiento de transacciones 617 @ Planes en serie equivalentos, Ninguno Raz6n ciclo X(T; +79), ¥(To +7) ciclo X(T, Tp), YZ(To*T), Y(T3 977) Planes en serie equivalentes b= hh 0 Ge) Planes en serie equivalentes, (s) Ty Th —> Te bh h—» Th Figura 19.8. Otro ejemplo de prueba de seriabilidad. (d) Grafo de precedencia para el plan E. {e) Grafo de precedencia para el plan F. (f) Grafo de precedencia con dos planes en serie equivalentes. fos de precedencia creados para los planes A a D de la Figura 19.5 aparecen en las Figuras 19.7(a) a (d), respectivamente. El grafo de precedencia del plan C tiene un ciclo, as{ que no es serializable. EI grafo del plan D no tiene ciclos, de modo que es serializable, y el plan en serie equivalente es T, seguida de T,. Los grafos de los planes A y B no tienen ciclos, como era de esperar, porque los planes son en serie y por tanto serializables. En la Figura 19.8 se muestra otro ejemplo en el que participan tres transacciones. La Figura 19.8(a) ilustra las operaciones read_item y writeitem de cada transaccién, En la Figura 19.8(b) y (c) se muestran dos planes E y F para estas transacciones, respectivamente. Los grafos de precedencia de estos dos planes se muestran en la Figura 19.8(d) y (c). El plan E no es serializable, porque el correspondiente grafo de precedencia tiene ciclos. Ei plan F es serializable y el plan en serie equivalente a F se muestra en la Figura 19.8(e). Aunque s6lo existe un plan en serie equivalente para el plan F, en general puede haber mds de un plan en serie equivalente a un plan serializable dado. La Figura 19.8(f) muestra un grafo de precedencia que representa un plan que tiene dos planes en serie equivalentes.618 Fundamentos de sistemas de bases de datos 19.5.3. Aplicaciones de la seriabilidad Como vimos antes, decir que un plan P es serializable (por conflictos), es decir, que P es equivalente (por conflictos) a un plan en serie, es como decir que P es correcto. Sin embargo, ser seriali: zable no es lo mismo que ser en serie. Un plan en serie presenta un proceso ineficiente porque no se permite la intercalacién de operaciones de diferentes transacciones. Esto puede provocar un bajo aprovechamiento de la UCP mientras una transaccién espera una E/S de disco o a que otra transaccin termine, haciendo el procesamiento bastante més lento. Un plan serializable ofrece los benefi- cios de la ejecucién concurrente sin dejar de ser correcto. En la practica es muy dificil comprobar la seriabilidad de un plan. Casi siempre, el planificador del sistema operativo, que distribuye los recursos para todos los procesos, determina 1a intercala- ci6n de operaciones de transacciones concurrentes, las cuales normalmente se ejecutan como procesos del sistema operativo. Factores como la carga del sistema, el momento de introduccién de las transacciones y las prioridades de los procesos contribuyen al orden en el que se colocan las operaciones de un plan. Por ello es précticamente imposible determinar por anticipado cémo se interca- larén las operaciones de un plan cuando se intenta asegurar la seriabilidad. Si las transacciones se ejecutan a voluntad y luego se comprueba si el plan es serializable, de- beremos cancelar el efecto del plan si resulta que no es serializable. Este es un problema grave que hace poco préctico este enfoque. Por ello, la estrategia que se sigue en casi todos los sistemas préc- ticos es encontrar métodos que garanticen la seriabilidad sin tener que verificar los propios planes. El enfoque adoptado en la mayoria de los SGBD comerciales es disefiar protocolos (conjuntos de teglas) de forma que, si todas las transacciones individuales los siguen o si un sistema de control de concurrencia del SGBD asegura su cumplimiento, garanticen la seriabilidad de todos los planes en los que participen las transacciones. Otro problema es que, cuando las transacciones se estan introduciendo continuamente en el sistema, es dificil determinar cudndo comienza y cudndo termina un plan. La teorfa de la seriabilidad puede adaptarse para resolver este problema considerando exclusivamente la proyeccién confirmada de un plan P. Recuérdese que en la Seccién 19.4.1 se dijo que la proyeccién confirmada C(P) de un plan P incluye sélo las operaciones de P que pertenecen a transacciones confirmadas, Pode- mos definir que un plan P es serializable si su proyeccién confirmada C(P) es equivalente a algiin plan en serie, ya que el SGBD sélo garantiza las proyecciones confirmadas. En el Capitulo 20 estudiaremos varios protocolos de control de concurrencia que garantizan la seriabilidad. La técnica més comén, denominada bloqueo de dos fases, se basa en bloquear elementos de datos para evitar la interferencia entre transacciones concurrentes y reforzar una condi- cidn adicional que garantice la seriabilidad. Esta técnica se utiliza en la mayoria de los SGBD comerciales. Se han propuesto otros protocolos‘? como el ordenamiento por marca de tiempo, donde a cada transacci6n se le asigna una marca de tiempo tinica’y el protocolo garantiza que operaciones cualesquiera en conflicto se ejecutarén en el orden de las marcas de tiempo de las transacciones; los protocolos multiversién, que se-basan en mantener miiltiples versiones de los elementos de datos; y los protocolos optimistas (también llamados de certificacién o validacién), que comprueban las posibles violaciones de la seriabilidad una vez que las transacciones han terminado, pero antes de que sean permitidas 0 confirmadas. 19.5.4. Equivalencia de vistas y seriabilidad por vistas En la Seccién 19.5.1 definimos los conceptos de equivalencia por conflictos para los planes y de seriabilidad por conflictos. Otra definicién menos restrictiva de la equivalencia entre planes se Estos otros protocolos no se han utilizado mucho en la préctica; la mayoria de los sistemas utilizan alguna variante del protocolo de bloqueo de dos fases.Conceptos sobre procesamiento de transacciones 619 denomina equivalencia de vistas. Esto conduce a otra definicién de seriabilidad llamada seriabilidad por vistas. Se dice que dos planes P y P’ son equivalentes por vistas si se cumplen las siguientes tres condiciones: 1, El mismo conjunto de transacciones participa en P y en P’, y P y P’ incluyen las mismas operaciones de esas transacciones. 2. Para cualquier operacién r(X) de T, en P, si el valor de X que lee la operaci6n fue escrito por una operaci6n w,(X) de TZ, (0 si es el valor original de X antes de comenzar el plan), debe cumplirse la misma condicién para el valor de X que lee la operacién r(X) de T, en P’. 3. Sila operaci6n w,(¥) de 7, es la tiltima operacién que escribe el elemento Y en P, entonces w,(¥) de 7, debe ser también la ditima operacién que escribe ¥ en P’. La equivalencia de vistas se basa en la idea de que, en tanto cada operacién de lectura de una transacci6n lea el resultado de la misma operacién de escritura en ambos planes, las operaciones de escritura de ambas transacciones producirdn los mismos resultados. Asi pues, se dice que las operaciones de lectura perciben la misma vista en ambos planes. La condicién 3 garantiza que la ope- racién de escritura final de cada elemento de datos sea la misma en ambos planes, con lo que el estado de la base de datos deberd ser el mismo al final de los dos. Se dice que un plan P es serializable por vistas si es equivalente por vistas a un plan en serie, Las definiciones de seriabilidad por conflictos y por vistas resultan similares si se cumple una condicién conocida como suposicién de escritura restringida en todas las transacciones del plan. Esta condicién establece que cualquier operacién de escritura w(X) en T,, va precedida por una operacién r,(X) en T; y que el valor escrito por w,(X) en T, depende s6lo del valor de X que r,(X) lee. Esto supone que el célculo del nuevo valor de X es una funcién (X) basada en el antiguo valor de X leido de la base de datos. Sin embargo, la definicién de seriabilidad por vistas es menos restrictiva que la de seriabilidad por conflictos si se supone la escritura no restringida, donde el valor escrito por una operacién w,(X) en 7, puede ser independiente de cualquier valor anterior de Ia base de datos. Esto se conoce como escritura ciega, y se ilustra con el siguiente plan P, de tres transacciones 7,: 7,(X), w,(X); T3: w3(X); y Ts: wy): P 7X); wo(X); Wy); Ww3(X)s C43 C25 C33 En P,, las operaciones w,(X) y w3(X) son escrituras ciegas, porque ni 7, ni T; len el valor de X. El plan P, es serializable por vistas, ya que es equivalente por vistas al plan en serie T,, T>, Ts Sin embargo, P, no es serializable por conflictos, pues no es equivalente por conflictos a ningéin plan en serie. Se ha demostrado que cualquier plan serializable por conflicts también es serializable por vistas, pero no viceversa, como lo ilustra el ejemplo anterior. Hay un algoritmo para comprobar si un plan P es serializable por vistas 0 no, pero se ha demostrado que el problema de de- mostrar la seriabilidad por vistas es NP-completo, lo que significa que la probabilidad de,encontrar un algoritmo eficiente en tiempo polinémico para este problema es muy baja. 19.5.5. Otros tipos de equivalencia de planes Hay quienes consideran la seriabilidad de los planes demasiado restrictiva como condicién para asegurar la correccién de las ejecuciones concurrentes. Algunas aplicaciones pueden producir planes correctos satisfaciendo condiciones menos exigentes que la seriabilidad por conflictos o la seriabilidad por vistas. Un ejemplo de ellas son las transacciones de cargo y abono, como las que aplican depésitos y reintegros a un elemento de datos cuyo valor es el saldo actual de una cuenta bancaria, La seméntica de las operaciones de cargo y abono es que actualizan el valor de un ele-620 Fundamentos de sistemas de bases de datos mento de datos X reduciendo o aumentando el valor de dicho elemento. Dado que las operaciones de resta y de suma son conmutativas, es decir, se pueden realizar en cualquier orden, es posible producir planes correctos que no sean serializables. Por ejemplo, consideremos las dos transaccio- hes siguientes, cada una de las cuales puede servir para transferir una cantidad de dinero entre dos cuentas bancarias: Ty: 7,3 X: = X ~ 10; w,C0)3 71); ¥: = ¥ + 10; w,(H); Ta raf = ¥— 20; w,(¥); r(X); X: = X + 20; wp6 Consideremos el siguiente plan no serializable para las dos transacciones: Pa 1003 W003 093 was 71.03 wi); 72003 w2(X); Con el conocimiento adicional, 0 seméntica, de que las operaciones entre cada r,(J) y w,(J) son conmutativas, sabemos que el orden de ejecutar las secuencias que consisten en (leer, actualizar, escribir) no es importante mientras que no se interrumpa ninguna de estas secuencias por alguna transaccién 7; sobre un determinado elemento J debido a operaciones en conflicto. Por esto, se considera que el plan P, es correcto aunque no sea serializable. Algunos investigadores han estado tratando de extender la teorfa del control de la concurrencia para manejar casos en los que la seriabilidad se considera una condicién demasiado restrictiva para la correccién de planes. 9.6. Soporte de transacciones en SQ! La definicién de una transaccién SQL es similar al concepto de transaccién ya definido. Es decir, es una unidad l6gica de trabajo y se garantiza que es atémica. Una tnica sentencia SQL se considera siempre que es at6mica, tanto si completa su ejecucién sin errores como si falla y deja la base de datos sin modificar. Con SQL, no hay una sentencia explicita begin_transaction. El inicio de una transaccién se realiza implicitamente cuando se encuentran determinadas sentencias de SQL. Sin embargo, toda transacci6n ha de tener una sentencia explicita de final, que puede ser COMMIT (confirmar) 0 ROLL- BACK (deshacer o restaurar). A toda transaccién se le atribuyen ciertas caracteristicas que se especifican con la sentencia SET TRANSACTION de SQL2. Estas caracterfsticas son el modo de acceso, el tamaiio del drea de diagnéstico y el nivel de aislamiento. El modo de acceso puede especificarse como READ ONLY (solo lectura) 0 READ WRITE (leer y escribir). El valor por defecto es READ WRITE, a menos que se especifique el nivel de aislamiento de lectura no confirmada (READ UNCONMITTED) que veremos més adelante, en cuyo caso se supone READ ONLY. Un modo de READ WRITE permite que se ejecuten instrucciones de modificar, insertar, borrar y crear. Un modo de READ ONLY, como su nombre implica, se usa solamente para recupera- cién de dato La opcién de tamafio del area de diagnéstico, DIAGNOSTIC SIZE n, especifica un valor entero 1n, que indica el mimero de condiciones que se pueden tomar simultineamente en el area de diag- néstico. Estas condiciones suministran al usuario informacién de feedback (errores 0 excepciones) sobre las sentencias de SQL ejecutadas mas recientemente. La opcién del nivel de aislamiento se especifica utilizando la sentencia ISOLATION LEVEL , donde el valor para puede ser READ UNCOWMITTED (lectura no confirmada), READ COMMITTED (lectura confirmada), REPEATABLE READ (lectura repetible), 0 SERIA-Conceptos sobre procesamiento de transacciones 621 LIZABLE (serializable).'* El nivel de aislamiento por defecto es SERIALIZABLE, aunque algunos sistemas usan por defecto READ COMMITTED. El uso del término SERTALIZABLE aqui se basa en no permitir violaciones que causen lecturas sucias, lecturas no repetibles ni fantasmas'® y por tanto no es idéntico a la definicién que se dio de seriabilidad en la Seccidn 19.5. Si una transaccién se ejecuta en un nivel de aislamiento mas bajo que SERTALIZABLE, entonces pueden ocurrir una o més de las siguientes tres violaciones: 1. Lectura sucia: una transaccién T, puede leer la actualizacién de la transacci6n T;, que todavia no se ha confirmado. Si T; falla y se aborta, entonces T, habria lefdo un valor que no existe y es incorrecto. 2. Lectura no repetible: una transaccién 7, puede leer un determinado valor de una tabla. Si otra transacciGn T, actualiza més tarde dicho valor y T, lee de nuevo el valor, 7, veré un valor diferente. 3, Fantasmas: una transacci6n 7, puede leer un conjunto de filas de una tabla, quiz basadas en una condicién especificada en una cléusula WHERE de SQL. Supéngase que una transac- cién T, inserta una nueva fila que también satisface la condici6n de la cldusula WHERE usada en T,, en la tabla utilizada por 7. Si T, se repite, entonces T, verd un fantasma, una fila que previamente no existfa. La Tabla 19.1 resume las posibles violaciones para los diferentes niveles de aislamiento. Una entrada de «si» indica que la violacién es posible y una entrada de «no» indica que no es posible. Una transaccién SQL de ejemplo podria ser la siguiente: EXEC SQL WHENEVER SQLERROR GOTO UNDO; EXEC SQL SET TRANSACTION READ WAITE DIAGNOSTICS SIZE 5 ISOLATION LEVEL SERIALIZABLE; EXEC SQL INSERT INTO EMPLEADO (ENOMBRE, LNOMBRE, NSS, DNO, SALARIO) VALUES (‘Robert', ‘Smith’, '991004321', 2, 35000); EXEC SQL UPDATE EMPLEADO SET SALARIO = SALARIO * 1,1 WHERE DNO = 2; EXEC SQL COMMIT; GOTO THE_END; UNDO: EXEC SQL ROLLBACK; THE-END: «65 Tabla 19.1. Violaciones posibles basadas en los niveles de aislamiento definidos en SQL. _ Tipo de violacion Nivel de Lectura Lectura aislamiento sucia no repetible. — Fantasma LECTURA NO CONFIRMADA si si si LECTURA CONFIRMADA, no st si LECTURA REPETIBLE no no si SERIALIZABLE no no no 18 Son similares a los niveles de aislamiento explicados brevemente al final de la Seccién 19. 45 Los problemas de lectura sucia y de lectura no repetible se explicaron en la Seccién 19.1.3. Los fantasmas se comen- tardn en la Seccién 20.6.1622 Fundamentos de sistemas de bases de datos La transaccién anterior primero inserta una nueva fila en la tabla EMPLEADO y después actualiza el salario de todos los empleados que trabajan en el departamento 2. Si ocurriera algtin error en alguna de las sentencias de SQL, la transaccién completa se desharfa (rollback). Esto implica que cualquier salario actualizado (por esta transaccién) serfa restaurado a su valor inicial y que la fila insertada serfa eliminada. Como hemos visto, el SQL proporciona varias caracteristicas orientadas a transacciones. El ABD 0 los programadores de la base de datos pueden beneficiarse de estas opciones para intentar mejorar el rendimiento de las transacciones. Esto pueden hacerlo relajando la seriabilidad siempre que sea aceptable para sus aplicaciones. CTT En este capitulo analizamos conceptos de SGBD para el procesamiento de transacciones, Presenta- mos el concepto de transaccién de base de datos y las operaciones que intervienen en dicho procesamiento. Comparamos los sistemas monousuario y multiusuario y Iuego examinamos algunos ejemplos de cémo 1a ejecucién no controlada de transacciones concurrentes en un sistema multiusuario puede dar pie a resultados y valores incorrectos en la base de datos. También vimos los diversos tipos de fallos que pueden ocurrir durante la ejecucién de transacciones, Después presentamos los estados por los que puede pasar una transaccién durante su ejecucién, y analizamos varios conceptos que se usan en los métodos de recuperacién y de control de concurrencia. El diario del sistema sigue los pasos a los accesos a la base de datos y el sistema utiliza esta informacién para recuperarse de los fallos. Una transaccién o bien tiene éxito y Hega a su punto de confirmacién o falla y debe deshacerse. Las modificaciones de una transaccién confirmada se gra- ban permanentemente en la ‘base de datos. Presentamos un resumen sobre las propiedades deseables de las transacciones, denominadas atomicidad, conservacién de consistencia, aislamiento (isolation) y durabilidad, a las que se suele llamar propiedades ACID. Después definimos un plan (0 historia) como una secuencia de ejecucién de las operaciones de varias operaciones con una posible intercalacién. Seguidamente caracterizamos los planes en tér- minos de recuperabilidad. Los planes recuperables garantizan que, una vez confirmada una opera- cién, nunca tendr4 que anularse. Los planes sin cascada afiaden una condicién para asegurar que ninguna transacci6n abortada requerir4 que otras transacciones se aborten en cascada. Los planes estrictos proporcionan una condicién atin ms fuerte que permite un esquema de recuperacién simple, el cual consiste en escribir los antiguos valores de los elementos que hayan sido modificados por una transaccién abortada. Posteriormente definimos la equivalencia entre planes y vimos que un plan serializable es equivalente a algtin plan en serie. Definimos los conceptos de equivalencia de conflictos y equivalencia de vistas, que conducen a los conceptos de seriabilidad por conflictos y seriabilidad por vistas. Se considera que un plan serializable es correcto. Después presentamos algoritmos para comprobar la seriabilidad (de conflictos) de un plan. Analizamos por qué la comprobacién de la seriabilidad no es practica en un sistema real, aunque puede servir para definir y verificar los protocolos de control de concurrencia, y mencionamos brevemente otras definiciones menos restrictivas de la equivalencia entre planes. Finalmente, dimos una visin breve de cémo se utilizan los conceptos de transac- cién en la préctica con SQL. En el Capitulo 20 trataremos los protocols de control de concurrencia y en el Capitulo 21 estudiaremos los protocolos para la recuperacién.Conceptos sobre procesamiento de transacciones 623. Preguntas de repaso ab 3 19.2. 19.3. 19.4, 19.5, 19.6. 19.7. 19.8. 19.9, 19.10. 19.11. 19.12. 19.13. Ejercicios 19.14, 19.15. 19.16. 19.17. {Qué significa ejecucién concurrente cuando hablamos de transacciones de bases de datos en un sistema multiusuario? Comente por qué es necesario el control de concurrencia y dé ejemplos informales. Explique los diferentes tipos de fallos. Qué significa fallo catastr6fico? Analice las operaciones que realizan read_item (leer_elemento) y write_item (escri- bir_elemento) en una base de datos. Dibuje un diagrama de estados y analice los estados por los que suele pasar una transac- én durante su ejecucién. {Para qué sirve el diario del sistema? {Qué tipos de registros suele contener el diario? {Qué son los puntos de confirmacién de las transacciones y por qué son importantes? Explique las propiedades de atomicidad, durabilidad, aislamiento y conservacién de la consistencia de una transaccién de base de datos. {Qué es un plan (historia)? Defina los conceptos de plan recuperable, plan sin cascada y plan estricto, y comparelos segtin su recuperabilidad. Indique las diferentes medidas de equivalencias entre transacciones. {Qué diferencia hay entre la equivalencia de conflictos y la equivalencia de vistas? {Qué es un plan en serie? {Qué es un plan serializable? {Por qué se considera correcto un plan en serie? ;Por qué se considera correcto un plan serializable? {Qué diferencia hay entre las suposiciones de escritura restringida y no restringida? {Cuél es més realista? Explique cémo se aplica la seriabilidad para imponer el control de concurrencia en un sistema de base de datos. {Por qué a veces se considera la seriabilidad demasiado restrictiva como medida de correccién de los planes? Describa los cuatro niveles de aislamiento del SQL2. Defina las violaciones causadas por cada una de las siguientes: lectura sucia, lectura no repetible y fantasmas. Modifique la transacci6n T de la Figura 19.2(b) de modo que sea: read_item(X) ; XH if X > 90 entonces exit else write_item(X) ; Analice el resultado final de los diferentes planes de la Figura 19.3(a) y (b), donde M = 2 y N = 2, respecto a las siguientes preguntas. La adici6n de la condicién anterior, zaltera el resultado final? ,Obedece el resultado a la regla de consistencia implicita (de que la capa- cidad de X es 90)? Repita el Ejercicio 19.12 afiadiendo un control en T,-de modo que ¥ no exceda de 90. ‘Afiada la operaci6n commit al final de las transacciones 7; y T, de la Figura 19.2; luego haga una lista de todos los planes posibles para las transacciones modificadas. Determine cudles dé los planes son recuperables, cudles son sin cascada y cudles son estrictos. Haga una lista con todos los planes posibles para las transacciones T, y T de la Figura 19.2 y determine cudles son serializables por conflictos (correctos) y cudles no.624 Fundamentos de sistemas de bases de datos 19.18. ;Cudntos planes en serie existen para las tres transacciones de la Figura 19.8(a)? ;Cusles son? {Cudl es el ntimero total de planes posibles? 19.19, Escriba un programa para ctear todos los planes posibles para las tres transacciones de la Figura 19.8(a) y para determinar cules de esos planes son serializables por conflictos y cuales no. Para cada plan serializable por conflictos, el programa deberd imprimir el plan y una lista de todos los planes en serie equivalentes. 19.20. ;Por qué se necesita una sentencia explicita de fin de transaccién (end_transaction) en SQL2 pero no una sentencia explicita de comienzo (begin_transaction)? 19.21. Describa las situaciones donde pueda ser titil cada uno de los diferentes niveles de aisle miento en el procesamiento de transacciones. : 19.22. {Cuailes de los siguientes planes son serializables (por conflictos)? Para cada plan serializable, determine los planes en serie equivalentes. 1.743 7300; 42s 00; W300; 2. rs 73%); 302; 1X); 72%); 3. 7300s 72003 #520; 003 W100: 4.13 Q)s 2003 10D; waX); WO); 19.23. Considérense tres transacciones T,, T y Ty, y los planes P, y P, dados a continuacién, Dibuje los grafos de seriabilidad (precedencia) para P, y P,, y establezca si cada uno de los planes es serializable o no. Si un plan es seralizable, escriba debajo el plan (0 planes) en serie equivalente. Ty Os Ds wi; 8 Ds 0); w2(Z); wa); 2173005 733 wa); Pu ns 1D (D3 Qs 74; 100; 3); 72(¥); w(Z; wD; Px QO: Dj 73003 (Zi rs 5 4; wy(Z); (Vs wo); 19.24. Considere los planes P,P, y Ps que se muestran debajo. Determine si cada plan es estric- to, sin cascada, recuperable, o no recuperable. (Determine la condici6n de recuperabilidad més estricta que satisfaga un plan.) Px rs Qi (Zs rs rs wis 13 was €55 (Ds w(Z)s we); 33 Pa AOD} Di Dj 75005 ros ws ws 723 ws ws 43 eo C53 Psi Qs Ds 3s (Zi raW)s rs (Hs 43 was wa; was 33 93 as Bibliografia seleccionada El concepto de transaccién se analiza en Gray (1981). El libro de Bernstein, Hadzilacos y'Good- man (1987) est4 dedicado a las técnicas de control de concurrencia y recuperacién en sistemas de bases de datos, tanto centralizados como distribuidos; es una referencia excelente. El libro de Papa- dimitriou (1986) ofrece una perspectiva més tedrica. Un libro de referencia de mas de mil paginas, Gray y Reuter (1993), ofrece una perspectiva més practica sobre los conceptos y técnicas del pro cesamiento de transacciones. Elmagarmid (1992) y Bhargava (1989) ofrecen colecciones de artfcu- los de investigaci6n sobre el procesamiento de transacciones. El soporte de transacciones en SQL2 se describe en Date y Darwen (1993). Los conceptos de seriabilidad se presentaron por primera vez en Gray et al. (1975). La seriabilidad de vistas se define en Yannakakis (1984). La recuperabilidad de los planes se analiza en Hadzilacos (1983, 1988).

Capitulo 19

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Capitulo 19

Uploaded by

Copyright:

Available Formats

You might also like