Base de datos Avanzadas

Actividad N° 6

Alumno: Felipe Castro

Profesor: Juan Ricardo Giadach.
Fecha: 14/11/2021.
Indice

Apartado 1……………………………………………………………. Página 4

Apartado 2……………………………………………………………. Página 7
Apartado 3……………………………………………………………. Página 10
Apartado 4……………………………………………………………. Página 14
Apartado 5……………………………………………………………. Página 18
Apartado 6……………………………………………………………. Página 23
Apartado 7……………………………………………………………. Página 27
Desarrollo

En primer lugar, se debe crear la tabla “DATOS”, la cual tendrá 2 atributos, que serán los
siguientes:
➢ Codigo numeric(2).
➢ Nombre carácter(10).

Figura 1: Tabla “DATOS” con sus atributos.

Luego, se deben almacenar en la columna “numeric”, números del 1 al 10 y en la columna

“nombre” nombres aleatorios.
La tabla “DATOS” finalmente tendrá esta estructura.

Figura 2: Datos de la tabla “DATOS”.

Una vez creada la tabla “DATOS” y almacenado en ella todos los datos requeridos, se
procede con el primer pase de la experiencia.

1. Se debe tener 2 consolas abiertas (C1 y C2) y conectadas a la base de datos

“ACTIVIDAD6”. Ambas consolas deben estar visibles en todo momento a fin de
observar simultáneamente lo que está ocurriendo en ellas.

1.1. En C1, actualizamos el “NOMBRE” de la fila de “CODIGO” 5. Para ello

utilizamos el siguiente comando:

Figura 3: Actualización de ”NOMBRE”.

1.2. En C2, actualizamos el “NOMBRE” de la fila de “CODIGO” 5, pero a un

nombre diferente al anterior.

Figura 4: Actualización de ”NOMBRE”.

 Figura 4.1: Tabla “DATOS” luego del UPDATE.

1.3. En C1, consultamos el “NOMBRE” de la fila de “CODIGO” 5.

Figura 5: Consultamos en C1 el “NOMBRE” de la fila de “CODIGO” 5.

1.4. En C2, consultamos el “NOMBRE” de la fila de “CODIGO” 5.

 Figura 6: Consultamos en C2 el “NOMBRE” de la fila de “CODIGO” 5.

Análisis

Al realizar el primer UPDATE en C1, podemos apreciar un tiempo de respuesta de

33.561ms y al realizar el segundo UPDATE en C2 podemos apreciar un tiempo de
respuesta de 19.397ms.
Esta diferencia de 14.164 ms es porque en el primer UPDATE, se trae a la memoria la fila a
actualizar, y lo hace a medida que va recorriendo la tabla, además se trae el bloque donde
está la fila involucrada. En el bloque se marca como eliminado la fila que será actualizada y
se devuelve ese bloque al almacenamiento. Luego se actualiza la fila, se pide el ultimo
bloque de la tabla o uno nuevo si no hay espacio, se agrega la fila actualizada a ese bloque
y se graba en el almacenamiento.
Pero debido a que ya ocurrió una actualización previa a la misma fila, el sistema de base de
datos no tiene que buscar la fila a actualizar una por una, debido a que en su memoria
guardó el lugar en que se insertó la fila actualizada.
2.1 A continuación, en C1, se procede a abrir una transacción “BEGIN”, para luego
actualizar el “NOMBRE” de la fila de “CODIGO” 3 y consultar el “NOMBRE” de
la fila de “CODIGO” 3.

Figura 7: Transacción “BEGIN”.

Figura 8: Actualización.

Figura 9: Consulta.

2.2. Ahora, en C2, abrimos una transacción “BEGIN” y consultamos en “NOMBRE” de

la fila de “CODIGO” 3.

Figura 10: Transacción “BEGIN”.

 Figura 11: Consulta.

2.3. A continuación en C1, se procede a cerrar la transacción con “COMMIT”.

Figura12: Cierre de transacción.

2.4. Por último, en C2, volvemos a consultar el “NOMBRE” de la fila de

“CODIGO” 3 y cerrar la transacción con “COMMIT”.

Figura 13: Consulta

 Figura 14: Cierre de transacción.

Análisis

Para entender este procedimiento, debemos entender que es la instrucción “BEGIN” y

“COMMIT”.
Se utiliza el comando “BEGIN”, para dejar sin efecto permanente cualquier cambio que se
le realice a la base de datos.
Se utiliza el comando “COMMIT” para confirmar como permanentes las modificaciones
realizadas en una transacción.

Al realizar la transacción BEGIN y luego UPDATE en C1, este cambio no afecta de

manera permanente a la base de datos, es por ello que, en C2, al realizar la transacción
BEGIN y consultar por el NOMBRE de CODIGO 3, no se puede apreciar dicho cambio.
Ahora, cuando utilizamos la instrucción COMMIT en C1, aplicamos los cambios de
manera permanente a la base de datos durante la instrucción BEGIN.
Es por ello que cuando consultamos en C2, por el NOMBRE de CODIGO 3, ahora si nos
muestra el NOMBRE actualizado.
Para avanzar en el siguiente punto, debemos conocer la transacción COMMIT.

Primeramente usamos la transacción BEGIN, el cual deja sin efectos permanentes los
cambios que se le realicen a la base de datos, ahora bien, si queremos efectuar ese cambios,
cerramos la transacción mediante el comando COMMIT, el cual efectua los cambios
realizados a la base de datos.
Con esto presente, podemos continuar.

3.1. En C1, abrimos una transacción BEGIN y actualizamos en NOMBRE de la fila de

CODIGO 7.

Figura 15: Transacción BEGIN.

Figura 16: UPDATE fila CODIGO 7.

3.2. En C2, abrimos una transacción BEGIN y actualizamos el NOMBRE de la fila de

CODIGO 7 a un NOMBRE diferente.
 Figura 17: Transacción BEGIN.

Figura 18: Actualización.

3.3. En C1, volvemos a actualizar el NOMBRE de la fila de CODIGO 7 a un NOMBRE

diferente a los anteriores y finalmente cerramos la transacción con COMMIT.

Figura 19: Actualización.

Figura 20: Instrucción COMMIT en C1.

 Figura 21: Actualización en C2, luego de realizado el COMMIT en C1.

El UPDATE en C2, se hizo efectivo una vez realizado el COMMIT en C1, es por ello
que el tiempo de ejecución demoró 3 minutos y 58 segundos.

3.4. Ahora en C2, procedemos a cerrar la transacción mediante el comando COMMIT.

Figura 22: COMMIT en C2.

3.5. En C1, ahora procedemos a consultar el NOMBRE de la fila de CODIGO 7.

Figura 23: Consulta en C1.

3.6. Análogamente, repetimos el proceso de consultar el NOMBRE de la fila de CODIGO
7, pero esta vez en C2.

Figura 24: Consulta en C2.

Análisis

Durante la ejecución de los comandos, se puede apreciar algo que llama fuertemente la
atención, y es que después de realizado el BEGIN enC1, y realizar el UPDATE en el
NOMBRE de CODIGO 7. En C2, se realiza un BEGIN y luego el UPDATE en el
NOMBRE de CODIGO 7, este comando no se ejecuta, es decir, no se realiza la
actualización en C2 dentro del comando BEGIN.

Esto es debido a una propiedad llamada “Concurrencia”. La cual dice que, el control de
transacciones concurrentes en una base permite controlar la ejecución de transacciones que
operan en paralelo, accediendo a información compartida y, por lo tanto, interfiriendo
potencialmente unas con otras.

Esto quiere decir, que una ejecución no se puede llevar a cabo, si hay otra ejecución en
paralelo que aún no ha terminado.

Esto es muy eficiente en un caso real. Por ejemplo:

En una Base de Datos bancaria podría ocurrir que se paguen dos cheques en forma
simultánea sobre una cuenta que no tiene saldo suficiente para cubrirlos en su totalidad,
esto es posible evitarlo si se tiene un control de concurrencia.
4.1. Ahora, en C1, abrimos una transacción BEGIN y actualizamos en NOMBRE de la fila
de CODIGO 4.

Figura 25: Transacción BEGIN.

Figura 26: Actualización.

4.2 . Seguidamente, en C2 abrimos una transacción BEGIN y actualizamos en NOMBRE

de la fila de CODIGO 6.

Figura 27: Transacción BEGIN.

 Figura 28: Actualización.

4.3 Ahora, en C1, consultamos por el NOMBRE de la fila de CODIGO 6.

Figura 29: Consulta.

4.4 Seguido a eso, ahora en C2, consultamos por el NOMBRE de la fila de CODIGO 4.

Figura 30: Consulta

4.5 Ahora en C1, cerramos la transacción con COMMIT.

Figura 31: Cierre transacción COMMIT

4.6 Análogamente, en C2, cerramos la transacción con COMMIT.

Figura 32: Cierre transacción COMMIT

4.7 Ahora, en C1, consultamos por el NOMBRE de la fila de CODIGO 6.

 Figura 33: Consulta

4.8 Ahora en C2, consultamos por el NOMBRE de la fila de CODIGO 4.

Figura 34: Consulta

Análisis

Primeramente, en C1, al realizar un BEGIN seguido de un UPDATE del NOMBRE en la

fila de CODIGO 4. La consulta en C1, por el NOMBRE de la fila de CODIGO 6, seguirá
siendo “Sebastián”, puesto que no se ha actualizado.
Segundo, en C2, al realizar un BEGIN seguido de un UPDATE del NOMBRE en la fila de
CODIGO 6. La consulta en C2, por el NOMBRE de la fila de CODIGO 4, seguirá siendo
“Andrés”, puesto que se ha actualizado en C1, pero con un BEGIN, y esto deja sin efecto
permanente los cambios realizados a la base de datos.
Por ultimo se realiza un COMMIT en C1 y en C2.
En C1, al consultar por el NOMBRE de fila de CODIGO 6, ahora el resultado si será
“UPDATE_6”, puesto que mediante el comando COMMIT, se efectúan los cambios
realizados a la base de datos.
De manera análoga ocurre en C2, al consultar por el NOMBRE de fila de CODIGO 4,
ahora el resultado si será “UPDATE_4”, puesto que mediante el comando COMMIT, se
efectúan los cambios realizados a la base de datos.
5.1. En C1, abrimos una transacción BEGIN y actualizamos en NOMBRE de la fila de
CODIGO 2.

Figura 35: Transacción BEGIN.

Figura 36: Actualización.

5.2. En C2, abrimos una transacción BEGIN y actualizamos el NOMBRE de la fila de

CODIGO 8.

Figura 35: Transacción BEGIN.

Figura 36: Actualización.

5.3. En C1, actualizamos el NOMBRE de la fila CODIGO 8 a un NOMBRE diferente a los
anteriores.

Figura 37: Actualización incompleta.

5.4. En C2, actualizamos el NOMBRE de la fila CODIGO 2 a un NOMBRE diferente a los

anteriores.

Figura 38: Actualización errónea.

5.5. En C1, cerramos la transacción con un COMMIT.

Figura 39: Cierre transacción COMMIT.

5.6. En C2, cerramos la transacción con un COMMIT.

Figura 40: Cierre transacción COMMIT.

5.7. En C1, consultamos por el NOMBRE de la fila de CODIGO 8.

Figura 41: Consulta.

5.8. En C2, consultamos por el NOMBRE de la fila de CODIGO 2.

Figura 42: Consulta.

Análisis

Lo más importante de este proceso, es la aparición del error denominado “deadlock”, pero
¿Qué es este error, de que se trata, por qué aparece?

El “deadlock” para ejemplificarlo en un caso de la vida real, se vería como la siguiente

imagen.

Figura 43: Ejemplo “deadlock”.

El “deadlock”, sucede cuando dos o más transacciones intentan hacer actualizaciones o

cambios en alguna fila de la tabla en orden opuesto, como lo sucedido anteriormente.

Si ambas consultas se ejecutan al mismo tiempo, la consulta 1, bloqueará la actualización 1

y la consulta 2 bloqueará la actualización 2, y cada consulta esperará a que la otra libere la
actualización, ocurriendo el “deadlock”.
Ejemplo de proceso para que ocurra un “deadlock”:
Consulta 1:
BEGIN => UPDATE datos SET nombre = ‘UPDATE_2’ WHERE codigo =2;
Seguido de:
BEGIN => UPDATE datos SET nombre = ‘UPDATE_8’ WHERE codigo =8;

Consulta 2:
BEGIN => UPDATE datos SET nombre = ‘UPDATE_8_1’ WHERE codigo =8;
Seguido de:
BEGIN => UPDATE datos SET nombre = ‘UPDATE_2_1’ WHERE codigo =2;

Para evitar este “deadlock” y que los cambios ocurran, el orden de las consultas debería ser
el siguiente:

Consulta 1:
BEGIN => UPDATE datos SET nombre = ‘UPDATE_2’ WHERE codigo =2;
Seguido de:
BEGIN => UPDATE datos SET nombre = ‘UPDATE_2_1’ WHERE codigo =2;

Consulta 2:
BEGIN => UPDATE datos SET nombre = ‘UPDATE_8’ WHERE codigo =8;
Seguido de:
BEGIN => UPDATE datos SET nombre = ‘UPDATE_8_1’ WHERE codigo =8;
6.1. En C1, abrimos una transacción BEGIN y actualizamos en NOMBRE de la fila de
CODIGO 1.

Figura 44: Transacción BEGIN.

Figura 45: Actualización.

6.2. En C2, abrimos una transacción BEGIN y actualizamos el NOMBRE de la fila de

CODIGO 1 a un NOMBRE diferente.

Figura 44: Transacción BEGIN

 Figura 45: Actualización en espera.

6.3. En C1, actualizamos el NOMBRE de la fila de CODIGO 9 a un NOMBRE diferente a

los anteriores.

Figura 46: Actualización.

6.4 En C2, actualizamos el NOMBRE de la fila de CODIGO 9 a un NOMBRE diferente a

los anteriores.

No se puede realizar la actualización debido que hay una “concurrencia”, esto quiere decir,
que la ejecución no se puede llevar a cabo, si hay otra ejecución que aún no ha terminado.
Dicho esto, procederemos al siguiente paso.

6.5 En C1, cerramos la transacción con COMMIT.

Figura 47: Cierre transacción COMMIT.

Una vez ingresado el comando COMMIT la base de datos no lo procesa y arroja un

ROLLBACK, el cual, deja sin efecto los cambios realizados durante la transacción BEGIN.
Ahora, es cuando en C2, se actualiza el NOMBRE de la fila de CODIGO 1.
Aclaración: El tiempo tardado, solo corresponde a la demora en ingresar el comando
COMMIT en C1.

Figura 48: Actualización efectiva.

6.6 En C1, cerramos la transacción con COMMIT.

Figura 49: Cierre transacción COMMIT.

Análisis

En el presente desarrollo, se pretendía actualizar en la primera consulta de C2 el NOMBRE

de fila de CODIGO 1, pero esta acción no se pudo llevar a cabo inmediatamente debido a la
presencia de “concurrencia”.
Esto es porque hay otra ejecución que aún no ha terminado en C1, la cual es la siguiente:
C1 => BEGIN => UPDATE datos SET nombre = ‘UPDATE_1’ WHERE codigo = 1;
Pero una vez finalizada la transacción mediate el comando COMMIT en C1, es que ahora si
se puede actualizar el NOMBRE de la fila de CODIGO 1.
Como si de liberar un embotellamiento se tratase.
Para continuar con el último apartado de la experiencia, debemos conocer lo que es:
“SELECT … FOR UPDATE”
A veces, las aplicaciones leen datos de la base de datos, procesan los datos y guardan el
resultado en la base de datos. Este es un ejemplo clásico en el que “SELECT … FOR
UPDATE”, puede proporcionar seguridad adicional.
Ya que, si otro usuario desea cambiar algún dato de la FILA en cuestión, no podrá
realizarlo, hasta que se finalice la transacción, ya sea mediante el comando COMMIT o
ROLLBACK.
7.1 En C1, abrimos una transacción BEGIN y consultamos por el NOMBRE de la fila de
CODIGO 10 mediante la opción de actualización.

Figura 50: Transacción BEGIN.

Figura 51: Consulta.

7.2 En C2, sin utilizar la transacción BEGIN y sin utilizar el comando “FOR … UPDATE”,
consultamos por el NOMBRE de la fila de CODIGO 10 y lo actualizamos a un NOMBRE
diferente.

Figura 52: Consulta.

 Figura 53: Actualización en espera.

7.3 En C1, consultamos por el NOMBRE de la fila de CODIGO 10, sin utilizar el comando
“FOR … UPDATE”, y lo actualizamos a un NOMBRE diferente a los anteriores.

Figura 54: Consulta.

Figura 55: Actualización.

7.4 En C2, consultamos sin utilizar el comando “FOR … UPDATE”, por el NOMBRE de
la fila de CODIGO 10.

Figura 56: Actualización en espera.

7.5 En C1, cerramos la transacción con COMMIT.

Figura 57: Cierre transacción COMMIT.

7.6 En C1, consultar sin utilizar el comando “FOR … UPDATE”, por el NOMBRE de la
fila de CODIGO 10.

Figura 58: Consulta.

7.7 En C2, consultar sin utilizar el comando “FOR … UPDATE”, por el NOMBRE de la
fila de CODIGO 10.

Figura 59: Consulta.

Análisis

En esta experiencia se esperaba que se pudieran actualizar el NOMBRE de CODIGO 10,

sin inconvenientes, pero al utilizar el comando SELECT… FOR UPDATE, este protege a
la base de datos si otro usuario desea cambiar algún elemento de la base de datos, mientras
esta este siendo ocupada, solo hasta que la transacción esté finalizada.
Es por eso que, luego del siguiente comando en C1:
C1 => BEGIN => SELECT nombre FROM datos WHERE codigo = 10 FOR UPDATE;

Al realizar el siguiente comando:

C2 => UPDATE datos SET nombre = ‘UPDATE_10’ WHERE codigo = 10;

No se efectúa la actualización, porque el comando SELECT… FOR UPDATE lo impide.

Y dicha actualización solo se llevó acabo, después de utilizar el comando COMMIT en C1.