CARRERA DE INGENIERÍA DE SISTEMAS

LABORATORIO DE BASE DE DATOS II

NÚMERO DE PRÁCTICA:
NOMBRE DE LA PRÁCTICA: Bloqueos y Administración de concurrencia.
1. DATOS INFORMATIVOS:
CARRERA: INGENIERÍA DE SISTEMAS
CICLO/NIVEL: 5TO SEMESTRE
FECHA:
DOCENTE RESPONSABLE: ING. MILTON VALAREZO
LABORATORIO: De Tecnología
ESTUDIANTES: Astudillo Marco – Romero Melanie

2. FUNDAMENTACIÓN

Transacciones
Una transacción es una unidad de programa que accede y posiblemente actualiza varios
elementos de datos a la vez, en PostgreSQL se pueden realizar transacciones utilizando
las siguientes instrucciones SQL:
Por lo tanto, es necesario manejar modelo de procesos concurrentes para admitir
operaciones concurrentes que preserven la integridad de los datos.

Partes de una transacción:

 BEGIN: Empieza la transacción
 SAVEPOINT [nombre]: Le dice al DBMS la localización de un punto de retorno en la
transacción si una parte de la transacción es cancelada.
 COMMIT: Todos los cambios realizados por las transacciones deben ser
permanentes y accesibles a las demás operaciones del DBMS.
 ROLLBACK [savepoint]: Aborta la actual transacción todos los cambios realizados
deben ser revertidos.

Estado de una transacción

 Active: Es el estado inicial y permanece durante toda la ejecución.
 Partially committed: Después de que se ha ejecutado el último statement.
 Failed: Después de algún error, no se puede continuar.
 Aborted: Se hace un "rollback" hacia un estado anterior consistente.
 Committed: Después del éxito

Las transacciones deben cumplir el criterio ACID

 CARRERA DE INGENIERÍA DE SISTEMAS

Propiedad Característica
Atomicity Todas las acciones en la transacción se cumplen o no se cumple
ninguna.

Consistency La transacción solo termina si la data es consistente.

Isolation La transacción es independiente de otras transacciones.

Durability Cuando la transacción termina el resultado de la

misma es perdurable.

Gestión de Concurrencia

El control de concurrencia es el que asegura que muchos usuarios puedan acceder a la data
al mismo tiempo. Al realizar procesos de transacciones se producen operaciones de R/W.
Ninguna transacción debe ver el resultado de otras transacciones inconclusas, si esto no
fuera así estaríamos leyendo datos inconsistentes.

El control de accesos concurrentes y específicamente de transacciones concurrentes en SQL

es manejado por un módulo del dbms llamado "scheduler".

MVCC (Multiversión Concurrencia Control) de PostgreSQL

PostgreSQL mantiene la consistencia de los datos con un modelo multiversión (MVCC). Esto
significa que mientras se consulta una base de datos, cada transacción ve una imagen de los
datos (una versión de la base de datos) como si fuera tiempo atrás, sin tener en cuenta el
estado actual de los datos que hay por debajo. Esto evita que la transacción vea datos
inconsistentes que pueden ser causados por la actualización de otra transacción
concurrente en la misma fila de datos, proporcionando aislamiento transaccional para cada
sesión de la base de datos.

Aislamiento de Transacción
El estándar SQL define cuatro niveles de aislamiento de transacciones. El más estricto es
serializable, que se define por el estándar en un párrafo que dice que cualquier ejecución
concurrente de un conjunto de transacciones Serializable está garantizada para producir el
mismo efecto que ejecutarlos uno a la vez en algún orden.

Niveles de aislamiento en Base de Datos

 CARRERA DE INGENIERÍA DE SISTEMAS

READ COMMITED
Nivel de aislamiento por defecto de PostgreSQL, donde las modificaciones de otras
transacciones se ven si se terminaron con COMMIT antes de comenzar la consulta. En caso
de intentar cambiar un dato que otra transacción está cambiando, la actual queda bloqueada
hasta saber si proceder con el cambio (en caso de rollback) o si volver a ejecutar la condición
de consulta del cambio para comprobar que las filas a cambiar aún la cumplen (en caso de
commit).

READ-UNCOMMITTED (LECTURA NO CONFIRMADA)

La ejecución de la instrucción SELECT se llevan a cabo sin bloqueo, puede utilizar una
versión antigua de una fila que ya no existe. Por lo tanto, el uso de este nivel no tiene
aislamiento y no garantiza la transacción, tales lecturas no son consistentes. Esto también
se le llama una lectura sucia. De lo contrario, este nivel de aislamiento funciona igual que
“READ COMMITTED”.

REPEATABLE-READ (LECTURA REPETIBLE)

Lee todos los datos de forma coherente dentro de la misma transacción, es como hacer una
foto instantánea de los datos desde la primera lectura. Con este nivel de aislamiento se evita
el fenómeno de la lectura no repetible. Este nivel de aislamiento devuelve el mismo conjunto
de resultados para diferentes SELECT dentro de una misma transacción. Una instantánea
de la SELECT se toma la primera vez que se ejecuta durante la transacción y la misma
instantánea se utiliza dentro de la transacción cada vez que se ejecuta el mismo SELECT.
Una transacción que se ejecuta en este nivel de aislamiento no tiene en cuenta los cambios
de los datos realizados por otras transacciones, independientemente de si los cambios se
han confirmado (commit) o no. Esto asegura que las lecturas siempre son consistentes
(repetible). Este nivel de aislamiento es el predeterminado para InnoDB. Aunque este nivel
de aislamiento resuelve el problema de lectura no repetible, pero hay otro fenómeno
fantasma.

SERIALIZABLE
Es la empleada por defecto en SQL estándar, solo se ven las modificaciones de otra
transacción que hayan sido aceptadas (COMMIT) al principio de la transacción actual.
PostgreSQL no tiene un nivel SERIALIZABLE real puesto que solo ve los datos que han sido
COMMIT antes de la primera consulta o modificación de datos.
 CARRERA DE INGENIERÍA DE SISTEMAS
Bloqueos en PostgreSQL

Bloqueo Explicito:
PostgreSQL provee varios métodos de bloqueo además de MVCC para situaciones donde
este no proporciona el comportamiento deseado.

Bloqueo a nivel de Tablas:

Estos son los tipos de bloqueo a nivel de tablas, son adquiridos de manera automática por
PostgreSQL o manual mediante el comando LOCK.

Bloqueo a nivel de Filas:

Los tipos de bloqueo a nivel de filas son SELECT FOR UPDATE para un bloqueo exclusivo y
SELECT FOR SHARE para un bloqueo compartido, pero que genera una solicitud de bloqueo
exclusivo cuando se intenta modificar la fila.

Advisory Locks:
Son bloqueos para fines específicos que no son usados normalmente por el sistema, existen
de sesión, que obtienen el bloqueo desde el inicio de la sesión hasta el final de esta y no se
desbloquea incluso con rollbacks, y de transacción, que se comporta más como los bloqueos
normales, se liberan automáticamente al final de la transacción, si hay un bloqueo de sesión
sobre un recurso, no puede haber uno de transacción, y viceversa.

3. OBJETIVOS:
Administrar la ejecución de transacciones sobre una base de datos PostgreSQL,
garantizando que todas las consultas no violen la regla ACID, además la implementación
y comprobación de los diferentes tipos de bloqueos.

4. MATERIALES E INSUMOS
- 1 Computadoras de escritorio por equipo de trabajo
- Equipos instalados con el DBMS PostgreSQL
- Internet

5. PROCEDIMIENTO
Para poder aplicar los conceptos descritos en este laboratorio es necesario tener una
base de datos en la cual aplicar las restricciones que requiere el proyecto de trabajo.

1. Se utilizará una base de datos para una empresa de venta de productos para el
hogar, cuyo modelo Relacional se encuentra en el Anexo No. 1. Esta base de datos
debe ser implementada en PostgreSQL, para lo cual pueden ejecutar los scripts
 CARRERA DE INGENIERÍA DE SISTEMAS
proporcionados para crear la base de datos necesaria, y además llenarla, el script se
denomina scripts.sql.

2. Comprobar las 4 propiedades de una transacción, use de la tabla clientes de la base

de datos, PEDIDOS.
A. Atomicidad
B. Consistencia
C. Aislamiento
D. Durabilidad
3. Comprobar el funcionamiento del Control de Concurrencia Multiversión, probarlo
en la tabla “Productos” que indica todo lo relacionado con la venta de productos,
utilizar el usuario Administrador y secretaria en dos sesiones diferentes.

El proceso sería:
o sesión 1: iniciamos una transacción, vemos los datos que hay,
actualizamos los datos de la tabla productos (aumentaremos el stock
+300) y no confirmamos la transacción.
o b. sesión 2: iniciamos la transacción y consultamos la información de
productos.
o c. sesión 2: iniciar una transacción e intentar sumar 100 a la
cantidad.
o d. sesión 1: confirmamos los cambios y vemos qué pasa con los datos
vistos desde esta sesión y luego vamos a ver los datos vistos desde
la sesión 2.
o e. sesión 2: confirmamos los cambios

4. Comprobar el funcionamiento del bloqueo Explicito, en la tabla productos.

5. Comprobar si el nivel de aislamiento READ UNCOMMITTED es posible ejecutarlo en
PostgreSQL, utilizar la tabla productos, usar dos sesiones con diferentes usuarios.

6. CUADROS DE RESULTADOS
Se espera que los estudiantes puedan administrar transacciones a la base de datos,
utilizando las herramientas que proporciona el DBMS PostgreSQL. La evidencia son
capturas de pantalla con los resultados y las explicaciones de dichos resultados.

1
 CARRERA DE INGENIERÍA DE SISTEMAS

2 ATOMICIDAD:
Para probar la propiedad de atomicidad se escribió erróneamente la tercera
sentencia dentro de un bloque de transacción BEGIN-COMMIT
 CARRERA DE INGENIERÍA DE SISTEMAS

Se comprueba que no se concretó ninguna sentencia, por ejemplo la insert:

CONSISTENCIA:
Si se ingresa correctamente:

AISLAMIENTO:
La transacción queda pendiente y no se muestra hasta realizar el commit
 CARRERA DE INGENIERÍA DE SISTEMAS

Usando commit para concretar la transacción

 CARRERA DE INGENIERÍA DE SISTEMAS

DURABILIDAD:
Todas las transacciones concretadas se mantienen:

3 Sesión 1: iniciamos una transacción, vemos los datos que hay, actualizamos los
datos de la tabla productos (aumentaremos el stock +300) y no confirmamos
la transacción.
 CARRERA DE INGENIERÍA DE SISTEMAS

Sesión 2: iniciamos la transacción y consultamos la información de productos.

Sesión 3: iniciar una transacción e intentar sumar 100 a la cantidad.

Sesión 1: confirmamos los cambios y vemos qué pasa con los datos vistos
desde esta sesión y luego vamos a ver los datos vistos desde la sesión 2.
 CARRERA DE INGENIERÍA DE SISTEMAS

sesión 2: confirmamos los cambios

4
 CARRERA DE INGENIERÍA DE SISTEMAS
5

7. CONCLUSIONES

RECOMENDACIONES

Realizar recomendaciones para llevar a cabo una buena administración del control de
concurrencia.