0% encontró este documento útil (0 votos)
38 vistas11 páginas

Control de Concurrencia

Este documento describe los conceptos básicos de las transacciones y el control de concurrencia en bases de datos. Explica que una transacción debe cumplir con las propiedades ACID (atomicidad, coherencia, aislamiento y durabilidad). También describe los tipos de transacciones implícitas y explícitas, y cómo el motor de base de datos usa mecanismos como bloqueos y versiones de fila para garantizar la integridad de las transacciones cuando varios usuarios acceden a los datos de forma concurrente.
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd
0% encontró este documento útil (0 votos)
38 vistas11 páginas

Control de Concurrencia

Este documento describe los conceptos básicos de las transacciones y el control de concurrencia en bases de datos. Explica que una transacción debe cumplir con las propiedades ACID (atomicidad, coherencia, aislamiento y durabilidad). También describe los tipos de transacciones implícitas y explícitas, y cómo el motor de base de datos usa mecanismos como bloqueos y versiones de fila para garantizar la integridad de las transacciones cuando varios usuarios acceden a los datos de forma concurrente.
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd
Está en la página 1/ 11

lOMoARcPSD|17230113

Control de Concurrencia

Base de datos II (Universidad Tecnológica de Panamá)

Scan to open on Studocu

Studocu is not sponsored or endorsed by any college or university


Downloaded by Rodrigo Ortiz Fallas (rortiz@ucenfotec.ac.cr)
lOMoARcPSD|17230113

CAPITULO I: IMPLEMENTACIÓN DE BASE DE DATOS RELACIONALES Y TRANSACCIONES

1.0 Introducción

En cualquier base de datos, la falta de administración de las transacciones a menudo produce problemas de
contención y de rendimiento en sistemas con muchos usuarios. A medida que aumenta el número de usuarios
que obtienen acceso a los datos, adquiere importancia el que las aplicaciones utilicen las transacciones
eficazmente.

Los sistemas de bases de datos, según el número de usuarios que pueden utilizarlos de forma concurrente, se
clasifican en sistemas monousuario y multiusuario.

Varios usuarios pueden usar un mismo equipo (servidor) a la vez gracias a la multiprogramación: el computador
puede procesar al mismo tiempo varias transacciones.

1.1 Introducción a las transacciones y bloqueos

Una transacción es una secuencia de operaciones realizadas como una sola unidad lógica de trabajo. Una unidad
lógica de trabajo debe exhibir cuatro propiedades, conocidas como propiedades de atomicidad, coherencia,
aislamiento y durabilidad (ACID), para ser calificada como transacción.

Atomicidad
Una transacción debe ser una unidad atómica de trabajo, tanto si se realizan todas sus modificaciones en los
datos, como si no se realiza ninguna de ellas. En otros términos, la Atomicidad requiere que cada transacción
sea "todo o nada": si una parte de la transacción falla, todas las operaciones de la transacción fallan, y por lo
tanto la base de datos no sufre cambios.

Coherencia
Cuando finaliza, una transacción debe dejar todos los datos en un estado coherente. En una base de datos
relacional, se deben aplicar todas las reglas a las modificaciones de la transacción para mantener la integridad
de todos los datos. Todas las estructuras internas de datos, como índices de árbol o listas doblemente
vinculadas, deben estar correctas al final de la transacción. Se asegura que cualquier transacción llevará a la
base de datos de un estado válido a otro estado válido.

Aislamiento
Las modificaciones realizadas por transacciones simultáneas se deben aislar de las modificaciones llevadas a
cabo por otras transacciones simultáneas. Una transacción es una unidad de aislamiento, permitiendo que

Ing. Gionella L. Araujo Transacciones y Control de la concurrencia Base de Datos II 1

Downloaded by Rodrigo Ortiz Fallas (rortiz@ucenfotec.ac.cr)


lOMoARcPSD|17230113

transacciones concurrentes se comporten como si cada una fuera la única transacción que se ejecuta en el
sistema. El aislamiento requiere que parezca que cada transacción sea la única que manipula el almacén de
datos, aunque se puedan estar ejecutando otras transacciones al mismo tiempo. Una transacción nunca debe
ver las fases intermedias de otra transacción.

Durabilidad
Una vez concluida una transacción, sus efectos son permanentes en el sistema. Las modificaciones persisten aún
en el caso de producirse un error del sistema. Una transacción también es una unidad de recuperación. Si una
transacción se realiza satisfactoriamente, el sistema garantiza que sus actualizaciones se mantienen aunque el
equipo falle inmediatamente después de la confirmación. El registro especializado permite que el procedimiento
de reinicio del sistema complete las operaciones no finalizadas, garantizando la permanencia de la transacción.

Los programadores de SQL son los responsables de iniciar y finalizar las transacciones en puntos que exijan la
coherencia lógica de los datos. El programador debe definir la secuencia de modificaciones de datos que los
dejan en un estado coherente en relación con las reglas de negocios de la organización. El programador incluye
estas instrucciones de modificación en una sola transacción de forma que Motor de base de datos de SQL Server
puede hacer cumplir la integridad física de la misma.

Nota: Una transacción es necesaria cuando un conjunto de sentencias se deben comportar como una
unidad.

Tipos de transacciones:

Transacciones Implícitas.

Este tipo de transacciones, se conocen como transacciones "de Confirmación automática" y es el


comportamiento predeterminado de SQL Server, donde ejecuta (o hace efectivo los cambios en los ficheros de
datos) por separado cada sentencia Transact-SQL justo después de que se termine dicha sentencia.

Por ejemplo, pensemos que tenemos dos INSERT, el primero de los cuales nos da error, y el segundo se ejecuta
de forma exitosa, si trabajamos con Transacciones Implícitas, veremos como el segundo cambio se mantiene
porque cada INSERT se incluye automáticamente en su propia transacción.

Podemos encontrar escenarios donde la confirmación automática de las transacciones (Transacciones


Implícitas) puede ser peligroso, por ejemplo, si
borramos accidentalmente todas las filas (o un grupo de filas) de una tabla, no tendremos opción de deshacer la
transacción.

Una transacción no implícita, una vez creada, permanece abierta y no finaliza hasta que no se produce un
ROLLBACK o se invoca al COMMIT. La Transacciones Implícitas finalizan cuando se inicia una nueva transacción
en la misma sesión.

Para activar el modo de trabajo con las transacciones implícitas se ejecuta:

SET IMPLICIT_TRANSACTIONS ON

Ing. Gionella L. Araujo Transacciones y Control de la concurrencia Base de Datos II 2

Downloaded by Rodrigo Ortiz Fallas (rortiz@ucenfotec.ac.cr)


lOMoARcPSD|17230113

Para desactivar las transacciones implícitas:

SET IMPLICIT_TRANSACTIONS OFF

Trabajar con transacciones implícitas, puede ser problemático en un entorno de producción, ya que los
desarrolladores o los usuarios finales se puede olvidar de cerrar las transacciones, y esto puede ser origen de
bloqueos...

Transacciones explícitas

Por el contrario, las Transacciones explícitas son las que se define en el código T-SQL. Hay que indicar cuando se
inician (BEGIN TRANSACTION) y cuando finalizan (COMMIT TRANSACTION), y pueden albergar un conjunto de
instrucciones dentro de la misma transacción.

Cuando se produce el COMMIT, se hacen efectivos los cambios en los ficheros de datos (.mdf y .ndf). Mientras
no se realiza el COMMIT las sentencias de los cambios se guardan en el log de transacciones (.log), que gracias a
este es posible revertir los cambios si fuese necesario.

Estados por los que puede pasar una transacción:

1.1.1 Administración de las transacciones

La administración de las transacciones de SQL Server es un paso importante para asegurar la fluidez de las
operaciones y evitar los errores por bloqueos. SQL Server implementa diversos niveles de aislamiento de
transacción, para garantizar las propiedades de atomicidad, coherencia, aislamiento y durabilidad (ACID) de
estas transacciones. En términos prácticos, esto significa que utiliza bloqueos y pestillos para mediar el acceso
transaccional a recursos de base de datos compartida y evitar "interferencias" entre las transacciones.

1.1.2 Bloqueos en SQL y 1.1.3 Administración de los bloqueos

Ing. Gionella L. Araujo Transacciones y Control de la concurrencia Base de Datos II 3

Downloaded by Rodrigo Ortiz Fallas (rortiz@ucenfotec.ac.cr)


lOMoARcPSD|17230113

El Motor de base de datos de SQL Server utiliza los siguientes mecanismos para garantizar la integridad de las
transacciones y mantener la coherencia de las bases de datos cuando varios usuarios obtienen acceso a los
datos al mismo tiempo:

• Bloqueo

Cada transacción solicita diferentes tipos de bloqueo en los recursos como, por ejemplo, filas, páginas o
tablas de los que depende la transacción. Estos bloqueos impiden que otras transacciones puedan
modificar los recursos de forma que esto provoque problemas para la transacción que solicita el bloqueo.
Cada transacción libera sus bloqueos cuando ya no depende de los recursos bloqueados.

• Versiones de fila

Cuando un nivel de aislamiento basado en versiones de fila está habilitado, Motor de base de datos de
SQL Server mantiene versiones de cada fila que se ha modificado. Las aplicaciones pueden especificar que
una transacción utilice las versiones de fila para ver los datos tal como eran al empezar la transacción o la
consulta en lugar de proteger todas las lecturas con bloqueos. Mediante las versiones de fila, las
probabilidades de que una operación de lectura bloquee otras transacciones se reduce notablemente.

El bloqueo y las versiones de fila impiden a los usuarios leer los datos no confirmados así como cualquier
intento de cambiar los mismos datos a la vez. Sin el bloqueo o las versiones de fila, las consultas
ejecutadas para esos datos podrían generar resultados inesperados al devolver datos que todavía no se
han confirmado en la base de datos.

En ocasiones, los usuarios tienen acceso a un recurso al mismo tiempo, es decir, simultáneamente. El
acceso simultáneo a los datos requiere la utilización de mecanismos para impedir efectos negativos
cuando varios usuarios intentan modificar recursos que otros usuarios están utilizando.

1.1.1 Concepto sobre control de concurrencia

Acceso simultáneo, uso de una base de datos por múltiples usuarios en un mismo espacio y tiempo.

• Varias transacciones introducidas por usuarios, que se ejecutan de manera concurrente, pueden
leer/modificar los mismos elementos almacenados en la base de datos
• Razones para permitir la concurrencia:
– Aumentar la productividad: número de transacciones ejecutadas por minuto.
– Aumentar la utilización de la CPU (menos tiempo ocioso) y Control del disco.
– Reducir el tiempo medio de respuesta de transacciones (las ‘pequeñas’ no esperan a las
‘grandes’).

¿Por qué es necesario el control de la concurrencia?

• ... porque pueden surgir problemas si las transacciones concurrentes se ejecutan de manera no
controlada

Ing. Gionella L. Araujo Transacciones y Control de la concurrencia Base de Datos II 4

Downloaded by Rodrigo Ortiz Fallas (rortiz@ucenfotec.ac.cr)


lOMoARcPSD|17230113

• Ejemplo sencillo:
sistema de bases de datos que permite hacer y anular reservas de plazas en vuelos de diferentes
compañías aéreas.
– Se almacena un registro por cada vuelo, que incluye, entre otras cosas, el número de asientos
reservados en el vuelo
– *Sean dos transacciones T1 y T2 concurrentes:
▪ T1 transfiere N reservas realizadas en un vuelo X a otro vuelo Y
▪ T2 reserva M plazas en el vuelo X

Aunque las transacciones pueden ser perfectamente correctas en sí mismas, la ejecución concurrente
de T1 y T2 puede producir un resultado incorrecto, debido a la intercalación de sus operaciones,
poniendo en cuestión la integridad y la coherencia de la base de datos

Como ya mencionamos, cuando se realizan varias transacciones de forma simultánea, pueden darse diversas
situaciones en el acceso concurrente a los datos, es decir, cuando se accede a un mismo dato en dos
transacciones distintas. Estas situaciones son:

• Lectura sucia (Dirty Read). Una transacción lee datos que han sido escritos por otra transacción que aún
no se ha confirmado.
• Lectura no repetible (Non-repeateable Read). Una transacción vuelve a leer los datos que ha leído
anteriormente y descubre que otra transacción confirmada ha modificado o eliminado los datos.
• Lectura fantasma (Phantom Read). Una transacción vuelve a ejecutar una consulta que devuelve un
conjunto de filas que satisface una condición de búsqueda y descubre que otra transacción confirmada
ha insertado filas adicionales que satisfacen la condición.

Para una mejor gestión de estas situaciones debemos indicar el nivel de aislamiento que deseamos. De las
cuatro propiedades de ACID de un SGBD, la propiedad de aislamiento es la más laxa. Un nivel de aislamiento
bajo aumenta la capacidad de muchos usuarios para acceder a los mismos datos al mismo tiempo, pero también
aumenta el número de efectos de concurrencia (como lecturas sucias). Un mayor nivel de aislamiento puede dar
como resultado una pérdida de concurrencia y el aumento de las posibilidades de que una transacción bloquee
a otra.

Podemos solicitar al SGBD cuatro niveles de aislamiento. De menor a mayor nivel de aislamiento, tenemos:

• READ UNCOMMITTED (Lectura no confirmada). Las sentencias SELECT son efectuadas sin realizar
bloqueos, por tanto, todos los cambios hechos por una transacción pueden verlos las otras
transacciones. Permite que sucedan las 3 situaciones indicadas previamente: lecturas fantasma, no
repetibles y sucias.

Ing. Gionella L. Araujo Transacciones y Control de la concurrencia Base de Datos II 5

Downloaded by Rodrigo Ortiz Fallas (rortiz@ucenfotec.ac.cr)


lOMoARcPSD|17230113

• READ COMMITTED (Lectura confirmada). Los datos leídos por una transacción pueden ser modificados
por otras transacciones. Se pueden dar lectuas fantasma y lecturas no repetibles.
• REPEATEABLE READ (Lectura repetible). Consiste en que ningún registro leído con un SELECT se puede
cambiar en otra transacción. Solo pueden darse lecturas fantasma.
• SERIALIZABLE. Las transacciones ocurren de forma totalmente aislada a otras transacciones. Se
bloquean las transacciones de tal manera que ocurren unas detrás de otras, sin capacidad de
concurrencia. El SGBD las ejecuta concurrentemente si puede asegurar que no hay conflicto con el
acceso a los datos.

1.3 Control de la concurrencia con métodos de bloqueo

1.3.1 Granularidad

Al referirnos a lo que es bloqueo en bases de datos en realidad utilizamos lo que se conoce como granularidad
del bloqueo.

La granularidad se refiere a que tan fino se quiere que sea un bloqueo. Por ejemplo ¿desea bloquear la tabla
completa (un bloqueo de granularidad gruesa) o solo desea bloquear una fila especifica (un bloqueo de
granularidad fina)?.
Por ejemplo, los datos referentes a graduados, pueden registrarse semestre a semestre, en cambio, los datos
referentes a nivel de posgrado pueden hacerse mensualmente. Mientras mayor sea el nivel de detalle de los
datos, se tendrán mayores posibilidades de análisis, ya que los mismos podrán ser resumidos. Es decir, los datos
que posean granularidad fina (nivel de detalle) podrán ser resumidos hasta obtener una granularidad media o
gruesa.
Deben tenerse en cuenta ciertas cuestiones relacionadas con la profundidad de los bloqueos. Con un bloqueo de
granularidad fina se adquieren muchos recursos para administrar el bloqueo, pero se asegura la consistencias de
los datos. Con un bloqueo de granularidad gruesa se utilizan menos recursos pero se aumenta el riesgo de
inconsistencia de los datos, y tal vez hasta se evite que otros usuarios realicen sus tareas. Por lo general SQL
Server se encarga del bloqueo por nosotros.

Pero ¿qué pasa si se desea establecer específicamente un nivel de bloqueo? por lo general esto no es necesario
en aplicaciones que tienen solo unos cuantos usuarios, pero tal vez algunas veces encontremos que los bloqueos
no se liberan tan rápido como uno quisiera, si esto ocurre se puede especificar la granularidad del bloqueo que
se requiera.

La granularidad representa el nivel de detalle al que se desea almacenar la información sobre el negocio que se
esté analizando. En este tipo de negocio o de inteligencia de negocio se pretende medir en primera medida el
número de graduados por facultad en la UPTC, esta granularidad se define por fecha, contando el número de
graduados en cada semestre del año. Otros datos que se pretende conocer son el número de graduados que
poseen empleo y que no, esta granularidad se relacionara por la dimensión NIVEL_EMPLEO.

1.3.2 Tipos de bloqueo

Un bloqueo es una variable asociada a un elemento de datos de la base de datos, usada para restringir las
operaciones que se pueden aplicar sobre él. Existen varios tipos de bloqueo: binarios (de propiedades limitadas),
compartidos, exclusivos (usados en la práctica), y bloqueos de certificación. Las operaciones sobre bloqueos se

Ing. Gionella L. Araujo Transacciones y Control de la concurrencia Base de Datos II 6

Downloaded by Rodrigo Ortiz Fallas (rortiz@ucenfotec.ac.cr)


lOMoARcPSD|17230113

deben implementar como secciones críticas, es decir, de forma indivisible; el SGBD no deberá alternar sus
instrucciones con otras.

Bloqueos binarios

Se caracterizan por tener dos valores posibles, bloqueados y desbloqueados. Cada elemento de la base de datos
tiene un bloqueo distinto. El bloqueo señala si una transacción está operando sobre el elemento o está libre
para que se pueda operar con él. De esta manera se impide que dos o más transacciones estén operando sobre
un mismo elemento al mismo tiempo. La implementación de un bloqueo binario es simple; basta con un vector
de la siguiente forma: donde el booleano es en sí el indicador del bloqueo.

Bloqueos de lectura/escritura

Son una ampliación de los bloqueos binarios. Tenemos que el bloqueo puede tener tres posibles posiciones:
libre, bloqueado para lectura, y bloqueado para escritura. De esta forma, más de una transacción puede tener
un mismo elemento de datos bloqueado para lectura, pero sólo una para escritura. Si una transacción quiere
escribir en ese elemento, habrá de esperar a que el bloqueo quede libre (cualquiera que sea el tipo de bloqueo),
y a continuación, bloquearlo para escritura. Si quiere leer, sólo tendrá que esperar si el elemento está
bloqueado para escritura. Se dice por tanto, que el bloqueo de lectura es compartido y el de escritura exclusivo.
Tendremos por tanto tres operaciones; bloquear_escritura(X), bloquear_lectura(X) y desbloquear(X).

1.3.3 Seriabilidad

Objetivo de un protocolo de control de concurrencia:


• Planificar las transacciones de forma que no ocurran interferencias entre ellas, y así evitar la
aparición de los problemas mencionados
Solución obvia: no permitir intercalación de operaciones de varias transacciones
• Pero el objetivo de un SGBD multiusuario también es maximizar el grado de concurrencia del sistema
• Si se permite la intercalación de operaciones, existen muchos órdenes posibles de ejecución de las
transacciones.

Ing. Gionella L. Araujo Transacciones y Control de la concurrencia Base de Datos II 7

Downloaded by Rodrigo Ortiz Fallas (rortiz@ucenfotec.ac.cr)


lOMoARcPSD|17230113

Planificación de las transacciones:


• Cada transacción comprende una secuencia de operaciones que incluyen acciones de lectura y escritura
en la BD, que finaliza con una confirmación (commit) o anulación (rollback)
• Una planificación P de n transacciones concurrentes T1, T2 ... Tn es una secuencia de las operaciones
realizadas por dichas transacciones, sujeta a la restricción de que
para cada transacción Ti que participa en P,
sus operaciones aparecen en P
en el mismo orden en el que ocurren en Ti

1.3.4 Interbloqueos
El interbloqueo se produce cuando cada transacción T en un conjunto de dos o más transacciones está
esperando a algún elemento que está bloqueado por alguna otra transacción T' de dicho conjunto. En este
estado, cada transacción está parada en espera a que otra transacción libere el recurso.

1.4 Otros métodos de control de concurrencia

1.4.1 El control de concurrencia optimista (en inglés Optimistic concurrency control o OCC) es un
método de control de concurrencia que se aplica a sistemas transaccionales, tales como sistemas de
gestión de bases de datos relacionales y memoria transaccional de software. El OCC asume que
múltiples transacciones se pueden completar frecuentemente sin interferir entre sí. Mientras se
ejecutan, las transacciones utilizan recursos de datos sin adquirir bloqueos en esos recursos. Antes de
hacer el commit, cada transacción verifica que ninguna otra transacción ha modificado los datos que ha
leído. Si la comprobación revela modificaciones en conflicto, la transacción que iba a hacer commit hace
un rollback y se puede reiniciar. El control de concurrencia optimista fue propuesto por primera vez por
H. T. Kung.

1.4.2 Control de concurrencia pesimista: Este método implementa cerraduras que impide que los usuarios
puedan alterar los datos de una manera que afecta a otros usuarios. Cuando un usuario realiza una acción en
una entidad que aplica un bloqueo en la entidad, otros usuarios no pueden llevar a cabo acciones en esa entidad
hasta que el propietario de la cerradura libera. El control pesimista se utiliza cuando existe una alta contención
para datos.

Ing. Gionella L. Araujo Transacciones y Control de la concurrencia Base de Datos II 8

Downloaded by Rodrigo Ortiz Fallas (rortiz@ucenfotec.ac.cr)


lOMoARcPSD|17230113

ANEXOS

Ing. Gionella L. Araujo Transacciones y Control de la concurrencia Base de Datos II 9

Downloaded by Rodrigo Ortiz Fallas (rortiz@ucenfotec.ac.cr)


lOMoARcPSD|17230113

Ing. Gionella L. Araujo Transacciones y Control de la concurrencia Base de Datos II 10

Downloaded by Rodrigo Ortiz Fallas (rortiz@ucenfotec.ac.cr)

También podría gustarte

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy