7/13/2019 Tes 1232

1/82

Benemrita Universidad Autnoma de Puebla

Facultad de Ciencias de la Computacin

ADMINISTRACIN DE TRANSACCIONESEN BASES DE DATOS,

CASO DE ESTUDIO: MySQL

TESIS PROFESIONAL

PARA OBTENER EL TTULO DE:

LICENCIADO EN CIENCIASDE LA COMPUTACIN

PRESENTA:

JUAN ANGEL TABOADA MONDRAGN

ASESOR:

MARIA DEL ROCO BOONE ROJAS

OCTUBRE 2010

7/13/2019 Tes 1232

2/82

2

AGRADECIM IENTO

A mis padres, por su apoyo y sacrificio incondicional durante mis estudios y mivida personal, por sus sabios consejos, desvelos, amor, cario, comprensin,

paciencia y dedicacin; espero se sientan orgullosos de la persona que hanformado y que Dios me los conserve por mucho tiempo. Uds. son mi ejemplo aseguir y una parte muy importante en mis xitos.

A mi esposa Mariana y a mis hijos Angel Emiliano y Zoe Amairany, que llegaron adarle un impulso y sentido importante a mi vida, a ser mi motor y el de mis metas,por Uds. seguir siempre adelante y juntos llegaremos a cumplir nuestros msgrandes anhelos. Confo en Dios en que nos ayude en tener la inteligencia,fortaleza, dedicacin y coraje para que podamos salir siempre adelante.

A mis hermanas y hermanos Pepe , Coco, Toa, Eric, Mary y Rafa, gracias por

su valioso e incondicional apoyo, por estar siempre conmigo, tanto en las buenas,como en las malas, por sus consejos, sus palabras de aliento, ustedes tambin sonparte muy importante de lo que soy.

A mis sobrinas y sobrinos Ary, Edna, Lauris, Andy, Claus, Miry, Yessi, Ana, Erick,Emanuel, Rafa, Ayla, Uriel por el haberme hecho participe en su bella infancia, poresos gratos momentos que pasamos en familia. Me siento muy orgulloso deustedes.

A todos mis amigos, por su gran apoyo incondicional, confianza, lealtad y gratosmomentos de sano esparcimiento.

A mis Maestros, por su disposicin, entrega, enseanzas, consejos y apoyo; elconcluir con esta etapa de mi vida. Uds. han forjado mi carrera profesional conbuenos cimientos, espero no defraudarlos y contribuir con mi granito de arenapara que este pas crezca y lleguemos a ser una mejor y gran nacin.

7/13/2019 Tes 1232

3/82

3

NDICE GENERALPAGINA

INTRODUCCIN.4

1. CONCEPTOS FUNDAMENTALES DE LA ADMINISTRACIN DETRANSACCIONES. 6

1.1. Definicin de Transaccin... 71.2. Sistema de uno y de varios usuarios. 81.3. Estados de las transacciones y operaciones adicionales.. 91.4. Operaciones de lectura y escritura en una transaccin 111.5. Bitcora de sistema. 121.6. Punto de confirmacin de una transaccin 131.7. Puntos de control en la bitcora del sistema.. 141.8. Propiedades deseables en las transacciones 141.9. Tipos de Transacciones. 15

1.9.1. Transacciones de larga duracin.. 151.9.2. Transacciones anidadas. 171.9.3. Transacciones de compensacin.. 181.9.4. Implementacin 191.9.5. Restricciones temporales 20

2. RECUPERACIN DE TRANSACCIONES EN BASES DE DATOS 21

2.1. Por qu es necesaria la recuperacin?................................................... 222.2. Tipo de Fallos.. 242.3. Recuperacin del sistema y de los medios de almacenamiento 272.4. Falla del sistema. 282.5. Falla de los medios de almacenamiento 302.6. Confirmacin de dos fases 30

3. CONTROL DE CONCURRENCIA. 32

3.1. Por qu es necesario el control de concurrencia?...................................333.2. Planificaciones en serie y en paralelo. 333.3. Protocolos basados en bloqueo... 373.4. El protocolo de bloqueo de dos fases.. 413.5. Protocolos basados en grafos.. 433.6. Protocolos basados en hora de entrada.. 453.7. Protocolo de ordenacin por hora de entrada 463.8. Protocolo Basado en Validacin.. 483.9. Protocolo en rbol.. 503.10. Esquema multiversin.. 533.11. Las operaciones insertar y suprimir.. 543.12. Bloqueo Mortal o Deadlock.... 55

7/13/2019 Tes 1232

4/82

4

PAGINA

4. CASO DE ESTUDIO: TRANSACCIONES EN MySQL. 604.1. Caractersticas de MySQL 614.2. Tipos de tablas usadas por MySQL 61

4.3. Que es un Stored Procedure?..................................................................

634.3.1. Stored Procedures: Ventajas.. 634.3.2. Creando un Stored Procedure en MySQL. 644.3.3. Cursores. 644.3.4. Que es un trigger?............................................................................. 64

4.4. Transacciones 654.5. Transacciones en MySQL. 67

4.5.1. Transacciones en MySQL: bloqueos.. 684.5.2. Transacciones en MySQL: ejemplos.. 69

ANEXO A... 74

CONCLUSIONES. 77

BIBLIOGRAFA.78

7/13/2019 Tes 1232

5/82

5

INTRODUCCIN.

Antecedentes.

Un sistema de bases de datos completo ha de ofrecer por fuerza varios recursos

adicionales, aparte de las funciones bsicas de acceso a datos, y un conocimientogeneral de la tecnologa de bases de datos no sera completo si no se entendieranhasta cierto punto esos recursos adicionales. Los recursos en cuestin, unconjunto un tanto heterogneo, se puede dividir en dos categoras amplias: losproporcionados por el DBMS en s y los proporcionados por algn subsistema deseccin frontal o por una aplicacin integrada u otro componente auxiliar.

Antes que nada, la informacin en una base de datos esta sujeta a varios posiblespeligros (tanto deliberados como accidentales). Por ejemplo, un disco podra sufrirun dao fsico o destruirse, o ciertos daos confidenciales, podran quedarexpuestos a un usuario no autorizado. Por tanto, el sistema, o en trminos msprecisos el DBMS base, deber ofrecer un conjunto apropiado de controles paraproteger la base de datos contra ese tipo de riesgos. Entre los controlesnecesarios para desarrollar nuestro tema estn los de recuperacin yconcurrencia. Los problemas de recuperacin y concurrencia en un sistema debase de datos estn muy vinculados a la nocin de procesamiento de informacin.

Nota: Suponemos en la mayor parte de esta tesis que se est en un ambientegrande o de macro computador. Los DBMS pequeos suelen ofrecer poco oningn apoyo para la recuperacin y la concurrencia; la cuestin concurrenciasencillamente no es pertinente y la recuperacin se considera como problema delusuario (el usuario debe preparar copias de respaldo de la base de datos yrehacer su trabajo en forma manual si se presenta una falla).

Existen diversos modelos de transacciones propuestos para actividades de largaduracin, interactivas y cooperativas en el contexto del desarrollo de un softwarepara mltiples usuarios y ambientes CAD/CAM (Computer Aided Design, DiseoAsistido por Cumputadora)/(Computed Aided Manufacturin, Manufactura Asistidapor Computadora). Muchas de esas son variantes del modelo checkout , el cualdirecciona la larga duracin y la naturaleza interactiva de las actividadessoportadas por estos ambientes, pero todava asla a los usuarios del ambiente,puesto que su fabricacin hace difcil su interaccin mientras algunas actividadesse estn ejecutando. Sin embargo pocos modelos de transacciones cooperativasse han propuesto para facilitar la colaboracin, mientras mantengan algunas

garantas de consistencia.Las transacciones de las bases de datos convencionales garantizan la atomicidaden dos sentidos: atomicidad de concurrencia, para accesos concurrentesconsistentes, y la atomicidad del fracaso, persistencia consistente.Desafortunadamente, estas propiedades de atomicidad limitan severamente la El modelo bsico checkout, es apoyado por numerosas herramientas fabricadas comercialmente para el desarrollo desoftware (ejemplo,Ad ele[Estublier en 1984], DFEE[Leblang y Chase en 1987], SMS[Schwanke en 1989]). Katz en 1990da una apreciacin comprensiva de la versin y configuracin de sistemas orientados hacia ambientes CAD/CAM.

7/13/2019 Tes 1232

6/82

6

aplicacin del concepto de transaccin con respecto a modernas aplicaciones enbases de datos tal como el desarrollo de software y ambientes CAD/CAM, aunquetodava estas aplicaciones requieren de un acceso concurrente constante ypersistente.

Desde una perspectiva de las transacciones, los ambientes multiusuario se

caracterizan por: Su larga duracin actividades que consisten en secuencias de accesos a la

base de datos que pueden durar de minutos a meses. El rollback detransacciones largas, funciona en uno de dos sentidos, para el control deconcurrencia o la recuperacin de fallas, el cual es generalmente inaceptabledebido al costo econmico y mortal del trabajo perdido.

El control interactivo los usuarios escogen las acciones dentro de susactividades cuando las estn realizando. Es usualmente inconveniente elplanear la programacin a prioridad de transacciones, y automticamenterehacer actividades que son a menudo no factibles.

La cooperacin entre usuarios los usuarios comparten resultados parcialesde sus actividades mientras se encuentran en proceso. La serializabilidad es aveces incompatible con la consistencia, cuando el esfuerzo es conjunto, senecesita tomar la base de datos desde un estado consistente semnticamente aotro.

Objetivo General.

Identificar, analizar y realizar una experimentacin bsica de mecanismos yproblemas que plantean la recuperacin y control de concurrencia de bases dedatos basada en transacciones.

ESTRUCTURA DEL DOCUMENTO

El presente trabajo de tesis se encuentra organizado en 4 captulos que son:

Capitulo 1. En este captulo, se incluyen los conceptos fundamentales de laadministracin de transacciones y tipos de transacciones.

Capitulo 2.Se define la necesidad por la cual la recuperacin de transaccioneses indispensable, detallando algunos conceptos, los cuales son de sumaimportancia para el xito de una transaccin.

Capitulo 3. Se explican los principales conceptos y la necesidad del control de

concurrencia para el manejo de transacciones en un ambiente de mltiplesusuarios.

Capitulo 4. Se propone un caso de estudio para analizar las transaccionesmediante MySQL, en donde se ejemplifican diferentes tipos de transacciones queson ejecutadas por usuarios, a la vez de caracterizar cada una de las mismas.

Al final se encuentran las conclusiones y perspectivas del trabajo as como labibliografa utilizada.

7/13/2019 Tes 1232

7/82

7

Capitulo 1. CONCEPTOS FUNDAMENTALES DE LAADMINISTRACIN DE TRANSACCIONES.

En el captulo uno, se definirn los conceptos fundamentales de laadministracin de transacciones y tipos de transacciones, para comprender elsignificado de Transaccin y sus caractersticas.

7/13/2019 Tes 1232

8/82

8

1. CONCEPTOS FUNDAMENTALES DE LA ADMINISTRACIN DETRANSACCIONES.

Las aplicaciones de bases de datos a gran escala, con bases de datos de grantamao y con cientos de usuarios concurrentes, como los sistemas de reservas,los bancos, la bolsa, etc., requieren una alta disponibilidad, tiempo de respuestamnimo para cada uno de los usuarios concurrentes que est utilizando el sistema.Las aplicaciones de bases de datos suelen ser sistemas a los que accedenconcurrentemente varios usuarios por lo que es posible que varios usuarios estnintentando acceder simultneamente a los mismos datos. Esta situacin esespecialmente delicada cuando alguno o varios de estos usuarios han intentandomodificar los datos que estn siendo utilizados por los otros usuarios, de formaque hay que controlar la gestin y el acceso a los datos en este tipo desituaciones, esto se consigue mediante el uso de transacciones.

1.1. Definic in de Transaccin.

Una transaccin, de acuerdo Elmasri [10 y 11], es una unidad lgica de trabajo oprocesamiento: ejecucin de un programa que incluye operaciones de acceso a labase de datos.

Una transaccin es una secuencia de operaciones que llevan la base de datosdesde un estado de consistencia a otro estado de consistencia, por esto sueledecirse tambin que la transaccin es una unidad lgica de integridad.

Cuando mltiples transacciones son introducidas en el sistema por varios usuarios,es necesario evitar que interfieran entre ellas de forma tal que provoquen que laBD que den en un estado no consistente; desde este punto de vista, podemos veruna transaccin como una unidad lgica de concurrencia.

Si ocurre un fallo que provoca la cada del sistema de bases de datos, cuandohaba varias transacciones en curso de ejecucin, muy probablemente los datosen la BD quedaran errneos (estado inconsistente debido a un fallo); en estascircunstancias, se debe garantizar que la BD pueda ser recuperada a un estado enel cual su contenido sea consistente, observando las transacciones queterminaron su ejecucin y las que quedaron a medio; por esto una transaccin esconsiderada tambin una unidad lg ica de recuperacin.

La idea clave es que una transaccin debe ser atmica, es decir, las operacionesque la componen deben ser ejecutadas en su totalidad o no ser ejecutadas enabsoluto.

Una sentencia de definicin o manipulacin de datos ejecutada de formainteractiva (por ejemplo utilizar el SQL*Plus de Oracle para realizar una consulta)puede suponer el inicio de una transaccin. Asimismo, la ejecucin de unasentencia SAL por parte de un programa que no tiene ya una transaccin enprogreso, supone la iniciacin de una transaccin.

El conjunto de valores almacenados en la base de datos cumple toda restriccin de integridad especificada en elesquema, as como cualesquiera otras restricciones que deban cumplirse en la B. D.

7/13/2019 Tes 1232

9/82

9

Toda transaccin finaliza con una operacin de commit(confirmar) o bien con unaoperacin de rollback(anular, abortar o revertir).

Tanto una operacin como la otra puede ser de tipo explicito (si la propiatransaccin (su cdigo) contiene una sentencia COMMIT o ROLLBACK) oimplcito (si dicha operacin es realizada por el sistema de forma automtica, por

ejemplo tras detectar una terminacin normal (xito) o normal (fallo) de latransaccin).

Por defecto, una vez finalizada una transaccin, si todas sus operaciones se hanrealizado con xito, se realiza un COMMIT implcito de dicha transaccin; y sialguna de ellas tuvo problemas, se lleva a cabo un ROLLBACK implcito de latransaccin (es decir, se deshacen todas las operaciones que haba realizadohasta el momento del fallo).

1.2. Sistema de uno y de varios usuarios.

Un criterio para clasificar los sistemas de bases de datos, es por el nmero de

usuarios que pueden utilizarlos de manera concurrente, es decir, al mismo tiempo.Un DBMS es monousuario si un slo usuario a la vez puede utilizarlo y esmultiusuario si muchos usuarios pueden utilizarlo al mismo tiempo. Los DBMSmonousuario suelen estar restringidos a algunos sistemas de microcomputador ycasi todos los dems DBMS son multiusuarios.

El que muchos usuarios puedan utilizar los sistemas de computador al mismotiempo se debe al concepto de multiprogramacin, que permite al computadorprocesar simultneamente varios programas (o transacciones). Si slo hay unaunidad central de procesamiento (UCP), en realidad slo se puede procesar unprograma a la vez. Sin embargo, los sistemas operativos de multiprogramacin

ejecutan algunas rdenes de un programa, luego suspenden ese programa yejecutan algunas rdenes del siguiente programa y as sucesivamente. Cuando aun programa le llega el turno de usar la UCP otra vez, se reanuda su ejecucin enel puerto en el que se suspendi. As pues, la ejecucin concurrente de losprogramas es en realidad intercalada, como se ilustra en la figura 1.1, donde semuestra la ejecucin concurrente de dos programas Ay Bde manera intercalada.La intercalacin mantiene ocupada a la UCP cuando un programa en ejecucinrequiere una operacin de entrada o de salida (E/S), como leer un bloque de undisco. La UCP se conmuta para ejecutar otro programa en vez de permanecerociosa durante el tiempo de E/S.

Figura 1.1 Concurrencia intercalada vs. simultnea.

A A

B B C

D

t ie m p o

U C P 1

U C P 2

t1 t2 t3 t4

A A

B B C

D

t ie m p o

U C P 1

U C P 2

t1 t2 t3 t4

7/13/2019 Tes 1232

10/82

10

Si el computador cuenta con mltiples procesadores (UCP) en hardware, esposible el procesamiento simultneo de varios programas, dando lugar a unaconcurrencia simultnea, no intercalada, como lo ilustran los programas Cy Ddela figura 1.1. Casi toda la teora sobre el control de concurrencia en las bases dedatos, se desarroll en trminos de la concurrencia intercalada, aunque se puede

adaptar a la concurrencia simultnea.En un DBMS multiusuario, los elementos de informacin almacenados son losrecursos primarios a los que pueden tener acceso concurrente los programas deusuarios, que constantemente obtienen informacin de la base de datos y lamodifican. En un sentido amplio, a la ejecucin de un programa que lee o modificael contenido de la base de datos es a lo que llamamos una transaccin.

Como se dijo antes, la ejecucin de un programa que incluye operaciones deacceso a la base de datos se denomina transaccin de base de datos osimplemente transaccin .

1.3. Estados de las transacciones y operaciones adicionales.Una transaccin, de acuerdo Elmasri [10 y 11], es una unidad atmica de trabajoque se realiza por completo o, bien, no se efecta en absoluto. Para fines derecuperacin, el sistema necesita mantenerse al tanto de cuando la transaccin seinicia, termina y se confirma o aborta. As pues, el gestor de recuperacin semantiene al tanto de las siguientes operaciones:

INICIO_DE_TRANSACCIN: Esta marca el principio de la ejecucin de latransaccin.

LEER o ESCRIBIR: Estas especifican operaciones de lectura o escritura de

elementos de la base de datos que se efectan como parte de unatransaccin.

FIN_DE_TRANSACCIN: Esta especifica que las operaciones de LEER yESCRIBIR de la transaccin han terminado y marca el lmite de la ejecucinde la transaccin. Sin embargo, en este punto puede ser necesario verificarsi los cambios introducidos por la transaccin se pueden aplicarpermanentemente a la base de datos (confirmar) o si la transaccin debeabortarse porque viola el control de concurrencia o por alguna otra razn.

COMMIT_TRANSACCIN: Este seala que la transaccin termin conxito y que cualesquier cambios (actualizaciones) ejecutados por ella se

pueden confirmar sin peligro en la base de datos y que no se cancelaran.

ROLLBACK (o ABORTAR): Esta indica que la transaccin termin sin xitoy que cualesquier cambios o efectos que pueda haber aplicado a la base dedatos se deben cancelar.

Si las operaciones de base de datos en una transaccin no actualizan datos, sino que slo los leen, se habla de unatransaccin de slo lectura.

7/13/2019 Tes 1232

11/82

11

Adems de las anteriores, algunas tcnicas de recuperacin requierenoperaciones adicionales como las siguientes:

DESHACER: Similar a rollback, pero se aplica a una sola operacin y no auna transaccin completa.

REHACER: Esta especifica que ciertas operaciones de transaccin sedeben repetir (rehacer) para asegurar que todas las operaciones de unatransaccin confirmada se hayan aplicado con xito a la base de datos.

La figura 1.2muestra un diagrama de transicin de estados que describe el pasode una transaccin por sus estados de ejecucin. Una transaccin entra en unestado activo inmediatamente despus de que inicia su ejecucin y ah puedeemitir operaciones LEER y ESCRIBIR. Cuando la transaccin termina, pasa alestado parcialmente confirmado. En este punto, algunas tcnicas de control deconcurrencia requieren que se efecten ciertas verificaciones para garantizar quela transaccin no interfiera otras transacciones en ejecucin. Por aadidura,algunos protocolos de recuperacin deben asegurar que un fallo del sistema no

provocar una incapacidad para registrar permanentemente los cambios hechospor la transaccin (usualmente asentando los cambios en una bitcora delsistema, de la cual hablaremos en la siguiente subseccin). Una vez realizadascon xito ambas verificaciones, se dice que la transaccin ha llegado a su puntode confirmacin y pasa al estado confirmado. Los puntos de confirmacin setratarn con mayor detalle en la seccin 1.5. Una vez que una transaccin est enel estado confirmado, ha concluido con xito su ejecucin.

Figura 1.2. Diagrama de transicin de estados para la ejecucin de transacciones.

Sin embargo, una transaccin puede pasar al estado fallido si una de lasverificaciones falla o si la transaccin se aborta mientras est en el estado activo.En tal caso, es posible que la transaccin deba revertirse para anular los efectosde sus operaciones ESCRIBIR sobre la base de datos. El estado terminadocorresponde al abandono del sistema por parte de la transaccin. Lastransacciones fallidas o abortadas pueden reiniciarse posteriormente, ya sea enforma automtica o despus de reintroducirse como transacciones nuevas.

ACTIVA PARCIALMENTECONFIRMADA

CONFIRMADA

FALLIDA TERMINADA

INICIO_DE_TRANSACCIN

FIN_DE_TRANSACCIN

ABORTAR ABORTAR

CONFIRMAR

LEER_ESCRIBIR

7/13/2019 Tes 1232

12/82

12

1.4. Operaciones de lectura y escri tura en una transacc in.

Al hablar de las tcnicas de control de concurrencia y de recuperacin nosocuparemos de las transacciones en el nivel de elemento de informacin ybloques de discos [10 y 11]. En este nivel, las operaciones de acceso a la base dedatos que una transaccin puede incluir son:

Leer_elemento(X): Lee un elemento de la base de datos llamado X y locoloca en una variable de programa. Para simplificar nuestra notacin,supondremos que la variable de un programa tambin se llamaX.

Escribir_elemento(X):Escribe el valor de la variable de programa Xen elelemento de la base de datos llamado X.

Un bloquees la unidad bsica de transferencia de datos del disco a la memoriaprincipal del computador. En general, un elemento de informacin ser un campode algn registro de la base de datos, aunque puede ser una unidad mayor, comoun registro o incluso un bloque completo.

La ejecucin de una orden leer_elemento(X)incluye los siguientes pasos:

1. Encontrar la direccin del bloque de disco que contiene el elementoX.2. Copiar ese bloque de disco en un almacenamiento intermedio (buffer)

dentro de la memoria principal (si ese bloque no est ya enalmacenamiento intermedio).

3. Copiar el elemento X del almacenamiento intermedio a la variable deprograma llamadaX.

La ejecucin de una orden escribir_elemento(X)incluye los siguientes pasos:

1. Encontrar la direccin del bloque de disco que contiene el elementoX.

2. Copiar ese bloque de disco en un almacenamiento intermedio dentro de lamemoria principal (si ese bloque no est ya en almacenamientointermedio).

3. Copiar el elemento X desde la variable de programa llamada X al lugarcorrecto dentro del almacenamiento intermedio.

4. Transferir el bloque actualizado desde el almacenamiento intermedio aldisco (ya sea de inmediato o en algn momento posterior).

(a) leer_elemento(X);X:=X-N;escribir_elemento(X);

leer_elemento(Y);Y:=Y+N;escribir_elemento(Y);

(b) leer_elemento(X);X:=X+M;escribir_elemento(X);

Figura 1.3 Dos transacciones simples. (a) La transaccin T1. (b) La transaccin T2.

El paso 4 es el que de hecho actualiza la base de datos en disco. En algunoscasos el almacenamiento intermedio no se transfiere de inmediato al disco, por sifuera necesario hacer cambios adicionales en el buffer. Por lo regular, la decisin

7/13/2019 Tes 1232

13/82

13

sobre cuando almacenar en disco un bloque modificado que est en unalmacenamiento intermedio corresponde al gestor de recuperacin o el sistemaoperativo.

Para tener acceso a la base de datos, una transaccin deber incluir operacionesleer_elemento y escribir_elemento. La figura 1.3 muestra ejemplos de dostransacciones muy simples. Los mecanismos de control de concurrencia y derecuperacin se ocupan principalmente de las rdenes de acceso a la base dedatos incluidas en una transaccin.

Las transacciones introducidas por los diversos usuarios se podran ejecutar demanera concurrente y podran leer y actualizar los mismos elementos de la basede datos. Si esta ejecucin concurrente no se controla, puede provocar que labase de datos no sea consistente. Mas adelante presentaremos de manerainformal tres de los problemas que pueden presentarse cuando se ejecutan sincontrol las transacciones concurrentes.

1.5. Bitcora del sistema.

Para poderse recuperar de los fallos de transacciones [10 y 11], el sistemamantiene una bitcora . La bitcora se mantiene en disco, de modo que no laafecta ningn tipo de fallo, ms que los de disco o catastrficos. Adems labitcora se respalda peridicamente en cinta para protegerse contra falloscatastrficos. A continuacin mencionaremos los tipos de entradas que sedescriben en la bitcora y la accin que realiza cada una de ellas. En estasentradas, T se refiere a un identificador de transaccin nico que el sistemagenera automticamente y que sirve para identificar cada transaccin:

1. (inicio_de_transaccin, T): Asienta que se ha iniciado la ejecucin de la

transaccin T.2. (escibir_elemento, T, X, valor_anterior, nuevo_valor): Asienta que latransaccin T cambi el valor del elemento de base de datos X devalor_anterior a nuevo_valor.

3. (leer_elemento, T, X): Asienta que la transaccin T ley el valor delelemento de base de datosX.

4. (commit, T): Asienta que la transaccin Ttermin con xito y establece quesu efecto se puede confirmar (asentar permanentemente) en la base dedatos.

5. (rollback, T): Asienta que se abort la transaccin T.

Los protocolos de recuperacin que evitan las reversiones en cascada norequieren que las operaciones LEER se asienten en la bitcora del sistema, perootros protocolos s necesitan estas entradas para la recuperacin. En el primercaso, el costo extra de asentar las operaciones en la bitcora se reduce, porqueen ella se registran menos operaciones, slo las de ESCRIBIR. Adems, losprotocolos estrictos requieren entradas ESCRIBIR ms simples que no incluyennuevo_valor.(A veces llamada diario) La bitcorasigue la pista a todas las operaciones de transacciones que afectan los valores de

elementos de la base de datos.

7/13/2019 Tes 1232

14/82

14

Cabe sealar que aqu estamos suponiendo que las transacciones no se puedenanidar. Tambin suponemos que todos los cambios permanentes de la base dedatos ocurren dentro de las transacciones, as que la nocin de recuperase de unatransaccin equivale a deshacer o rehacer las operaciones recuperablesindividualmente a partir de la bitcora. Si el sistema se cae, podemos recuperar la

base de datos a un estado consiente examinando la bitcora. Dado que la bitcoracontiene un registro de cada operacin ESCRIBIR que altera el valor de algnelemento de la base de datos, es posible deshacer (cancelar) el efecto de estasoperaciones ESCRIBIR de una transaccin T, rastreando hacia atrs en labitcora y reestableciendo todos los elementos alterados con una operacinESCRIBIR de T a su valor_anterior. Tambin podemos rehacerel efecto de lasoperaciones ESCRIBIR de una transaccin T rastreando hacia delante en labitcora y cambiando todos los elementos modificados por una operacinESCRIBIR de Ta su nuevo_valor. Puede ser necesario rehacer las operacionesde una transaccin si todas sus actualizaciones estn asentadas en la bitcora,pero ocurre un fallo antes de que estemos seguros de que todos los nuevos

valores se han escrito permanentemente en la base de datos real.1.6. Punto de confirmacin de una transacc in.

Una transaccin T llega a su punto de confirmacin cuando todas susoperaciones que tienen acceso a la base de datos se han ejecutado con xito y elefecto de todas estas operaciones se ha asentado en la bitcora [10 y 11]. Msall del punto de confirmacin, se dice que la transaccin est confirmada y sesupone que su efecto se asent permanentementeen la base de datos. En esemomento la transaccin escribe una entrada (commit,T) en la bitcora. Si ocurreun fallo del sistema, buscamos en la bitcora todas las transacciones Tque hanescrito una entrada (inicio_de_transaccin,T) en la bitcora pero no han escrito

todava su entrada (commit,T); es posible que durante el proceso de recuperacinestas transacciones tengan que revertirse para cancelar su efecto sobre la basede datos. Las transacciones que ya escribieron su entrada de confirmacin en labitcora tambin debern haber asentado en ella todas sus operacionesESCRIBIR, pues de lo contrario no estaran confirmadas; su efecto sobre la basede datos puede rehacerse a partir de las entradas de la bitcora.

Observe que el archivo de la bitcora debe mantenerse en disco. La actualizacinde un archivo en disco implica copiar el bloque apropiado del archivo del disco aun almacenamiento intermedio en la memoria principal, actualizar estealmacenamiento intermedio y copiarlo de la memoria principal al disco. Confrecuencia se mantiene un bloque del archivo de bitcora en memoria principalhasta que se llena de entradas y luego se escribe una sola vez en el disco, en vezde escribirlo cada vez que se aade una entrada. Esto ahorra el gasto extra deescribir varias veces en disco el mismo bloque de archivo. Cuando se cae elsistema, slo las entradas de bitcora que se han escrito en disco se consideraque estn en el proceso de recuperacin, porque puede haberse perdido elcontenido de la memoria principal. Por ello, antes de que una transaccin llegue asu punto de confirmacin, cualquier porcin de la bitcora que no se haya escrito Tambin se conoce como punto de sincronizacin, especialmente en productos comerciales.

7/13/2019 Tes 1232

15/82

15

en el disco todava se deber grabar. Este proceso se denomina forzar la escrituradel archivo de bitcora (tambin llamado Protocolo de bitcora de escrituraadelantada) antes de confirmar una transaccin.

1.7. Puntos de control en la bitcora del sistema.

Otro tipo de entradas en la bitcora es el llamado punto de control (punto derevisin). Un registro (punto_de_control) se escribe en la bitcora peridicamentecada vez que el sistema escribe en la base de datos en disco, el efecto de todaslas operaciones ESCRIBIR de las transacciones confirmadas [10 y 11]. As pues,todas las transacciones que tengan sus entradas (commit,T) en la bitcora antesde una entrada (punto_de_control) no necesitarn la repeticin de susoperaciones ESCRIBIR en caso de una cada del sistema.

El gestor de recuperacin de un DBMS debe decidir con qu intervalos asentar unpunto de control. El intervalo puede medirse en el tiempo, digamos, cada mminutos, o por el nmero tde transacciones confirmadas desde el ltimo punto de

control, donde los valores dem

o det son parmetros del sistema. Elasentamiento de un punto de control consiste en las siguientes acciones:

1. Suspender temporalmente la ejecucin de las transacciones.2. Forzar la escritura de todas las operaciones de actualizacin pertenecientes

a transacciones confirmadas del almacenamiento intermedio al disco.3. Escribir un registro (punto_de_control) en la bitcora y forzar la escritura de

la bitcora en el disco.4. Reanudar la ejecucin de transacciones.

Un registro de punto de control en la bitcora tambin puede incluir informacinadicional, como una lista de identificadores de las transacciones activas o las

ubicaciones (direcciones) del primer registro y del ms reciente (ltimo) en labitcora para cada transaccin activa. Esto puede facilitar la anulacin deoperaciones en caso de ser necesaria la reversin de una transaccin.

1.8. Propiedades deseables en las transacciones.

Las transacciones atmicas deben poseer varias propiedades [10 y 11]. Estas seconocen como ACID (Atomicity, Consistency, Isolation, Durability) y deben serimpuestas por lo mtodos de control de concurrencia y de recuperacin de losDBMS. Las propiedades ACID son:

1. Atomicidad: Una transaccin es una unidad atmica de procesamiento; o

bien se realiza por completo o no se realiza en absoluto.2. Conservacin de la consistencia: Una ejecucin correcta de latransaccin debe llevar a la base de datos de un estado consistente a otro.

3. Aislamiento: Una transaccin no debe dejar que otras transaccionespuedan ver sus actualizaciones antes de que sea confirmada; estapropiedad, cuando se hace cumplir estrictamente, resuelve el problema dela actualizacin temporal y hace innecesarias las reconversiones encascada de las transacciones.

7/13/2019 Tes 1232

16/82

16

4. Durabilidad o permanencia: Una vez que una transaccin ha modificadola base de datos y las modificaciones se han confirmado, stas nuncadeben perderse por un fallo subsecuente.

La propiedad de atomicidad requiere que ejecutemos una transaccin hastacompletarla. Es obligacin del mtodo de recuperacin garantizar la atomicidad. Sipor alguna razn una transaccin no puede completarse, como por una cada delsistema a la mitad de su ejecucin, el mtodo de recuperacin debe cancelartodos los efectos de la transaccin sobre la base de datos.

En general, se considera que la propiedad de conservacin de la consistencia esresponsabilidad de los programadores que escriben los programas de base dedatos o del mdulo del DBMS que impone las restricciones de integridad.Recuerde que un estado de la base de datos es una coleccin de todos loselementos de informacin (valores) almacenados en la base de datos en unmomento dado. Un estado consiente de la base de datos satisface lasrestricciones especificadas en el esquema, adems de cualesquier otras

restricciones que deban cumplirse en la base de datos. Los programas de base dedatos deben elaborarse a modo de garantizar que, si la base de datos est en unestado consistente antes de ejecutar la transaccin, estar en un estadoconsistente despus de la ejecucin completa de la transaccin, suponiendo queno hay interferencias con otras transacciones.

El aislamiento lo impone el mtodo de control de concurrencia. Se ha intentadodefinir el nivel o grado de aislamiento de una transaccin. Se dice que unatransaccin tiene aislamiento de grado 0 (cero) si no sobrescribe las lecturassucias de transacciones de nivel ms alto; una transaccin con nivel deaislamiento 1 (uno) no tiene actualizaciones perdidas y el aislamiento grado 2 notiene actualizaciones perdidas ni lecturas sucias. Por ltimo, el aislamiento grado 3(tambin llamado aislamiento verdadero) tiene, adems de las propiedades delgrado 2, lecturas repetibles. La propiedad de durabilidad es responsabilidad delmtodo de recuperacin.

1.9. Tipos de Transacciones.

1.9.1. Transacciones de larga duracin.

El concepto de transaccin, segn Date [7], fue desarrollado inicialmente en elcontexto de aplicaciones de procesamiento de datos en el que la mayor parte delas transacciones no son interactivas y son de corta duracin. Cuando esteconcepto es aplicado a sistemas de bases de datos que implican interaccinhumana, surgen serios problemas. Estas interacciones tienen las siguientespropiedades clave:

Larga duracin.Cuando hay una interaccin humana con una transaccinactiva, esa transaccin llega a ser de larga duracin desde la perspectivadel computador, puesto que el tiempo de respuesta humana es lentocomparado con la velocidad del computador. Adems, en aplicaciones dediseo, la actividad humana que se est modelando puede implicar horas,

7/13/2019 Tes 1232

17/82

17

das o incluso un largo periodo. As pues, las transacciones pueden ser delarga duracin en trminos humanos y tambin en trminos de la mquina.

Exposicin de datos no ejecutados . Los datos que una transaccin delarga duracin genera y presenta al usuario no estn ejecutados, puestoque la transaccin puede abortar. As, los usuarios, y como resultado otras

transacciones, pueden ser forzados a leer datos no ejecutados. Si variosusuarios cooperan en un diseo, puede que las transacciones de usuariosnecesiten intercambiar datos antes de que la transaccin se ejecute.

Subtareas. Una transaccin interactiva puede constar de un conjunto desubtareas iniciadas por el usuario. El usuario puede que desee abortar unasubtarea sin causar necesariamente que aborte toda la transaccin.

Recuperabilidad. No es aceptable abortar una transaccin interactiva delarga duracin por una cada del sistema. La transaccin activa deberecuperarse a un estado que exista poco antes de la cada de forma que sepierda relativamente poco trabajo humano.

Rendimiento. El buen rendimiento en un sistema de transaccionesinteractivas se define como tiempo de respuesta rpido; a diferencia de lossistemas no interactivos, en los que el objetivo es el rendimiento alto(nmero de transacciones por segundo). Los sistemas de alto rendimientohacen que el uso de los recursos del sistema sea eficiente. Sin embargo, enel caso de transacciones interactivas, el ms costoso es elusuario. Para optimizar la eficiencia y satisfaccin del usuario, el tiempo derespuesta debe ser rpido (desde una perspectiva humana). En los casosen los que una tarea tarde mucho tiempo, el tiempo de respuesta debe serprevisible (es decir, la variacin en los tiempos de respuesta debe ser baja),de forma que los usuarios puedan manejar bien su tiempo.

Efectos adversos en t ransacciones de larga duracin.

Cada uno de los protocolos convencionales de control de concurrencia, tieneefectos adversos en las transacciones de larga duracin:

Bloqueo de dos fases. Cuando un bloqueo no puede garantizarse, sefuerza a la transaccin que solicita el bloqueo a que espere que sedesbloquee el dato en cuestin. La duracin de esta espera es proporcionala la duracin de la transaccin que tiene el bloqueo. Si el dato estbloqueado por una transaccin de corta duracin, esperamos que el tiempode espera sea corta (excepto en el caso de bloqueo total o de sobrecargodel sistema). Sin embargo, si el dato esta bloqueado por una transaccin delarga duracin, la espera ser de larga duracin. Los tiempos de esperalargos conllevan un tiempo de espera ms largo y un aumento de laprobabilidad de bloqueo total.

Protocolos basados en grafos. Los protocolos basados en grafospermiten que los bloqueos se liberen antes que bajo los protocolos debloqueo de dos fases, y previene el bloqueo total. Sin embargo, imponenuna ordenacin en los datos. Las transacciones deben bloquear los datosde una manera consistente con esa ordenacin. Como resultado, unatransaccin puede que tenga que bloquear ms datos de los que necesite.

7/13/2019 Tes 1232

18/82

18

Adems, una transaccin debe tener un bloqueo hasta que no hayaninguna probabilidad de que este se vuelva a necesitar. As es probableque el bloqueo de larga duracin espera.

Protocolos basados en hora de entrada. Los protocolos basados enhorade entrada nunca requieren que espere una transaccin. Sin embargo,

requieren que las transacciones aborten bajo determinadas circunstancias.Si se aborta una transaccin de larga duracin, se pierde una cantidadimportante de trabajo. Para transacciones no interactivas, este trabajoperdido repercute en el rendimiento. Para transacciones interactivas,repercute tambin en la satisfaccin del usuario. No es deseable enabsoluto que un usuario se de cuenta de que se han perdido varias horasde trabajo.

Validacin. Al igual que los protocolos basados en hora de entrada, losprotocolos de validacin hacen que se cumpla la serializabilidad abortandolas transacciones.

As, parece que el hacer que se cumpla la serializabilidad resulta en esperas de

larga duracin, aborto de transacciones de larga duracin o ambos. Al hacer quese cumpla la serializabilidad surgen problemas adicionales cuando consideramosla recuperacin. Anteriormente tratamos el problema del retroceso en cascada, enel que el aborto de una transaccin puede conducir al aborto de otrastransacciones. Este fenmeno es indeseable, particularmente para lastransacciones de larga duracin. Si se utiliza bloqueo, los bloqueos exclusivosdeben mantenerse hasta el final de la transaccin si se va a evitar el retroceso encascada. Sin embargo, esto aumenta la duracin del tiempo de espera .

1.9.2. Transacciones anidadas.

Una transaccin de larga duracin, segn Date [7], puede ser vista como unacoleccin de subtareas o subtransacciones relacionadas. Estructurando unatransaccin como un conjunto de subtransacciones, podemos aumentar elparalelismo, puesto que puede ser posible ejecutar varias subtransacciones enparalelo. Adems, es posible tratar los fallos de una subtransaccin (debidos aabortos, cada del sistema, etc.), sin tener que retroceder la transaccin de largaduracin entera.

Una transaccin anidada Tse representa mediante un conjunto T={t1, t2,, tn}desubtransacciones y un orden parcial de Pen T. Una subtransaccin t, de Tpuedeabortar sin obligar a T a que aborte. En lugar de ello, T puede reiniciar a ti o

simplemente decidir que ti no se ejecute. Si ti se ejecuta, esto no hace a tipermanente. En cambio, tiejecuta a T y todava puede abortar si Taborta. Unaejecucin de T no debe violar el orden parcial P, es decir, si en el grafo deprecedencia aparece una arista ti tjentoncestj tino debe estar en el cierretransitivo deP.

As, parece que el cumplimiento de la atomicidad de la transaccin debe conducir a un aumento de la probabilidad deesperas de larga duracin o a crear una posibilidad de retroceso en cascada.

7/13/2019 Tes 1232

19/82

19

La anidacin puede tener varios niveles de profundidad, representando unasubdivisin de una transaccin en subtareas, subsubtareas y as sucesivamente.En el nivel ms bajo de la anidacin tenemos las operaciones estndar de la basede datos ready writeque hemos utilizado anteriormente.

Aunque el principal valor prctico de las transacciones anidadas surge en lastransacciones de larga duracin complejas, usaremos el ejemplo sencillo de lafigura para mostrar como la anidacin puede crear operaciones de ms alto nivelque aumentan la concurrencia. Volvemos a escribir la transaccin T15usando lassubtransaccionestuytbque realizan operaciones de incremento o decremento.

T15 consta de:o taresta 50 de A.o tbsuma 50 a B.

De manera similar, volvemos a escribir la transaccin T16 usando lassubtransacciones tc y td que realizan operaciones de incremento o

decremento: T16consta de:

o tcresta 10 de B.o tdsuma 10 a A.

No se especifica ningn orden en ta, tb, tc y td. Cualquier ejecucin de estassubtransacciones generar un resultado correcto. La planificacin de la figura 1.9corresponde a la planificacin .

T15 T16read(A)A:=A-50write(A)

read(B)B:=B-10write(B)

read(B)B:=B+50write(B)

read(A)A:=A+10write(A)

Figura 1.9 Una Planificacin no serializable en conflictos.

1.9.3. Transacciones de compensacin.

Anteriormente utilizamos la operacin undopara eliminar los cambios en la basede datos que realiz una transaccin abortada. Ello garantiza la atomicidad de lastransacciones [7].

El acercamiento a este enfoque tiene efectos adversos en las transacciones delarga duracin. Para reducir la frecuencia de espera de larga duracin, es

7/13/2019 Tes 1232

20/82

20

necesario que las transacciones que no han terminado se expongan a otrastransacciones que se ejecutan de manera concurrente. Sin embargo, la exposicinde los datos no ejecutados puede crear retrocesos en cascada.

El concepto de transacciones de compensacin trata de este problemaproporcionando una alternativa a la operacin undopara recuperacin en fallos de

transacciones. En vez de deshacer estrictamente todos los cambios que produjo latransaccin que ha fallado, se presenta especial atencin a la compensacin delfallo.

1.9.4. Implementacin.

Los conceptos de transaccin tratados en esta seccin, crean serias dificultadesde implementacin. Aqu presentamos algunos de estos problemas y tratamoscomo se pueden resolver [7].

Las transacciones de larga duracin deben sobrevivir a las cadas del sistema.Esto puede lograrse realizando un redo en las subtransacciones terminadas y

realizando un undoo una compensacin para todas las subtransacciones de cortaduracin que estuvieran activas en el momento de la cada. Sin embrago, estoslo es parte del problema. En los sistemas de base de datos tpicos, estos datosinternos del sistema como tablas de bloqueo y horas de entrada de transaccionesse guardan en almacenamiento estable. Para que una transaccin de largaduracin se reanude despus de una cada, estos datos se deben restaurar. Portanto, no slo es necesario registrar los cambios en la base de datos, sino tambinlos cambios en los datos internos del sistema pertenecientes a las transaccionesde larga duracin.

El registro de actualizaciones se hace ms complejo segn los tipos de datos quepueda haber en la base de datos. Un dato puede estar en un diseo CAD, en el

texto de un documento o en otra forma de diseo compuesto. Estos datos songrandes fsicamente. Por tanto, no es deseable que se almacenen en un registrode bitcora ambos valores del dato: el antiguo y el nuevo.

Existen dos enfoques para reducir el gasto extra de garantizar la recuperacin delos datos grandes:

Registro de operacin. Slo se almacenan en el registro la operacinrealizada en el dato y el nombre del dato. Para cada operacin, debe existiruna operacin inversa. Undo se realiza utilizando la operacin inversa yredo se utiliza usando la propia operacin. La recuperacin mediante laoperacin de registro es ms difcil, ya que redo y undo no son

idempotentes. Registro y doble paginacin.El registro se utiliza para modificaciones en

datos pequeos, mientras que los datos grandes se recuperan utilizandouna tcnica de doble paginacin. Usando la doble paginacin, solo senecesita almacenar en duplicado las pginas que realmente se modifiquen.

Nota:Sea cual sea la tcnica utilizada, las complejidades que introducen las transacciones de larga duracin y los datoscomplican el proceso de recuperacin. Por tanto, es deseable permitir que ciertos datos que no sean crticos, estnexentos de registro y confiar en las copias de seguridad fuera de lnea y en la intervencin humana.

7/13/2019 Tes 1232

21/82

21

1.9.5. Restr icc iones temporales.

Las transacciones que hemos considerado hasta ahora pertenecen a los valoresalmacenados en la base de datos. En determinadas aplicaciones, las restriccionesincluyen una fecha/hora tope en la que una tarea debe terminarse. Ejemplos deestas aplicaciones incluyen gestin de planta, control de trfico y planificacin.Cuando se incluyen las fechas/horas tope, el que una ejecucin sea correcta ya noes nicamente un favor de consistencia de la base de datos. Ms bien nosinteresa cuantas fecha/horas tope faltan y por cuanto tiempo faltan [7]. Lasfechas/horas tope se caracterizan como:

Fijas (Hard). La tarea tiene valor cero si termina antes de la fecha/horatope.

Temporales (Soft). La tarea ha disminuido el valor si termina despus dela fecha/hora tope, con el valor prximo a cero segn aumenta el grado delatencia. Los sistemas con fechas/horas tope se denominan sistemas entiempo real.

La gestin de transacciones en sistemas en tiempo real debe tener en cuentafechas/horas tope. Si el protocolo de concurrencia determina que una transaccinT debe esperar, puede causar que Tpierda su fecha/hora tope. En tales casos,puede ser preferible evitar que se ejecute la transaccin que tiene el bloqueo ypermitir que Tcontine. Sin embargo, la prevencin (el evitar la ejecucin) debeutilizarse con cuidado, porque el tiempo que ha perdido la transaccin de la que sepreviene (debido al retroceso y al reinicio) puede causar que pierda su fecha/horatope.

Desafortunadamente, es difcil determinar si es preferible el retroceso o la esperaen una situacin dada. El problema surge de la variacin en el tiempo de ejecucin

de las transacciones. En el mejor de los casos, todos los accesos a datos serefieren a datos del buffer de la base de datos. En el peor de los casos, cadaacceso hace que se escriba una pgina del buffer en el disco (precedido de losregistros de bitcora necesarios) seguido de la lectura del disco de la pgina quecontienen los datos que va a ser accedidos. Debido a que los dos o ms accesosa disco que se necesitan, en el peor de los casos, tardan varios rdenes demagnitud ms de tiempo que el que requiere las referencias a memoria principalen el mejor caso, el tiempo de ejecucin de transaccin puede estimarse muyvagamente.

Los problemas de las bases de datos en tiempo real se encuentran en proceso

investigacin. Las notas bibliogrficas hacen referencia a algunas investigacionesiniciales en este campo.

7/13/2019 Tes 1232

22/82

22

Capitulo 2. RECUPERACIN DE TRANSACCIONESEN BASES DE DATOS.

En este captulo, se define la necesidad por la cual la recuperacin detransacciones es indispensable, detallando algunos conceptos, los cuales son desuma importancia para el xito de una transaccin.

7/13/2019 Tes 1232

23/82

23

2. RECUPERACIN DE TRANSACCIONES EN BASES DE DATOS.

2.1. Por qu es necesaria la recuperacin?

Una transaccin comienza con la ejecucin satisfactoria de una instruccin BEGIN

TRANSACTION y termina con la ejecucin satisfactoria de una instruccinCOMMIT o ROLLBACK. COMMIT establece lo que es conocido, entre muchasotras acepciones, como punto de confirmacin (tambin se conoce comopunto de sincronizacin, especialmente en productos comerciales) [7]. Unpunto de confirmacin corresponde entonces al final de una unidad de trabajolgica y por lo tanto, a un punto en el cual la base de datos est o debera estar enun estado consistente. Por el contrario, ROLLBACK regresa la base de datos alestado en que estaba antes de BEGIN TRANSACTION, lo que en efecto significaregresar al punto de confirmacin anterior. (La frase "punto de confirmacinanterior" sigue siendo adecuada, aun en el caso de que sea la primera transaccinen el programa; si coincidimos en que la primera BEGIN TRANSACTION delprograma est estableciendo tcitamente un "punto de confirmacin" inicial.)

Nota: A lo largo de este captulo, el trmino "base de datos" significa enrealidad slo aquella parte de la base de datos a la que la transaccin enconsideracin est teniendo acceso. Es posible que otras transacciones estn enejecucin paralela y hagan cambios a sus propias partes, por lo que tambin esposible que la "base de datos total" no est en un estado completamenteconsistente en un punto de confirmacin.

Al establecer un punto de confirmacin:

1. Todas las actualizaciones hechas por el programa en ejecucin desde el puntode confirmacin anterior, son confirmadas; es decir, se vuelven permanentes.Antes del punto de confirmacin, todas estas actualizaciones deben ser vistascomo meramente tentativas, en el sentido de que pueden ser deshechasposteriormente. Es un hecho que una vez que una transaccin ha sidoconfirmada nunca podr ser deshecha (sta es la definicin de "confirmada").

2. Todo el posicionamiento de la base de datos se pierde y todos los bloqueos detupias son liberados. El "posicionamiento de la base de datos" se refiere en estecaso a la idea de que en cualquier momento, un programa en ejecucin tendruna direccionabilidad hacia ciertas tupias (por ejemplo, mediante determinadoscursoresen el caso de SQL); esta direccionabilidad se pierde en un punto deconfirmacin .

El prrafo 2 anterior, salvo el comentario acerca de la posible retencin de algunadireccionabilidad, y por tanto, la posible conservacin de determinados bloqueosde tuplas, tambin se aplica cuando la transaccin termina con ROLLBACK en vezde COMMIT. El prrafo 1, por supuesto, no presenta el mismo caso.

Nota:Algunos sistemas proporcionan una opcin por la cual el programa puede conservar la direccionabilidad haciadeterminadas tupias (y por lo tanto, conservar determinados bloqueos de tupias) entre una transaccin y la siguiente.

7/13/2019 Tes 1232

24/82

24

Observe cuidadosamente que COMMIT y ROLLBACK terminan la transaccin yno el programa. Por lo general, una sola ejecucin del programa consta de unasecuencia de varias transacciones ejecutndose una tras otra, como ilustra lafigura 2.1.

pr i mera t r ansacci n

i ni ci o BEGI N COMMI Tdel pr ogr ama TRANSACTI ON

segunda t r ansacci n ( cancel ada)

1 1ROLLBACK

TRANSACTI ON

- - - - - - - tercera t ransacci n - - - -

_|------------------------------------------------------|

TRANSACTI ON del programa

Figura 2.1 La ejecucin del programa es una secuencia de transacciones.

En ese ejemplo incluimos pruebas explcitas para errores y emitimos unainstruccin ROLLBACK explcita cuando fue detectado algn error. Pero el sistemapor supuesto no puede dar por hecho que los programas de aplicacin siempreincluirn pruebas explcitas para todos los errores posibles. Por lo tanto, el sistemaemitir una instruccin ROLLBACK implcita para cualquier transaccin que fallepor cualquier razn, para llegar a su terminacin planeada (donde "terminacinplaneada" significa una instruccin COMMIT o ROLLBACK explcitas).

Ahora podemos ver que las transacciones no slo representan la unidad detrabajo sino tambin la unidad de recuperacin. Si una transaccin es confirmadasatisfactoriamente, el sistema garantizar que sus actualizaciones quedengrabadas permanentemente en la base de datos, aunque el sistema llegue a fallaren el siguiente momento. Por ejemplo, es probable que el sistema falle despusde haber recibido a COMMIT, pero antes de escribir fsicamente lasactualizaciones en la base de datos; stas podran seguir esperando en un bfer

de memoria principal y por lo tanto, estar perdidas en el momento de la falla.Aunque esto suceda, el procedimiento de reinicio del sistema grabar esasactualizaciones en la base de datos. ste es capaz de descubrir los valores quehay que escribir, examinando las entradas relevantes de la bitcora.

(De aqu se deduce que la bitcora debe ser escrita fsicamente antes de quetermine el procesamiento de COMMIT; lo que se conoce como regla de escrituraanticipada de la bitcora). El procedimiento de reinicio recuperar cualquiertransaccin que haya terminado satisfactoriamente pero que no haya podido lograr

7/13/2019 Tes 1232

25/82

25

que sus actualizaciones fueran escritas fsicamente antes de la cada. Por lo tanto,como dije anteriormente, las transacciones son la unidad de recuperacin. Nota:En el siguiente captulo veremos que tambin son la unidad de concurrencia.Adems, puesto que supuestamente transforman un estado consistente hacia otroestado consistente de la base de datos, tambin pueden ser vistas como una

unidad de integridad.2.2. Tipos de fallos.

Hay varias razones por las que una transaccin puede fallar mientras se estejecutando [10 y 11]:

1. Un fallo del computador (cada): Un error de hardware o software ocurre enel sistema de cmputo durante la ejecucin de una transaccin. Si el equipofalla, es posible que se pierda el contenido de la memoria interna delcomputador.

2. Un error de la transaccin o del sistema: Alguna operacin de unatransaccin puede hacer que sta falle, por ejemplo, un desbordamiento deenteros o una divisin entre ceros. Tambin puede haber un fallo detransaccin debido a valores errneos de los parmetros o a un error lgicode programacin. Por aadidura, puede suceder que el usuario interrumpaa propsito la transaccin durante su ejecucin; por ejemplo, al emitircontrol-C en un entorno VAX/VMS o UNIX.

3. Errores locales o condiciones de excepcin detectadas por la transaccin:Durante la ejecucin de transacciones pueden presentarse ciertascondiciones que requieran la cancelacin de la transaccin. Por ejemplo, esposible que no se encuentren los datos para la transaccin. Una condicin,como un saldo insuficiente en una cuenta de una base de datos bancaria,puede hacer que se cancele una transaccin, como un retiro de fondos deesa cuenta. Esto puede hacerse por una instruccin ABORTARprogramada en la transaccin misma.

4. Imposicin del control de concurrencia: El mtodo de control deconcurrencia puede decidir que se aborte la transaccin para reiniciarladespus, porque viola la serializabilidad o porque varias transacciones seencuentran en un estado de bloqueo mortal.

5. Fallos del disco: Algunos bloques de disco pueden perder sus datos por unmal funcionamiento de lectura o de escritura o por un aterrizaje de unacabeza de lectura/escritura. Esto puede suceder durante una operacin delectura o de escritura de la transaccin.

6. Problemas y catstrofes fsicos: Esto se refiere a una interminable lista deproblemas que incluyen interrupcin del suministro de energa, fallo delacondicionamiento de aire, incendio, robo, sabotaje, sobre escritura endiscos o cintas por error, y que el operador haya montado la cintaequivocada.

Los fallos 1, 2, 3, y 4 son ms comunes que los fallos 5 y 6. Siempre que ocurreun fallo tipo del 1 al 4, el sistema debe mantener suficiente informacin para

7/13/2019 Tes 1232

26/82

26

recuperarse del fallo. Los fallos de disco o los catastrficos (tipos 5 6) no ocurrencon tanta frecuencia; si se dan, la recuperacin es una tarea bastante complicada.El concepto de transaccin atmica es fundamental para muchas tcnicas decontrol de concurrencia y de recuperacin de fallos.

Consideremos el siguiente ejemplo [7]. Para efectos de la ilustracin, tenemos tres

tablas: la tabla S, que representa a los proveedores; la tabla P, que representa alas partes y la tabla SP, que representa los envos de partes hechos por losproveedores (figura 2.2)

Figura 2.2 La base de datos de proveedores y partes.

La tablaP, la de partes contiene un campo adicional CANTTOTAL que representala cantidad total enviada de la parte en cuestin; en otras palabras, el valorCANTTOTAL para una parte dada es igual a la suma de todos los valoresSP.CANT de todos los registros SPcorrespondientes a esa parte. Consideremosahora la siguiente secuencia de operaciones, cuya intencin es aadir un nuevoenvo (S5,P1,1000) a la base de datos:

S S#CANT

SNOMBRE SI TUACI N CI UDAD SP S# P#

S1S2S3S4S5

Sal azarJ ai mesBer nalCor onaAl dana

2010302030

LondresPar i sPar i sLondresAt enas

S1S1S1S1

S1S1S2S2S3S4S4S4

P1P2P3P4

P5P6P1P2P3P2P4P5

300200400200

100100300400200200300400

P P# PNOMBRE COLOR CI UDAD

P1P2P3P4P5P6

TuercaPer noBi r l oBi r l oLevaEngrane

Roj oVer deAzulRoj oAzulRoj o

LondresPar i sRomaLondresPar i sLondres

PESO

121717141219

CANTTOTAL

CAMPO ADICIONAL

S S#CANT

SNOMBRE SI TUACI N CI UDAD SP S# P#

S1S2S3S4S5

Sal azarJ ai mesBer nalCor onaAl dana

2010302030

LondresPar i sPar i sLondresAt enas

S1S1S1S1

S1S1S2S2S3S4S4S4

P1P2P3P4

P5P6P1P2P3P2P4P5

300200400200

100100300400200200300400

P P# PNOMBRE COLOR CI UDAD

P1P2P3P4P5P6

TuercaPer noBi r l oBi r l oLevaEngrane

Roj oVer deAzulRoj oAzulRoj o

LondresPar i sRomaLondresPar i sLondres

PESO

121717141219

CANTTOTAL

CAMPO ADICIONAL

EXEC SQL WHENEVER SQLERROR GO TO ANULAR ;EXEC SQL I NSERT

I NTO SP ( S#, P#, CANT )VALUES ( S5 , P1 , 1000) ;

EXEC SQL UPDATE PSET CANTTOTAL = CANTTOTAL + 1000WHERE P# = P1 ;

EXEC SQL COMMI T ;GO TO TERMI NAR;

ANULAR:

EXEC SQL ROLLBACK ;

TERMI NAR: RETURN ;

7/13/2019 Tes 1232

27/82

27

La proposicin INSERT (insertar) agrega el nuevo envo a la tabla SP, laproposicin UPDATE (actualizar) pone al da en forma apropiada el campoCANTTOTAL de la parteP1.

El objetivo de este ejemplo es mostrar que una operacin supuestamenteindividual y atmica, aadir un nuevo envo, implica en realidad dos

modificaciones de la base de datos. Por aadidura, la base de datos ni siquiera esconsistente entre esa dos modificaciones; viola en forma temporal el requerimientosegn el cual el valor de CANTTOTAL para la parte P1debe ser igual a la sumade todos los valores SP.CANT correspondiente a esa parte. As pues, una unidadlgica de trabajo (o sea, una transaccin) no es por fuerza una sola operacin enla base de datos; ms bien, es en general una secuencia de varias de esasoperaciones mediante la cual un estado consistente de la base de datos setransforma en otro estado consistente, sin conservar por fuerza la consistencia entodos los puntos intermedios.

Ahora bien, es evidente que lo que no puede permitirse en el ejemplo es la

ejecucin de una de las dos modificaciones y no de la otra (porque en ese caso labase de datos quedara en un estado inconsciente). En una situacin ideal, desdeluego, nos gustara tener una garanta absoluta de que se realizaran las dosmodificaciones. Por desgracia, es imposible ofrecer tal garanta; siempre existe laposibilidad de una falla y, adems de una falla en el peor momento posible. Porejemplo, el sistema podra caerse justo despus de la primera modificacin, opodra haber un desborde aritmtico en la segunda, etctera. Pero el sistemamaneja el procesamiento de transacciones, podr ofrecer lo ms cercano a esagaranta. En trminos especficos, garantizar que si la transaccin ejecutaalgunas modificaciones y despus se presenta una falla (por cualquier razn)antes de que llegue el trmino normal de la transaccin, se anularn esasmodificaciones. As, o bien la transaccin se lleva a cabo en su totalidad (es decir,se hace como si jams se hubiera ejecutado). De esta manera, puede lograrseque una secuencia de operaciones, la cual en esencia no es atmica, aparenteserlo desde un punto de vista externo.

El componente del sistema encargado de lograr esta atomicidad (o apariencia deatomicidad) se conoce como manejador de transacciones, y las operacionesCOMMIT (comprometer) y ROLLBACK (retroceder) son la clave de sufuncionamiento:

La operacin COMMIT seala el trmino exitoso de la transaccin: le dice almanejador de transacciones que se ha finalizado con xito una unidadlgica de trabajo, que la base de datos est (o debera estar) de nuevo enun estado consiente, y que se puede comprometer, o hacer permanentes,todas las modificaciones efectuadas por esa unidad de trabajo.

La operacin ROLLBACK, en cambio, seala el trmino no exitoso de latransaccin: dice al manejador de transacciones que algo sali mal, que labase de datos podra estar en un estado inconsistente, y que todas lasmodificaciones efectuadas hasta el momento por la unidad lgica de trabajodeben retroceder o anularse.

7/13/2019 Tes 1232

28/82

28

En el ejemplo, entonces emitiremos un COMMIT si realizamos con xito las dosmodificaciones, con lo cual se comprometeran las alteraciones en la base dedatos y se volvern permanentes. En cambio, si algo sale mal, o sea, si cualquierade las dos proposiciones de modificacin produce la condicin SQLERROR,emitiremos un ROLLBACK, a fin de anular todas las modificaciones efectuadas

hasta ese momento.Nota 1: Hemos mostrado de manera explcita las operaciones COMMIT yROLLBACK, para efectos del ejemplo. Sin embargo, en el caso especfico del DB2emitir automticamente una instruccin COMMIT cuando termine en formanormal cualquier programa, y emitir tambin automticamente una instruccinROLLBACK cuando cualquier programa no termine en forma normal (sea cual seala razn; en particular, si un programa termina de manera anormal debido a unafalla del sistema, emitir un ROLLBACK por su cuenta cuando se reinicie elsistema). Por ejemplo, por tanto, podramos haber omitido la instruccin COMMITexplcita, pero no la instruccin ROLLBACK explcita.

Nota 2: Un programa de explicacin real no slo deber modificar la base de datos(o intentar modificarla) sino adems enviar algn tipo de mensaje de vuelta alusuario final indicando lo sucedido. En el ejemplo, podramos enviar el mensajeEnvo agregado si se llega a la instruccin COMMIT, o el mensaje Error: no seagreg el envo en caso contrario. El manejo de mensajes, a su vez, tieneimplicaciones adicionales en cuanto a la recuperacin.

En este punto, probablemente se pregunte cmo es posible anular unamodificacin. La respuesta es que el sistema mantiene una bitcora o diario encinta o (ms comnmente) en disco, en los cuales se registran los detalles detodas las operaciones de actualizacin, en particular, los valores inicial y final delobjeto modificado. Por tanto, si resulta necesario anular alguna modificacin

especfica, el sistema puede utilizar la entrada correspondiente de la bitcora pararestaurar el valor original del objeto modificado.

Un punto adicional: en un sistema relacional, desde luego, las proposiciones demanipulacin de datos se encuentran en el nivel de conjuntos y por lo regulartrabajan con varios registros a la vez. Qu sucedera si hay alguna falla durantela ejecucin de una proposicin de stas? Por ejemplo, es posible que unaactualizacin (UPDATE) de mltiples registros ponga al da varios de sus registrosobjetivos y despus falle antes de poner al da el resto? La respuesta, al menos enDB2, es que no es posible; las proposiciones individuales de SQL deben ser porfuerza atmicas en lo concerniente a su efecto sobre la base de datos. Si se llegaa presentar un error durante la ejecucin de estas proposiciones, la base de datosno sufrir alteracin alguna.

2.3. Recuperacin del sis tema y los medios de almacenamiento.

El sistema debe estar preparado para recuperarse no slo de fallas puramentelocales, como la aparicin de una condicin de desborde dentro de una solatransaccin, sino tambin de fallas globales como podra ser una interrupcin delsuministro elctrico en la UCP [7]. Una falla, por definicin, afecta slo latransaccin en la cual se present esa falla. Una falla global, en cambio, afecta a

7/13/2019 Tes 1232

29/82

29

varias y con mucha probabilidad a la totalidad, de las transacciones que seestaban efectuando en el momento de la falla, por lo cual tendr implicacionespara todo el sistema.

Tales fallas se dividen en dos categoras amplias:

Fallas del sistema (por ejemplo, interrupcin del suministro deelectricidad), las cuales afectan a todas las transacciones que se estnrealizando pero no daan fsicamente a la base de datos. Las fallas delsistema se conocen tambin como cadas suaves.

Fallas de los medios de almacenamiento(por ejemplo, un aterrizaje decabezas en el disco), las cuales si causan daos a la base de datos, o auna porcin de ella, y afectan al menos a las transacciones que estnutilizando esa porcin. Las fallas de los medios de almacenamiento sedenominan a veces cadas duras.

2.4. Falla del s istema.

El punto crtico en lo tocante a una falla del sistema es que se pierde el contenidode la memoria principal, en particular, se pierden las reas de almacenamientotemporal (buffers) de datos [7]. Por tanto, ya no se conocer el estado preciso dela transaccin que se estuviera realizando en el momento de la falla; esatransaccin jams se podr completar con xito, por lo cual ser preciso anularla(retroceder) cuando se reinicie el sistema. Por aadidura, podra ser necesario enel momento de reiniciar volver a realizar ciertas transacciones cuya ejecucin sitermin con xito antes de la cada pero cuyas modificaciones no lograron sertransferidas de los buffers de la base de datos a la base de datos fsica.

Surge la pregunta Cmo sabe el sistema en el momento de reiniciar cuales

transacciones debe anular y cuales debe realizar otra vez? La respuesta es lasiguiente. Cada cierto intervalo previamente establecido, por lo regular cuando seha grabado un nmero especificado de entradas en la bitcora, el sistemaestablece un punto de revisin de manera automtica. El establecimiento de unpunto de revisin implica: a) grabar fsicamente el contenido de los buffers dedatos en la base de datos fsica y b)grabar fsicamente un registro de punto derevisinespecial en la bitcora fsica. El registro de punto de revisin incluye unalista de todas las transacciones que se estaban realizando en el momento deestablecerse el punto de revisin. Para comprender la forma como se utiliza estainformacin, examnese la figura 2.3, la cual deber leerse de la siguiente manera:

Se present una falla de sistema en el momentotf. El punto de verificacin ms reciente antes detfse tom en el momentotv. Las transacciones del tipo T1se completaron antes del tiempotv. Las transacciones del tipo T2 se iniciaron antes del tiempo tv y se

completaron despus del tiempotvy antes del tiempotf. Las transacciones del tipo T3tambin se iniciaron antes del tiempo tvpero

no se completaron antes del tiempotf. Las transacciones del tipo T4 se iniciaron despus del tiempo tv y

terminaron (satisfactoriamente) antes del tiempotf.

7/13/2019 Tes 1232

30/82

30

Por ltimo, las transacciones del tipo T5 tambin se iniciaron despus deltiempotvpero no se completaron antes del tiempo tf.

Deber ser evidente que al reiniciarse el sistema debern anularse lastransacciones de los tipos T3y T5y debern realizarse de nuevo las transaccionesde los tipos T2 y T4. Advirtase, empero, que las transacciones del tipo T1 noentran en absoluto en el proceso de reinicio, porque sus modificaciones segrabaron fsicamente en la base de datos en el momento tv como parte delproceso de punto de revisin. Por tanto, en el momento del reinicio el sistemaefecta el siguiente procedimiento a fin de identificar las transacciones de los tiposT2-T5:

1. Comenzar con dos listas de transacciones, la lista ANULAR y la listaREPETIR. Igualar la lista ANULAR a la lista de todas las transaccionesincluidas en el registro de punto de revisin. Dejar vaca la lista REPETIR.

2. Examinar la bitcora hacia delante a partir del registro de punto de revisin.3. Si se encuentra una entrada de bitcora de iniciar transaccin para la

transaccin T, aadir Ta la lista ANULAR.

Figura 2.3. Cinco categoras de transacciones.

4. Si se encuentra una entrada de bitcora de comprometer para latransaccin T, pasar esa transaccin de la lista ANULAR a la listaREPETIR.

5. Cuando se llegue al final de la bitcora, las listas ANULAR y REPETIRidentificarn, respectivamente, las transacciones de los tipos T3 y T5 y delos tipos T2y T4.

T

r

a

n

s

a

cc

i

o

n

e

s

Tiempotv tf

Punto de verificacin

(tiempo tv)

Falla del sistema

(tiempo tf)

T1

T2

T3

T4

T5

T

r

a

n

s

a

cc

i

o

n

e

s

Tiempotv tf

Punto de verificacin

(tiempo tv)

Falla del sistema

(tiempo tf)

T1

T2

T3

T4

T5

7/13/2019 Tes 1232

31/82

31

Enseguida el sistema revisar la bitcora hacia atrs, anulando todas lastransacciones de la lista ANULAR. A continuacin la revisar otra vez haciadelante, realizando de nuevo todas las transacciones en la lista REPETIR. Porltimo, una vez terminada toda esta actividad de recuperacin (y slo entonces), elsistema estar listo para aceptar trabajos nuevos .

2.5. Falla de los medios de almacenamiento.

Una falla de los medios de almacenamiento es un percance (como por ejemplo unaterrizaje de las cabezas del disco o una falla del controlador del disco) en el cualse destruye fsicamente alguna porcin de la base de datos [7]. La recuperacinde una falla semejante implica en esencia cargar de nuevo (o restaurar) la base dedatos a partir de una copia de respaldo (o vaciado) y utilizar despus la bitcoratanto la porcin activa como la de archivo, en general para realizar de nuevo todaslas transacciones terminadas desde que se hizo esa copia de respaldo. No haynecesidad de anular las transacciones inconclusas en el momento de la falla,porque por definicin todas las modificaciones de esas transacciones ya se

anularon (destruyeron) de todas maneras.La necesidad de poder realizar una recuperacin de medios de almacenamientoimplica la necesidad de una utilera de vaciado/restauracin (o dedescarga/recarga). La porcin de vaciado de una utilera como sta sirve paracrear copias de respaldo de la base de datos cuando sea necesario. (Estas copiaspueden guardarse en cinta u otro medio de almacenamiento de archivo; no esnecesario mantenerlas en medios de acceso directo). La parte de restauracin dela utilera servir entonces para recrear la base de datos despus de una falla delos medios de almacenamiento a partir de una copia de respaldo especificada.

2.6. Confirmacin de dos fases.

En esta seccin analizaremos de manera breve una derivacin muy importante delconcepto bsico de compromiso/retroceso, llamada compromiso en dos fases [7].El compromiso en dos fases es importante cuando una transaccin dada puedeinteractuar con varios administradores de recursos independientes, cada uno delos cuales administra su propio conjunto de recursos recuperables. Por ejemplo,consideremos una transaccin que pone al da tanto la base de datos IMS comouna base de datos DB2, si la transaccin se completa con xito, todas susmodificaciones se debern anular (dicho de otro modo, no deber ser posible quese comprometan las modificaciones en IMS y se anulen las modificaciones enDB2, o viceversa, pues en ese caso la transaccin ya no sera atmica).

En consecuencia, no tendr sentido que la transaccin emita, digamos, una

instruccin COMMIT a IMS y una instruccin ROLLBACK a DB2; y an cuandoemitiera la misma instruccin a los dos, existira la posibilidad de una cada delsistema entre las dos, con resultados lamentables. As pues, en vez de ello, latransaccin emite una sola instruccin COMMIT (o ROLLBACK) para todo el -

Notar que nuestra descripcin del proceso de recuperacin del sistema est muy simplificada. En particular, muestra alsistema realizando primero operaciones de "deshacer" y luego operaciones de "rehacer". Los primeros sistemasfuncionaban de esa forma, pero por razones de eficiencia los sistemas modernos generalmente hacen las cosas alrevs.

7/13/2019 Tes 1232

32/82

32

sistema. Esa instruccin es manejada por un componente del sistema llamadocoordinador, cuya tarea es garantizar que los dos administradores de recursos (osea, IMS y DB2, en nuestro ejemplo) comprometan o anulen al unsono lasmodificaciones de las cuales son responsables, y adems hacer valerosa garantaan si el sistema falla durante el proceso.Y es el protocolo de compromiso en dos

fases el que le permite ofrecer esa garanta.Veamos cmo funciona. Vamos a suponer por sencillez que la transaccin terminacon xito, de modo que la operacin para todo el sistema es COMMIT, noROLLBACK.

Al recibir esa solicitud de comprometer, el coordinador realiza el siguiente procesode dos fases:

1. Primero, ordena a todos los administradores de recursos que se preparen paracualquiera de las dos posibilidades con respecto a la transaccin. En laprctica, esto significa que cada uno de los administradores de recursos debeforzar la grabacin de todas las entradas de la bitcora correspondientes a los

recursos locales empleados por la transaccin en su propia bitcora fsica (esdecir, en almacenamiento no voltil; suceda lo que suceda despus, elmanejador de recursos tendr ya un registro permanente de lo que hizo conrespecto a la transaccin, y as podr comprometer o anular susmodificaciones, segn sea necesario). Si la grabacin forzada tiene xito, elmanejador de recursos contestar todo bien al coordinador. En casocontrario, contestar no est bien.

2. Cuando el coordinador haya recibido respuesta de todos los manejadores derecursos, forzar la grabacin de una entrada en su propiabitcora fsica, pararegistrar su decisin en cuanto a la transaccin. Si todas las respuestas fuerontodo bien, la decisin ser comprometer; si cualquiera de las respuestas

fue no esta bien, la decisin ser retroceder. En cualquiera de los doscasos, el coordinador informar de su decisin a todos los administradores derecursos, y cada administrador de recursos deber comprometer o anular latransaccin localmente, segn se le haya ordenado. Advirtase que cadaadministrador de recursos debe hacer lo que ordena el coordinador en la fase2; se es el protocolo. (Obsrvese tambin, por cierto, que es la aparicin delregistro de decisin en la bitcora fsica del coordinador lo que marca latransaccin de la fase 1 a la fase 2).

Ahora bien, si el sistema falla en algn punto durante el proceso en general, elprocedimiento se reinicio buscar el registro de decisin en la bitcora delcoordinador. Si lo encuentra, el proceso de compromiso en dos fases podrcontinuar donde fue interrumpido. Si no lo encuentra, supondr que la decisin fueretroceder, con lo cual el proceso se podr completar en la forma apropiada.

Cabe sealar que el administrador de comunicacin de datos (administrador DC)se puede considerar como un administrador de recursos en el sentido que se leacaba de dar. Es decir, los mensajes pueden considerarse como un recursorecuperable, igual que los registros de base de datos, y el administrador DCnecesita ser capaz de participar en el proceso de compromiso en dos fases.

7/13/2019 Tes 1232

33/82

33

Capitulo 3. CONTROL DE CONCURRENCIA.

En el captulo, se exponen los principales conceptos para el control deconcurrencia, as como tambin la necesidad que existe del mismo, para unadecuado manejo de transacciones en un ambiente de mltiples usuarios.

7/13/2019 Tes 1232

34/82

34

3. CONTROL DE CONCURRENCIA.

3.1 Por qu es necesario el contro l de concurrencia?

Uno de los conceptos ms importantes de los sistemas modernos es, sin duda, la

multiprogramacin [7]. Teniendo varias transacciones ejecutndose al mismotiempo, puede compartirse el procesador entre ellas. Los beneficios de lamultiprogramacin son un mejor aprovechamiento del procesador y unaproductividad total de transacciones ms alta, es decir, la cantidad de trabajo quese realiza en un intervalo de tiempo dado. Adems, en el caso de transaccionesinteractivas en las que el usuario espera el resultado, el tiempo de respuesta debeser lo ms corto posible.

As pues, en un entorno de multiprogramacin es posible ejecutar variastransacciones de manera concurrente. Como se ver ms adelante, es necesarioque el sistema controle la interaccin entre las transacciones concurrentes paraevitar que destruyan la consistencia de la base de datos. El control se logra por

medio de varios mecanismos a los que nos referiremos como esquema de controlde concurrencia.

Cuando se ejecutan varias transacciones de manera concurrente, la consistenciade la base de datos puede destruirse an cuando cada una de las transaccionesindividuales sea correcta. En esta seccin presentamos el concepto deserializabilidad para ayudar a identificar las ejecuciones que se garantiza queaseguran la consistencia.

Supondremos que la variable local temporal tiene el mismo nombre que la del datoal que se esta accediendo. As en el resto de esta seccin, usaremos read(Q) ywrite(Q) para read (Q,q) y write (Q,q)

3.2 Planificaciones en serie y en paralelo.

Considrese el sistema bancario simplificado con varias cuentas y un conjunto detransacciones que acceden y actualizan esas cuentas [7]. Sean T0 y T1 doscuentas que transfieren fondos de una cuenta a otra. La transaccin T0 transfiere50 dlares de la cuentaAa la cuentaBy se define as:

T0: read(A);A:=A-50;write(A);

read(B);B:=B+50;write(B).

La transaccin T1transfiere el 10 por 100 del saldo de la cuenta Aa la cuenta Byse define as:

7/13/2019 Tes 1232

35/82

35

T1: read(A);temp:=A*0.1;

A:=A-temp;write(A);read(B);

B:=B+temp;

write(B).Sean los valores actuales de las cuentas A y B, 1000 dlares y 2000 dlares,respectivamente. Supongamos que las dos transacciones se ejecutan de una enuna en el orden T0seguida de T1. Esta secuencia de ejecucin est representadaen la figura 3.2. En la figura, la secuencia de pasos de instruccin est en ordencronolgico de arriba abajo, apareciendo las instrucciones de T0 en la columnaizquierda y las instrucciones de T1en la columna derecha. Los valores finales delas cuentas A y B despus de la ejecucin de la figura 3.2, son 855 dlares y2,145 dlares, respectivamente. As la cantidad total de dinero en la cuentas AyB, es decir, la suma de A+B, se conserva despus de la ejecucin de ambastransacciones.

T0 T1

read(A)A:=A-50write(A)read(B)

B:=B+50write(B)

read(A)temp:=A*0.1

A:=A-tempwrite(A)read(B)

B:=B+tempwrite(B)

Figura 3.2 Planificacin 1, planificacin en serie en la que T0va seguida deT1.

De manera similar, si las transacciones se ejecutan de una en una en el orden T1seguida de T0, entonces la secuencia de ejecucin correspondiente es la de lafigura 3.2.1.Una vez ms, como era de esperar, se conserva la suma A+B, y losvalores finales de las cuentas A y B son 850 dlares y 2,150 dlares,respectivamente.

Las secuencias de ejecucin descritas anteriormente se llaman planificaciones y

representan el orden cronolgico en que se ejecutan las instrucciones en elsistema. Es evidente que una planificacin para un conjunto de transaccionesdebe constar de todas las instrucciones de esas transacciones y debe conservar elorden en que aparecen las instrucciones en cada transaccin individual. Porejemplo, en la transaccin T0, la instruccin write(A) debe aparecer antes de lainstruccin read(B) en cualquier planificacin vlida. En el siguiente estudiollamaremos a la primera secuencia de ejecucin (T0seguida de T1) planificacin 1y a la segunda secuencia de ejecucin (T1seguida de T0) planificacin 2.

7/13/2019 Tes 1232

36/82

36

T0 T1

read(A)temp:=A*0.1

A:=A-tempwrite(A)read(B)

B:=B+tempwrite(B)

read(A)A:=A-50write(A)read(B)

B:=B+50write(B)

Figura 3.2.1 Planificacin 2, planificacin en serie en la que T1va seguida deT0.

Las planificaciones descritas arriba se denominan planificaciones en serie. Cadauna de ellas consta de una secuencia de instrucciones de varias transacciones enlas que las instrucciones pertenecientes a una nica instruccin aparecen juntasen esa planificacin. As, para un conjunto de n transacciones existen n!planificaciones en serie diferentes.

Cuando se ejecutan varias transacciones concurrentemente, no es preciso que laplanificacin correspondiente est en serie. As, el nmero de planificacionesposibles para un conjunto de ntransacciones es mucho mayor que n!Volviendo alejemplo anterior, supngase que las dos transacciones se ejecutan de maneraconcurrente. Existen varias secuencias de ejecucin posibles, ya que ahorapueden irse cambiando varias instrucciones de ambas transacciones. Una de lasposibles planificaciones se muestra en la figura 3.2.2.Despus de llevarse a cabo

esta ejecucin, llegamos al mismo estado que al que se llega en el caso en quelas transacciones se ejecuten en serie en el orden T0seguida de T1. La sumaA+Bs se conserva.

T0 T1

read(A)A:=A-50write(A)

read(A)temp:=A*0.1

A:=A-tempwrite(A)

read(B)B:=B+50write(B)

read(B)B:=B+tempwrite(B)

Figura 3.2.2 Planificacin 3, planificacin serializable concurrente.

7/13/2019 Tes 1232

37/82

37

No todas las ejecuciones concurrentes resultan en un estado incorrecto. Parailustrarlo considrese la planificacin en paralelo de la figura 3.2.3.Despus de laejecucin de esta planificacin llegamos a un estado en el que los valores finalesde las cuentas A y B son 950 dlares y 2,100 dlares, respectivamente. Esteestado final es un estado inconsistente, ya que hemos ganado 50 dlares en el

proceso de la ejecucin concurrente. De hecho, la ejecucin de las dostransacciones no conserva la sumaA+B.

Es necesario que una transaccin sea un programa que conserve la consistencia.Es decir, cada transaccin, al ejecutarse sola, transfiere el sistema de un estadoconsistente a un nuevo estado consistente. Sin embargo, durante la ejecucin deuna transaccin puede que el sistema entre temporalmente en un estadoinconsistente. La inconsistencia temporal es la que causa la inconsistencia en lasplanificaciones en paralelo.

Est claro que una planificacin despus de su ejecucin debe dejar la base de

datos en un estado consistente. Adems, el efecto de una planificacin pudierahaber ocurrido sin ninguna ejecucin concurrente. Es decir, la planificacin debeser, de alguna forma, equivalente a una planificacin en serie. Para precisar mseste concepto necesitamos definir la equivalencia de planificaciones.

T0 T1

read(A)A:=A-50

read(A)temp:=A*0.1

A:=A-tempwrite(A)

read(B)write(A)read(B)

B:=B+50write(B)

B:=B+tempwrite(B)

Figura 3.2.3 Planificacin 4, planificacin no serializable.

Consideramos solamente dos operaciones read y write. As, suponemos que

entre una instruccin read(Q) y una instruccin write(Q) sobre un dato Q, unatransaccin puede realizar una secuencia arbitraria de operaciones sobre el valorde Q. As, las nicas operaciones significativas de una transaccin, desde el puntode vista de una planificacin, son las instrucciones read y write. Debido a esto,normalmente slo mostraremos instrucciones read y writeen las planificaciones,como en la representacin de la planificacin 5 que se muestra en la figura 3.2.4.

7/13/2019 Tes 1232

38/82

38

T0 T1

read(A)write(A)

read(A)write(A)

read(B)write(B)

read(B)write(B)

Figura 3.2.4 Planificacin 5, mostrando solamente las instrucciones read y write.

3.3 Protocolos basados en b loqueo.

Una forma de asegurar la serializabilidad es exigir que el acceso a los datos sehaga de manera mutuamente excluyente [7]; es decir, que mientras unatransaccin accede a un dato, ninguna otra puede modificarlo. El mtodo mscomn que se utiliza para implementar esto, es permitir que una transaccinacceda a un dato slo si tiene actualmente un bloqueo en ese dato.

Bloqueo.

Existen varios modos de bloquear un dato. En esta seccin restringiremos laatencin a dos modos:

Compartido. Si una transaccin Ti, ha obtenido un bloqueo de modocompartido (representado por 5) en el dato Q, entonces Tipuede leer estedato, pero no puede escribir Q.

Exclusivo. Si una transaccin Ti, ha obtenido un bloqueo de modoexclusivo (representado por X) en el dato Q, entonces Ti puede leer yescribir Q.

Exigimos que todas las transacciones pidan un bloqueo en el modo adecuado enel dato Qdependiendo del tipo de operaciones que van a realizar sobre Q.

Dado un conjunto de modos de bloqueo, podemos definir una funcin decompatibilidad en ellos de la siguiente manera. Sean A y B modos de bloqueoarbitrarios. Supngase que una transaccin Tisolicita un bloqueo de modo Aen eldato Qen el cual la transaccin Ti(TiTi) tiene actualmente un bloqueo de modo

B. Si puede concedrsele a la transaccin Tiun bloqueo en Qinmediatamente, apesar de la presencia del bloqueo de modoB, entonces decimos que el modoAescompatible con el modo B. Este tipo de funciones puede representarse de formaconveniente por medio de una matriz. La relacin de compatibilidad entre los dosmodos de bloqueo que se utilizan en esta seccin esta dada por la matriz compde la figura 3.3. Un elemento comp(A,B) de la matriz tiene el valor verdadero si, yslo si, el modoAes compatible con el modo B . Ntese que el modo compartido es compatible con el modo compartido, pero no con el modo exclusivo.

7/13/2019 Tes 1232

39/82

39

En un momento dado, transacciones diferentes pueden tener en forma simultneavarios bloqueos de modo compartido en un dato determinado. Una posteriorsolicitud de bloqueo de modo exclusivo tiene que esperar a que se liberen losbloqueos de modo compartido que existen.

S X

S Verdadero FalsoX Falso Falso

Figura 3.3 Matriz compde compatibilidad de bloqueo.

Una transaccin solicita un bloqueo compartido en el dato Q ejecutando lainstruccin lock-S(Q). De manera similar, un bloqueo exclusivo se solicita pormedio de la instruccin lock-N(Q).Un datos (Q) puede desbloquearse por mediode la instruccin unlock(Q).

Para acceder a un dato, la transaccin Tiprimero debe bloquearlo. Si un dato yaest bloqueado por otra transaccin en un modo incompatible, entonces Tidebeesperar hasta que se liberen todos los bloqueos incompatibles que tengan otras

transacciones. La transaccin Ti puede desbloquear un dato al que hababloqueado con anterioridad.

Cabe hacer notar que una transaccin debe tener un bloqueo en un dato mientrasest accediendo a l. Adems, no siempre es deseable que una transaccindesbloquee un dato inmediatamente despus de su ltimo acceso a ese dato, yaque existe la posibilidad de que no puede garantizarse la serializabilidad.

Para ilustrarlo, considrese de nuevo el sistema bancario simplificado. Sean Ay Bdos cuentas