Tecnologas de la Informacin y Comunicacin INFORME DE PRCTICA

Universidad Tecnolgica del Sureste de Veracruz

Tecnologas de la Informacin y Comunicacin

Universidad Tecnolgica del Sureste de Veracruz pg. 1

Tecnologas de la Informacin y Comunicacin INFORME DE PRCTICA

Actividad 2
BASES DE DATOS PARA APLICACIONES PRESENTAN
Jos Alberto Torres Santiago

CUATRIMESTRE Y GRUPO

8to. 801

NOMBRE DEL DOCENTE

M.C.EUNICE MORALES REYES.

Cd. Nanchital, Ver., a 09 de Febrero del 2012.

ndice de Contenidos
Concepto de Transacciones7 CONCEPTOS DE RECUPERACIN15 Conclusiones23 CONCURRENCIA10

Universidad Tecnolgica del Sureste de Veracruz pg. 2

COPIA DE SEGURIDAD DE LA BASE DE DATOS Y RECUPERACIN ANTE FALLOS CATASTRFICOS21

Tecnologas de la Informacin y Comunicacin INFORME DE PRCTICA

D
DESARROLLO DE LA PRCTICA6

I
Introduccin4 INVESTIGACION7

O
Objetivo3

P
PROTOCOLO BASADO EN TECNICAS DE BLOQUEO17

R
Referencias Bibliogrficas24

T
Tipos de transacciones9

Objetivo
El alumno de tecnologas de informacin har una investigacin de los conceptos bsicos de la materia de Bases de datos Distribuidas del tema Transacciones. Debe de aprender que son:
Universidad Tecnolgica del Sureste de Veracruz pg. 2

Tecnologas de la Informacin y Comunicacin INFORME DE PRCTICA Las transaccin Los Tipos de Transacciones Concurrencia Recuperacin Protocolo basados en tcnica de bloqueo Y copia de seguridad Al final de la investigacin el alumno ya deber conocer todo estos conceptos.

Introduccin
Una base de datos es una forma de almacenar y acceder a informacin de forma estructurada. Las bases de datos se usan a travs de los llamados sistemas de gestin de bases de datos, o SGBD, de los cuales buenos ejemplos son Oracle o Sybase entre las
Universidad Tecnolgica del Sureste de Veracruz pg. 1

Tecnologas de la Informacin y Comunicacin INFORME DE PRCTICA

bases de datos de pago, y PostgreSQL, MySQL o FireBird entre las libres y gratuitas. Habitualmente los SGBD se dividen en varias partes: un servidor, que se ejecuta en un ordenador determinado, y da acceso al espacio estructurado como una BD usando una variedad de interfaces diferentes, aparte de otra serie de servicios, como autentificacin y autorizacin, y un cliente, que permiten al usuario o a los programas acceder a esos datos. A veces por medio hay otras capas, habitualmente llamadas middleware, de las que no nos vamos a ocupar.

Universidad Tecnolgica del Sureste de Veracruz pg. 2

Tecnologas de la Informacin y Comunicacin INFORME DE PRCTICA

DESARROLLO DE LA PRCTICA

Universidad Tecnolgica del Sureste de Veracruz pg. 2

Tecnologas de la Informacin y Comunicacin INFORME DE PRCTICA

INVESTIGACION

Concepto de Transacciones
Una Transaccin es un conjunto de operaciones que forman una nica

unidad lgica de trabajo. Aunque se realicen varias operaciones (actualizaciones, consultas, eliminaciones, etc) desde el punto de vista del usuario la operacin es nica. Ejemplos: Transferencia de fondos, Registrar un pago, matricularse, etc. La transaccin consiste en todas las operaciones que se ejecutan entre las instrucciones Inicio de Transaccin y Fin de Transaccin

Universidad Tecnolgica del Sureste de Veracruz pg. 2

 Una transaccin en un Sistema de Gestin de Bases de Datos (SGBD),

Tecnologas de la Informacin y Comunicacin INFORME DE PRCTICA

es un conjunto de rdenes que se ejecutan formando una unidad de trabajo, es decir, en forma indivisible o atmica. Un SGBD se dice transaccional, si es capaz de mantener la integridad de los datos, haciendo que estas transacciones no puedan finalizar en un estado intermedio. Cuando por alguna causa el sistema debe cancelar la transaccin, empieza a deshacer las rdenes ejecutadas hasta dejar la base de datos en su estado inicial (llamado punto de integridad), como si la orden de la transaccin nunca se hubiese realizado. Para esto, el lenguaje de consulta de datos SQL (Structured Query Language), provee los mecanismos para especificar que un conjunto de acciones deben constituir una transaccin. BEGIN TRAN: Especifica que va a empezar una transaccin. COMMIT TRAN: Le indica al motor que puede considerar la transaccin completada con xito. ROLLBACK TRAN: Indica que se ha alcanzado un fallo y que debe restablecer la base al punto de integridad. En un sistema ideal, las transacciones deberan garantizar todas las propiedades ACID; en la prctica, a veces alguna de estas propiedades se simplifica o debilita con vistas a obtener un mejor rendimiento. Las transacciones deben de cumplir con las siguientes propiedades (ACID) para garantizar la integridad de los datos: Atomicidad: Todas las operaciones se realizan o ninguna. Consistencia: Los invariantes de la BD se conservan antes y despus de la ejecucin de la transaccin. Aislamiento: No importa que se ejecuten transacciones concurrentemente, desde el punto de vista del usuario lucen secuenciales (unas no afectan la ejecucin de las otras). Durabilidad: Los cambios comprometidos perduran en el tiempo. Estados de una transaccin Activa, el estado inicial; la transaccin permanece en este estado mientras se est ejecutando. Parcialmente comprometida, despus de ejecutarse la ltima instruccin. Fallida, despus de descubrir que la ejecucin normal ya no puede llevarse a cabo. Abortada, despus del retroceso de la transaccin y haber restaurado la base de datos su estado anterior al inicio de la transaccin. Dos opciones despus de que haya abortado: reiniciar la transaccin cancelar la transaccin Comprometida, despus de terminar con xito.

Universidad Tecnolgica del Sureste de Veracruz pg. 1

Tecnologas de la Informacin y Comunicacin INFORME DE PRCTICA

Clasificacin de la transaccin
Una transaccin puede clasificarse de diferentes maneras dependiendo bsicamente de tres criterios:
1. reas de aplicacin. En primer lugar, las transacciones se pueden ejecutar

en aplicaciones no distribuidas. Las transacciones que operan en datos distribuidos se les conoce como transacciones distribuidas. Por otro lado, dado que los resultados de una transaccin que realiza un commit son durables, la nica forma de deshacer los efectos de una transaccin con commit es mediante otra transaccin. A este tipo de transacciones se les conoce como transacciones compensatorias. Finalmente, en ambientes heterogneos se presentan transacciones heterogneas sobre los datos.
2. Tiempo de duracin. Tomando en cuenta el tiempo que transcurre desde

que se inicia una transaccin hasta que se realiza un commit o se aborta, las transacciones pueden ser de tipo batch o en lnea. Estas se pueden diferenciar tambin como transacciones de corta y larga vida. Las transacciones en lnea se caracterizan por tiempos de respuesta muy cortos y por acceder un porcin relativamente pequea de la base de datos. Por otro lado, las transacciones de tipo batch toman tiempos relativamente largos y accedan grandes porciones de la base de datos.
3. Estructura. Considerando la estructura que puede tener una transaccin se

examinan dos aspectos: si una transaccin puede contener a su vez subtransacciones o el orden de las acciones de lectura y escritura dentro de una transaccin.

Transacciones Abortadas

Una transaccin puede no llegar a su trmino debido a muchas razones: situacin excepcional detectada que hace que el programa no pueda continuar
Universidad Tecnolgica del Sureste de Veracruz pg. 2

Tecnologas de la Informacin y Comunicacin INFORME DE PRCTICA

falla del programa falla del software de BD falla del Sistema Operativo falla del hardware falla de energa elctrica control de concurrencia ha detectado un conicto control de concurrencia ha detectado un deadlock

Tipos de transacciones

Cundo inicia y finaliza una transaccin?

Una transaccin inicia cuando la primera sentencia DML es encontrada y finaliza cuando ocurre alguno de los siguientes puntos: Una sentencia COMMIT o ROLLBACK es usada Una sentencia DDL, como CREATE es utilizada Una sentencia DCL es usada El usuario sale de iSQL*Plus Una computadora falla o el sistema falla. Despus de que una transaccin finaliza, la siguiente sentencia SQL ejecutada automticamente inicia la siguiente transaccin. Una sentencia DDL o DCL es automticamente completada y por consiguiente implcitamente finaliza una transaccin.

CONCURRENCIA
El termino concurrencia se refiere al hecho de que los DBMS(SISTEMAS DE ADMINISTRACION DE BD)permiten que muchas transacciones puedan accesar a una misma base de datos a la vez. En un sistema de estos se necesitan algn tipo de mecanismos de control de concurrencia para asegurar que las transacciones concurrentes no interfieran entre s. En sistemas multiusuario, es necesario un mecanismo para controlar la concurrencia. Se pueden producir inconsistencias importantes derivadas del acceso concurrente, como por ejemplo, el problema de la operacin perdida. En un sistema de biblioteca, existe un campo que almacena el nmero de copias disponibles para prstamo. Este campo debe incrementarse en uno cada vez que
Universidad Tecnolgica del Sureste de Veracruz pg. 1

se devuelve un ejemplar del libro y disminuirse en uno cada vez que se presta un ejemplar. Si existen varias bibliotecarias, una de ellas inicia la transaccin t1, leyendo la variable numero ejemplares (n), cuyo contenido se guarda en la variable n1. Tiempo despus, otra bibliotecaria podra leer la misma variable incrementndola en una unidad, transaccin t2. Despus, la transaccin t1 aade una unidad a esa variable y la actualiza, el resultado es errneo, ya que la variable N debera haber aumentado en 2 unidades, y solo ha aumentado en una. La transaccin t2 se ha perdido. Consiste en controlar la interaccin entre los usuarios concurrentes para no afectar la inconsistencia de los datos. Cuando se trabajaba con manejadores de archivos y se estaba actualizando un determinado registro, ningn otro usuario poda actualizar el mismo archivo; aunque el registro a trabajar fuera otro. Con esta caracterstica, ya ms de un usuario puede accesar a un mismo registro y actualizarlo. El objetivo fundamental del control de concurrencia de base de datos es garantizar que la ejecucin concurrente de transacciones no resulta en una prdida de consistencia de la base de datos. La concurrencia se da cuando dos transacciones estn interconectadas, lo que es comn en un entorno multiusuario. As pues en un entorno de multiprogramacin es posible ejecutar varias transacciones de manera concurrente.

Tecnologas de la Informacin y Comunicacin INFORME DE PRCTICA

Control de concurrencia en bases de datos relacionales

La mayora de las bases de datos se utilizan en entornos multi-usuario, en los que muchos clientes utilizando la misma aplicacin, o muchas aplicaciones cada una con uno o muchos clientes acceden a la misma base de datos. Cada una de esas aplicaciones enviar consultas al gestor, y normalmente cada hilo de ejecucin ser una transaccin diferente. En la mayora de los sistemas operativos actuales, las diferentes tareas o hilos se ejecutan de forma intercalada (incluso en el caso de mquinas con varios procesadores). Es decir, el sistema operativo decide por su cuenta cuando suspender una de las tareas y darle un poco de tiempo de ejecucin a otra. Si hay tareas simultneas o concurrentes sobre la misma base de datos, esta intercalacin puede resultar en que las lecturas y escrituras de las diferentes tareas o aplicaciones en el medio fsico se realicen en cualquier orden y secuencia. El acceso simultneo descrito puede dar como resultados informacin inconsistente o simplemente incorrecta, dependiendo de la mala o buena suerte que tengamos en la intercalacin de las lecturas y escrituras simultneas. Esta problemtica ha llevado a disear e implementar diferentes estrategias de control de concurrencia, que se encargan de evitar todos esos problemas, de modo que los desarrolladores de las aplicaciones pueden olvidarse de ellos al escribir su cdigo. Por ejemplo, si tenemos una estructura de tablas relacional que incluye las siguientes: PEDIDO(id, num-cliente, id-prod, cantidad, precio) PRODUCTO(id-prod, nombre, ..., stock) ...
Universidad Tecnolgica del Sureste de Veracruz pg. 2

Pueden ocurrir diferentes problemas relacionados con la escritura simultnea con otras escrituras o lecturas, incluyendo los siguientes: 1. Dos sentencias UPDATE que actualicen un mismo producto decrementando el stock del mismo en una unidad podran terminar en que una de ellas no se realizase. Si pensamos en un UPDATE como una secuencia de una lectura y una escritura, puede que ambos UPDATE hagan la lectura, por ejemplo, de un stock de 10, y despus las escrituras, decrementan ese dato, quedando el resultado en 9, mientras que lo correcto era un resultado de 8. 2. Supongamos una sentencia que primero comprueba que hay stock del producto P, y despus inserta un nuevo PEDIDO de diez unidades del producto P, que tiene un stock de 10, seguido de unUPDATE al stock por esa cantidad. Puede que otra insercin de un pedido se ejecute antes del UPDATE pero despus de la comprobacin, haciendo quedar el stock del producto en negativo. Existen varias tcnicas para controlar la concurrencia. Los bloqueos son los ms conocidos, aunque tambin se utiliza el control multi-versin y otras tcnicas como las marcas de tiempo. Una forma de controlar la concurrencia es hacer que cada transaccin deba adquirir un derecho de acceso exclusivo a cada fragmento de datos que necesite modificar. A estos derechos se les denomina bloqueos.

Tecnologas de la Informacin y Comunicacin INFORME DE PRCTICA

Bloqueos binarios
La forma ms simple de bloquear es utilizar bloqueos binarios. En un bloqueo binario, cada transaccin debe solicitar el bloqueo de cada fragmento de datos A que vaya a utilizar antes de acceder a l (sea para leerlo o escribirlo), mediante una operacin bloquear(A). Deber liberar todos los bloqueos, mediante una operacin desbloquear(A) de modo que otras tareas puedan tomarlos. Este sistema de bloqueos tiene una implementacin muy simple, ya que solo requiere mantener una tabla que indica qu partes de los datos est bloqueada y por qu transaccin.
Bloqueos de lectura/escritura

El sistema de bloqueos binarios es simple pero demasiado restrictivo, ya que no permite que dos transacciones que van a leer el mismo fragmento de datos A lo hagan simultneamente, cuando en realidad, no puede haber problemas en varios lectores simultneos. Los bloqueos de lectura/escritura hacen ms dbil la restriccin permitiendo la siguiente compatibilidad de bloqueos.
ESCRITUR A

LECTURA

LECTUR Compatibl Incompati A e ble ESCRITU Incompati Incompati Universidad Tecnolgica del Sureste de Veracruz pg. 1

Tecnologas de la Informacin y Comunicacin INFORME DE PRCTICA

RA ble ble TABLA 1

En este caso, las operaciones que las transacciones deben realizar son tres: desbloquear(A) y bloquear_para_lectura(A) o bloquear_para_escritura(A). Ntese que esas llamadas se implementan de diferentes formas en diferentes gestores de bases de datos. Por ejemplo, en MySQL, tanto las solicitudes de bloqueos como las liberaciones se realizan mediante una sola llamada del API de los gestores de almacenamiento: store_lock(THD *thd, THR_LOCK_DATA **to, enum thr_lock_type lock_type) Cada llamada a store_lock utiliza el manejador de una tabla thd concreta, y se indica la informacin de los datos a bloquear mediante la variable to, y el tipo de bloqueo mediantelock_type (el nmero de tipos definidos en MySQL es muy grande, ya que cubre todos los tipos de bloqueo que implementan los mltiples gestores de almacenamiento disponibles).

Serializacin de los bloqueos de lectura/escritura

La serializacin de las operaciones de lectura y escritura consiste en ordenar esas operaciones para un conjunto de transacciones concurrentes de modo que los resultados de las operaciones sean correctos. Por ejemplo, si tenemos las siguientes transacciones X e Y, puede darse la siguiente situacin.

Figura 1

En esa situacin, la ejecucin de TX y TY hace que el dato original slo se haya incrementado una vez, cuando tena que haberse incrementado dos veces. Sin
Universidad Tecnolgica del Sureste de Veracruz pg. 1

embargo, si hubisemos tenido suerte y todas las operaciones de TX se hubiesen realizado antes que las de TY, el resultado habra sido correcto. La conclusin es que el mero mecanismo de los bloqueos garantiza el acceso exclusivo a un dato o fragmento de informacin (evitando ciertos problemas), pero los problemas asociados a la intercalacin de las operaciones compuestas an pueden darse. Por lo tanto, hace falta alguna poltica o mecanismo de adquisicin y liberacin de bloqueos que permita hacer las operaciones serializables.

Tecnologas de la Informacin y Comunicacin INFORME DE PRCTICA

El bloqueo en dos fases permite la serializacin

El protocolo de bloqueo en dos fases fuerza a las transacciones cuando todas las operaciones de adquisicin de bloqueos (bloquear_lectura, bloquear_escritura) preceden a la primera operacin de desbloqueo (desbloquear). Dicho de otro modo, primero hay que adquirir todos los bloqueos, y despus se pueden liberar. Cuando se utiliza el protocolo de bloqueo en dos fases, puede demostrarse que la ejecucin ser serializable.

Inconvenientes de los bloqueos y la serializacin

Un problema del protocolo de bloqueo en dos fases es que puede llevar a situaciones de interbloqueo. La siguiente es una secuencia de operaciones que lleva al interbloqueo pero cumple perfectamente l protocolo de bloqueo en dos fases. El inconveniente est en que puede que en la fase de adquisicin de bloqueos (fase de expansin), ms de una transaccin est interesada en los mismos dos fragmentos de datos, y la mala suerte nos lleve a una situacin en la que ambos quedan suspendidos, sin posibilidad de avanzar.
Figura 2

Bloqueos ms grandes o ms pequeos?

Un aspecto que an no se ha tratado en la discusin anterior es cun grandes son los elementos de datos que se deben bloquear. Una opcin posible es
Universidad Tecnolgica del Sureste de Veracruz pg. 2

bloquear tablas enteras. Esto hace que la gestin de los bloqueos sea simple y tenga poca sobrecarga (solo hay que guardar el estado de bloqueo de las N tablas). No obstante, esto impide que dos transacciones que van a manipular filas diferentes de una tabla puedan progresar en paralelo. Una segunda opcin es utilizar bloqueos al nivel de las filas. En este caso, se hacen mayores las posibilidades de concurrencia, pero por otro lado, hay que mantener mucha ms informacin sobre los bloqueos (ya que el nmero de filas es en general muy grande respecto al nmero de tablas), y el servidor se sobrecarga ms con la gestin de los bloqueos. Hay gestores de bases de datos que permiten seleccionar el tipo de bloqueo que queremos para nuestra base de datos. Por ejemplo, en MySQL hay gestores de almacenamiento que ofrecen bloqueo a nivel de fila, y otros bloqueo a nivel de tabla. No obstante lo anterior, hay sentencias que siempre producirn un bloqueo de tabla, como por ejemplo una sentencia ALTER TABLE.

Tecnologas de la Informacin y Comunicacin INFORME DE PRCTICA

Guardando instantneas de los datos: el Control Multi-versin

El protocolo de bloqueo en dos fases limita considerablemente las posibilidades de concurrencia. Si observamos los problemas que causan los bloqueos no serializados, veremos que muchos de los problemas estn en que una transaccin lee un cierto dato y antes de escribir el resultado, otra transaccin lee el dato antiguo. En ese momento, cada transaccin trabaja con un estado de informacin inconsistente. Para paliar esos problemas, pero permitir la mayor concurrencia posible, se han diseado los protocolos de control multi-versin. La idea bsica es que cuando una transaccin modifica un dato, se crea una nueva versin del mismo, pero se guarda la anterior. De este modo, al acabar la ejecucin de las transacciones, se puede utilizar para cada una de ellas la versin de los datos que hace la ejecucin correcta, es decir, que hace la ejecucin serializable. Lgicamente, estas tcnicas requieren ms espacio de almacenamiento para guardar las diferentes versiones.

CONCEPTOS DE RECUPERACIN
Descripcin de la recuperacin y clasificacin de los algoritmos de recuperacin

Recuperarse del fallo de una transaccin normalmente significa que la base de datos se restaura al estado coherente ms reciente, inmediatamente anterior al momento del fallo. Para ello, el sistema debe guardar informacin sobre los cambios que las distintas transacciones aplicaron a los elementos de datos. Esta informacin normalmente se guarda en el registro del sistema, Una estrategia tpica para recuperarse se puede resumir informalmente de este modo: 1. Si hay un dao extensivo a una amplia porcin de la base de datos debido a un fallo catastrfico, como una cada del disco, el mtodo de recuperacin restaura una copia de seguridad antigua de la base de datos que normalmente se archiva en cinta y reconstruye un estado ms actual volviendo a aplicar o rehaciendo las
Universidad Tecnolgica del Sureste de Veracruz pg. 2

operaciones de las transacciones confirmadas a partir de la copia de seguridad del registro,hasta el momento del fallo. 2. Cuando la base de datos no est daada fsicamente, pero se ha vuelto inconsistente por fallos no catastrficos de los tipos 1 a 4 (consulte la Seccin 17.1.4), la estrategia es invertir cualquier cambio que provocara la inconsistencia deshaciendo algunas operaciones. Tambin puede ser necesario rehacer algunas operaciones a fin de restaurar un estado consistente de la base de datos, como veremos. En este caso, no necesitamos una copia archivada completa de la base de datos. En su lugar, durante la recuperacin se consultan las entradas guardadas en el registro del sistema online. Conceptualmente, podemos distinguir dos tcnicas principales para recuperarse frente a fallos no catastrficos:actualizacin diferida y actualizacin inmediata. Las tcnicas de actualizacin diferida no actualizan fsicamente la base de datos en el disco hasta que la transaccin haya alcanzado su punto de confirmacin; es entonces cuando las actualizaciones se graban en la base de datos. Antes de alcanzar la confirmacin, todas las actualizaciones de las transacciones se guardan en el espacio de trabajo de transaccin local (o bferes).Durante la confirmacin, las actualizaciones se guardan primero en el registro del sistema y, despus, se escriben en la base de datos. Si una transaccin falla antes de alcanzar su punto de confirmacin, no habr cambiado la base de datos en absoluto, por lo que no se necesita DESHACER. Puede ser necesario REHACER el efecto de las operaciones de una transaccin confirmada a partir del registro, porque es posible que su efecto no se haya grabado todava en la base de datos. Por tanto, la actualizacin diferida tambin se conoce como algoritmo NODESHACER/REHACER, tcnica que explicamos en la Seccin 19.2.En las tcnicas de actualizacin inmediata, la base de datos puede ser actualizada por algunas operaciones de una transaccin antes de que esta ltima alcance su punto de confirmacin. Sin embargo, esas operaciones se graban normalmente en el registro del sistema, en disco, antes de que se apliquen a la base de datos, lo que todava hace posible la recuperacin. Si una transaccin falla despus de grabar algunos cambios en la base de datos pero antes de alcanzar su punto de confirmacin, el efecto de sus operaciones sobre la base de datos debe deshacerse; es decir, la transaccin debe anularse. En el caso general de una actualizacin inmediata,durante la recuperacin es posible tener que recurrir a deshacer y rehacer. Esta tcnica, conocida como algoritmo DESHACER/REHACER, requiere las dos operaciones, y se utiliza con mucha frecuencia en la prctica. Una variante del algoritmo en la que todas las actualizaciones se graban en la base de datos antes de que la transaccin se confirme slo requiere la operacin de deshacer, por lo que recibe el nombre de algoritmo DESHACER/NOREHACER. En la Seccin 19.3 explicamos estas tcnicas.

Tecnologas de la Informacin y Comunicacin INFORME DE PRCTICA

RECUPERACIN DISTRIBUIDA
El proceso de recuperacin en una base de datos distribuida es algo complejo, y aqu slo ofrecemos una breve introduccin. En ciertos casos, es incluso ms complicado determinar si un sitio est cado sin intercambiar numerosos
Universidad Tecnolgica del Sureste de Veracruz pg. 2

mensajes con otros sitios. Por ejemplo, supongamos que el sitio X enva un mensaje al Yesperando recibir una respuesta que no llega. Existen varias explicaciones para esto: El mensaje no fue entregado a Y debido a un fallo en la comunicacin. El sitio Y est cado y no pudo responder. El sitio Y est funcionando y enva una respuesta, pero sta no fue entregada. Sin otra informacin, o el envo de mensajes adicionales, resulta muy complicado determinar qu ha ocurrido realmente.Otro problema que aparece en la recuperacin distribuida es la confirmacin distribuida. Cuando una transaccin est actualizando datos en varios sitios, no puede realizar una confirmacin hasta que no est seguro de que el efecto de la misma no pueda perderse en cada sitio. Esto significa que cada uno de ellos debe haber registrado permanentemente los efectos locales de las transacciones en el lag de sitio local en disco. El protocolo de confirmacin en dos fases, comentado en la Seccin 19.6, suele emplearse a veces para asegurar la exactitud de la confirmacin distribuida.

Tecnologas de la Informacin y Comunicacin INFORME DE PRCTICA

PROTOCOLO BASADO EN TECNICAS DE BLOQUEO

Tcnicas de bloqueo en dos fases para controlar la concurrencia

Algunas de las principales tcnicas que se utilizan para controlar la ejecucin concurrente de transacciones estn basadas en el concepto de bloqueo de elementos de datos. Un bloqueo es una variable asociada a un elemento de datos que describe el estado de ese elemento respecto a las posibles operaciones que se le puedan aplicar. Generalmente, hay un bloqueo por cada elemento de datos de la base de datos. Los bloqueos se utilizan como un medio para sincronizar el acceso de las transacciones concurrentes a los elementos de la base de datos. En la Seccin 18.1.1 explicamos la naturaleza y los tipos de bloqueos. Despus, en la Seccin 18.1.2presentamos los protocolos que utilizan el bloqueo para garantizar la serializacin de las planificaciones de transacciones. Por ltimo, en la Seccin 18.1.3 explicamos dos problemas asociados con el uso de bloqueos (interbloqueo e inanicin), as como su manipulacin. Tipos de bloqueos y tablas de bloqueo del sistema En el control de la concurrencia se utilizan varios tipos de bloqueos. A fin de introducir gradualmente los conceptos de bloqueo, primero explicamos los bloqueos binarios, que son sencillos pero restrictivos, por lo que no se utilizan en la prctica. Despus explicamos los bloqueos compartidos/exclusivos, que ofrecen unas capacidades de bloqueo ms generales y que se utilizan en la prctica en los esquemas de bloqueo de bases de datos. En la Seccin 18.3.2 describimos un bloqueo de certificacin y mostramos cmo puede utilizarse para mejorar el rendimiento de los protocolos de bloqueo. Bloqueos binarios. Un bloqueo binario puede tener dos estados o valores: bloqueado y desbloqueado (o 1 y O, para simplificar). Cada elemento X de la base de datos tiene un bloqueo distinto. Si el valor del bloqueo sobre X es 1, el elemento X no podr ser accedido por una operacin de base de datos que
Universidad Tecnolgica del Sureste de Veracruz pg. 1

solicite el elemento.Si el valor del bloqueo sobre X es O, es posible acceder al elemento cuando es solicitado. Nos referiremos al valor (o estado) actual del bloqueo asociado con el elemento X como bloquear(X).Con el bloqueo binario se utilizan dos operaciones, bloquear_elemento y desbloquear_elemento. Una transaccin solicita acceso a un elemento X emitiendo primero una operacin bloquear_elemento(X). Si BLOQUEAR(X)= 1, la transaccin est obligada a esperar. Si BLOQUEAR(X)=O, se establece a 1 (la transaccin bloquea el elemento) y la transaccin tiene permiso para acceder al elemento X. Cuando la transaccin ha terminado de utilizar el elemento, emite una operacin desbloquear_elemento(X), que asigna O a BLOQUEAR(X) (desbloquea el elemento) por lo que otras transacciones pueden acceder a X. Por tanto, un bloqueo binario impone la exclusin mutua en el elemento de datos. En la Figura 18.1 se muestra una descripcin de las operaciones bloquear_elemento(X) y desbloquear_elemento(X). Las operaciones bloquear_elemento y desbloquear_elemento deben implementarse como unidades indivisibles (conocidas como secciones crticas en los sistemas operativos); es decir, no debe permitirse la interpolacin una vez iniciada una operacin de bloqueo o desbloqueo hasta que la operacin termina o la transaccin espera. En la Figura 18.1, el comando esperar dentro de la operacin bloquear_elemento(X) se implementa normalmente colocando la transaccin en una cola de espera para el elemento X hasta que se desbloquea ste y la transaccin obtiene acceso a l. Las dems transacciones que tambin quieren acceder a X se colocan en la misma cola. Por tanto, se considera que el comando esperar est fuera de la operacin bloquear_elemento. Es muy fcil implementar un bloqueo binario; basta con una variable de tipo binario, BLOQUEAR, asociada a cada elemento de datos X de la base de datos. En su forma ms sencilla, un bloqueo puede ser un registro con tres campos: <Nombre_elemento_datos, BLOQUEAR, Transaccin_de_bloqueo>, ms una cola para las transacciones que estn esperando a acceder al elemento. El sistema slo necesita guardar registros de este tipo para los elementos que actualmente estn bloqueados, y lo hace en una tabla de bloqueo, que puede organizarse como un fichero de dispersin. Los elementos que no figuran en esta tabla estn desbloqueados. El DBMS tiene un subsistema gestor de bloqueos que rastrea y controla el acceso a los bloqueos. En caso de utilizar este sencillo esquema de bloqueo binario, cada transaccin debe cumplir las siguientes reglas: 1. Una transaccin T debe emitir la operacin bloquear_elemento(X) antes de que se ejecute cualquier operacin leer_elemento(X) o escribir_elemento(X) en T. Figura 18.1. Operaciones de bloqueo y desbloqueo para lo bloqueos binarios, bloquear _elemento(X): B: Si BLOQUEAR(X) = O (* elemento desbloqueado *) then BLOQUEAR(X) +- 1 (* bloquear el elemento *) entonces inicio esperar (hasta BLOQUEAR(X) = O Y el gestor de bloqueo retoma la transaccin); ir a B fin; desbloquear _ elemento(X):
Universidad Tecnolgica del Sureste de Veracruz pg. 2

Tecnologas de la Informacin y Comunicacin INFORME DE PRCTICA

BLOQUEAR(X) +- O; (* desbloquear el elemento *) Si hay transacciones esperando entonces retomar una de las transacciones que espera; 2. Una transaccin T debe emitir la operacin desbloquear elemento(X) despus de haberse completado todas las operaciones leer_elemento(X) y escribir_elemento(X) de T 3. Una transaccin T no emitir una operacin bloquear_elemento(X) si ya posee el bloqueo del elementox.1 4. Una transaccin Tno emitir una operacin desbloquear_elemento(X) a menos que ya posea el bloqueo del elemento X. Estas reglas puede implementarlas el mdulo gestor de bloqueos del DBMS. Entre las operaciones bloquear_elemento(X) y desbloquear_elemento(X) de la transaccin T, se dice que T posee el bloqueo del elemento X. A lo sumo, una transaccin puede poseer el bloqueo de un elemento en particular. De este modo, dos transacciones no pueden acceder simultneamente al mismo elemento.Bloqueos compartidos/exclusivos (o lectura/escritura). El esquema de bloqueo binario anterior es demasiado restrictivo para los elementos de base de datos porque, como mximo, slo una transaccin puede poseer un bloqueo sobre un elemento dado. Debemos permitir que varias transacciones tengan acceso al mismo elemento X si todas ellas acceden a X slo para leer. Sin embargo, si una transaccin va a escribir un elemento X, debe tener acceso exclusivo a X. Con este fin, se utiliza un tipo de bloqueo diferente denominado bloqueo de modo mltiple. En este esquema (denominado bloqueos compartido/exclusivo o de lectura/escritura) hay tres operaciones de bloqueo: bloquearJectura(X), bloquear_escritura(X) y desbloquear(X). Un bloqueo asociado con un elemento X, BLOQUEAR(X), tiene ahora tres posibles estados: bloqueado para lectura, bloqueado para escritura o desbloqueado. Un elemento bloqueado para lectura tambin se denomina de lectura compartida porque otras transacciones pueden leer el elemento, mientras que un elemento bloqueado para escritura se denomina de escritura exclusiva porque una sola transaccin posee en exclusiva el bloqueo de un elemento. Un mtodo para implementar las operaciones anteriores en un bloqueo de lectura/escritura es hacer un seguimiento del nmero de transacciones que poseen un bloqueo compartido (lectura) sobre un elemento de la tabla de bloqueo. Cada registro de dicha tabla tendr cuatro campos: <Nombre_elemento_datos, BLOQUEAR,Nmero_deJecturas, Transaccin(esLbloqueo(s. Una vez ms, para ahorrar espacio, el sistema debe mantener registros de bloqueo slo para los elementos bloqueados de la tabla de bloqueo. El valor (estado) de BLOQUEAR puede ser bloqueado para lectura o bloqueado para escritura, adecuadamente codificado (si asumimos que no se guardan registros en la tabla de bloqueo para los elementos desbloqueados). Si BLOQUEAR(X)=bloqueado para escritura, el valor de Transaccin(esLbloqueo(s) es una sola transaccin que almacena el bloqueo exclusivo (escritura) de X Si BLOQUEAR(X)=bloqueado para lectura, el valor de Transaccin(esLbloqueo(s) es una lista de una o ms transacciones que poseen el bloqueo compartido (lectura)de X En la Figura 18.2 se describen las tres operaciones, bloquearJectura(X), bloquear_escritura(X) y desbloquear(X).2 Como antes, cada
Universidad Tecnolgica del Sureste de Veracruz pg. 1

Tecnologas de la Informacin y Comunicacin INFORME DE PRCTICA

una de las tres operaciones debe considerarse como indivisible; no debe permitirse la interpolacin una vez iniciada una de las operaciones, hasta que la operacin termina concediendo el bloqueo, o la transaccin se coloca en una cola de espera para el elemento. Cuando utilizamos el esquema de bloqueo compartido/exclusivo, el sistema debe implementar las siguientes reglas: 1. Una transaccin T debe emitir la operacin bloqueaUectura(X) o bloquear_escritura(X) antes de que se ejecute cualquier operacin leer_elemento(X) de T 2. Una transaccin T debe emitir la operacin bloquear_escritura(X) antes de que se ejecute cualquier operacin escribir_elemento(X) de T 3. Una transaccin T debe emitir la operacin desbloquear(X) una vez que se hayan completado todas las operaciones leer_elemento(X) y escribir_elemento(X) de T3 4. Una transaccin T no emitir una operacin bloqueaUectura(X) si ya posee un bloqueo de lectura(compartido) o de escritura (exclusivo) para el elemento X Esta regla se puede hacer menos estricta,como veremos en breve. 5. Una transaccin T no emitir una operacin bloquear_escritura(X) si ya posee un bloqueo de lectura(compartido) o de escritura (exclusivo) para el elemento X Esta regla se puede hacer menos estricta,como veremos en breve. 6. Una transaccin T no emitir una operacin desbloquear(X) a menos que ya posea un bloqueo de lectura(compartido) o de escritura (exclusivo) sobre el elemento X Conversin de bloqueos. En ocasiones, es deseable hacer menos estrictas las condiciones 4 y 5 del listado anterior para permitir una conversin del bloqueo; es decir, una transaccin que ya posee un bloqueo sobre el elemento X tiene permitido, bajo ciertas condiciones, convertir el bloqueo de un estado a otro. Por ejemplo,es posible para una transaccin T emitir una operacin bloquear_lectura(X) y ms tarde promocionar el bloqueo emitiendo una operacin bloquear_escritura(X). Si T es la nica transaccin que posee un bloqueo de lectura sobre X en el momento de emitir la operacin bloquear_escritura(X), el bloqueo puede promocionarse; en caso contrario, la transaccin debe esperar. Tambin es posible para una transaccin T emitir una operacin bloquear_escritura(X) y ms tarde degradar el bloqueo emitiendo una operacin bloqueaUectura(X).Cuando se utiliza la promocin y la degradacin de bloqueos, la tabla de bloqueo debe incluir los identificadores de transaccin en la estructura de registro de cada bloqueo [en el campo Transaccin(esLbloqueo(s)]para almacenar la informacin sobre las transacciones que poseen bloqueos sobre el elemento. Las descripciones de las operaciones bloqueaUectura(X) y bloquear_escritura(X) de la Figura 18.2 deben modificarse adecuadamente. Lo dejamos como ejercicio para el lector. Con los bloqueos binarios o bloqueos de lectura/escritura en las transacciones, como describimos anteriormente,no est garantizada la serializacin de las planificaciones. La Figura 18.3 muestra un ejemplo en el que se han seguido las reglas de bloqueo anteriores pero el resultado puede ser una planificacin no serializable.
Universidad Tecnolgica del Sureste de Veracruz pg. 2

Tecnologas de la Informacin y Comunicacin INFORME DE PRCTICA

Esto se debe a que en la Figura 18.3(a) los elementos Y de TI y X de T2 se desbloquearon demasiado pronto.Esto permite que se produzca una planificacin como la de la Figura 18.3(c), que no es una planificacin Figura 18.2. Bloqueo y desbloqueo de operaciones para bloqueos de dos modos (lectura/escritura o compartido/exclusivo ). bloquear_lectura(X): B: Si BLOQUEAR(X) 5 "desbloqueado" entonces inicio BLOQUEAR(X) +- "boqueado para lectura"; Nmero_deJecturas(X) +-1 fin sino Si BLOQUEAR(X) 5 "bloqueado para lectura" entonces Nmero_deJecturas(X) +- Nmero_de_lecturas(X) 1 sino inicio esperar (hasta BLOQUEAR(X) 5 "desbloqueado" y el gestor de bloqueos retoma la transaccin); ir a B fin; bloquear_escritura(X): B: Si BLOQUEAR(X) 5 "desbloqueado" entonces BLOQUEAR(X) +- "bloqueado para escritura" sino inicio esperar (hasta BLOQUEAR(X) 5 "desbloqueado" y el gestor de bloqueos retoma la transaccin); ir a B fin; desbloquear(X) : Si BLOQUEAR(X) 5 "bloqueado para escritura" entonces inicio BLOQUEAR(X) +- "desbloqueado"; retomar una de las transacciones en espera, si las hay fin sino Si BLOQUEAR(X) 5 "bloqueado para lectura" entonces inicio Nmero_deJecturas(X) +- Nmero_deJecturas(X) - 1; Si Nmero_deJecturas(X) 5 O fin; entonces inicio BLOQUEAR(X) 5 "desbloqueado"; retomar una de las transacciones en espera, si las hay fin serializable y, por tanto, ofrece unos resultados incorrectos. Para garantizar la serializacin, debemos seguir un protocolo adicional relativo al posicionamiento de las operaciones de bloqueo y desbloqueo en cada transaccin. El protocolo mejor conocido, el bloqueo en dos fases, se describe en la siguiente seccin.

Tecnologas de la Informacin y Comunicacin INFORME DE PRCTICA

COPIA DE SEGURIDAD DE LA BASE DE DATOS Y RECUPERACIN ANTE FALLOS CATASTRFICOS

Universidad Tecnolgica del Sureste de Veracruz pg. 3

Hasta ahora, todas las tcnicas que hemos explicado son aplicables a fallos no catastrficos. Una suposicin importante ha sido que el registro del sistema se conserva en el disco y que no se pierde como consecuencia del fallo. De forma parecida, el directorio sombra debe almacenarse en el disco para permitir la recuperacin cuando se utiliza la paginacin en la sombra. Las tcnicas de recuperacin que hemos explicado utilizan las entradas del registro del sistema o del directorio sombra para recuperarse ante un fallo, llevando la base de datos de nuevo a un estado consistente. El gestor de recuperacin de un DBMS tambin debe estar equipado para encargarse de fallos ms catastrficos, como la cada de los discos. La principal tcnica que se utiliza para manipular dichas cadas es un copia de seguridad de la base de datos, en la que esta ltima y el registro se copian peridicamente en un medio de almacenamiento de bajo coste, como las cintas magnticas. En caso de un fallo catastrfico del sistema, se puede volver a cargar la ltima copia de seguridad de la cinta al disco, de modo que el sistema se reinicia. Los datos de aplicaciones crticas, como las que se utilizan en banca, aseguradoras, mercados de valores y otras bases de datos, se vuelcan peridicamente en copias de seguridad y se guardan en ubicaciones seguras fsicamente separadas. Se han utilizado cajas fuertes subterrneas para proteger estos datos de inundaciones, tormentas, terremotos o incendios. Eventos recientes como el ataque terrorista delll/S en Nueva York (2001) o el huracn Katrina en Nueva Orleans (2005) han creado una mayor conciencia sobre la recuperacin ante desastres de bases de datos crticas. Para evitar la prdida de todos los efectos de las transacciones que se han ejecutado desde la ltima copia de seguridad, es costumbre hacer una copia de seguridad del registro del sistema a intervalos ms frecuentes que la copia de seguridad de la base de datos completa, copindolo peridicamente en la cinta magntica. Normalmente, el registro del sistema es considerablemente ms pequeo que la propia base de datos y, por tanto, se puede hacer una copia de seguridad de l con ms frecuencia. Por consiguiente, los usuarios no pierden todas las transacciones que han ejecutado desde la ltima copia de seguridad de la base de datos. Es posible rehacer el efecto sobre la base de datos de todas las transacciones confirmadas grabadas en la porcin del registro del sistema que se ha copiado en la cinta. Despus de cada copia de seguridad de la base de datos se inicia un nuevo registro del sistema. Por tanto, para recuperarse ante un fallo del disco, primero se vuelve a crear la base de datos en el disco a partir de su ltima copia de seguridad en cinta. A continuacin, se reconstruyen los efectos de todas las transacciones confirmadas cuyas operaciones se han grabado en las copias de seguridad del registro del sistema.

Tecnologas de la Informacin y Comunicacin INFORME DE PRCTICA

Universidad Tecnolgica del Sureste de Veracruz pg. 1

Tecnologas de la Informacin y Comunicacin INFORME DE PRCTICA

Conclusiones
El alumno desarrollo una investigacin de Bases distribuidas del tema Transacciones donde debio de aprender todos los conceptos basicos.

Universidad Tecnolgica del Sureste de Veracruz pg. 2

Tecnologas de la Informacin y Comunicacin INFORME DE PRCTICA

Referencias Bibliogrficas
Link
http://msdn.microsoft.com/es-es/library/ms190612.aspx http://cnx.org/content/m18939/latest/

Libros:
Vargas, J., Mendoza, M. et al, Fundamentos tericos de bases de datos distribuidas. Mas, Fernando A., Procesamiento de transacciones en sistemas distribuidos, ltima visita 12 de enero 2012 Fundamento de sistema de bases de datos Autor: Ramez Elmasri,Shamkant B.Navathe Editorial: PEARSON Addison Wesley Edicin: 5

Universidad Tecnolgica del Sureste de Veracruz pg. 3

Tecnologas de la Informacin y Comunicacin INFORME DE PRCTICA

Universidad Tecnolgica del Sureste de Veracruz pg. 3