UNIVERSIDAD MARIANO GALVEZ, DE GUATEMALA

DOCENTE:
ING. IVAN DE LEON

CURSO:
BASE DE DATOS II

INGENIERIA EN SISTEMAS DE IFORMACION

ESTUDIANTES

NOMBRES NO. CARNÉ

Deisi Lisbeth Arreaga López 0903-14-13793
Willy Uriel de León Maldonado 0903-14-21077
Elías Abraham Mérida Bámaca 0903-13-3696
 INTRODUCCIÓN
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 a la vez
gracias a la multiprogramación: la computadora puede procesar al mismo
tiempo múltiples transacciones. Si el equipo tiene varias CPU, es posible
un procesamiento simultáneo (paralelo) de transacciones. Si sólo hay una
CPU, el SO de multiprogramación reparte el tiempo de CPU entre las
transacciones: ejecución concurrente intercalada.

PROPÓSITO
Estudiar los conceptos fundamentales de Base de Datos, para el análisis,
el diseño y la implementación de un Sistema de Base de Datos. Conocer
la forma en que los sistemas de BD implementan la concurrencia y las
formas de implementación para mantener la Base de Datos segura y la
integridad de los datos. Todo lo anterior, haciendo uso del lenguaje SQL.
 LECTURAS SUCIAS
Una lectura sucia ocurre cuando se le permite a una transacción la lectura de una
fila que ha sido modificada por otra transacción concurrente pero todavía no ha sido
cometida.
Las lecturas sucias funcionan de modo similar a las lecturas no repetibles; sin
embargo la segunda transacción no necesita ser cometida para que la primera dé
un resultado diferente. Lo único que se puede prevenir en el nivel de aislamiento
LECTURAS NO COMETIDAS es que las actualizaciones aparezcan en desorden
en el resultado; esto es, que las primeras actualizaciones siempre aparecerán antes
que las actualizaciones posteriores.
En el ejemplo, la transacción 2 cambia una fila, pero no comete los cambios. La
transacción 1 entonces lee los datos sin cometer. Si ahora la transacción 2 deshace
sus cambios (ya leídos por la transacción 1) o realiza otros cambios, entonces los
datos que ha recuperado la transacción 1 serán erróneos.
Transacción 1 Transacción 2

/* Query 1 */
SELECT edad FROM usuarios WHERE
id = 1;
/* leerá 20 */

/* Consulta 2 */
UPDATE usuarios SET edad = 21 WHERE id
= 1;
/* No se hace commit */

/* Query 1 */
SELECT edad FROM usuarios WHERE
id = 1;
/* leerá 21 */

ROLLBACK; /* LECTURA SUCIA basada en

bloqueo */

Pero no existe ningún usuario que tenga la edad de 21.

 LECTURAS NO REPETIBLE
Una lectura no repetible ocurre cuando en el curso de una transacción una fila se
lee dos veces y los valores no coinciden.
El efecto de lecturas no repetible puede ocurrir en una implementación de
concurrencia mediante bloqueos cuando no se efectúan éstos al hacer un SELECT,
o cuando los bloqueos se liberan nada más terminar la operación SELECT. Cuando
se usa el método MVCC, las lecturas no repetibles pueden aparecer cuando se
relaja el requisito de que al cometer una transacción afectada por un conflicto ésta
deba deshacerse.
Transacción 1 Transacción 2

/* Consulta 1 */
SELECT * FROM usuarios WHERE
id = 1;

/* Consulta 2 */
UPDATE usuarios SET edad = 21 WHERE
id = 1;
COMMIT; /* en MVCC o READ COMMITTED
basado en bloqueos */

/* Consulta 1 */
SELECT * FROM usuarios WHERE
id = 1;
COMMIT; /* REPEATABLE READ
basado en bloqueos */

En este ejemplo, la transacción 2 comete correctamente, lo que significa que sus

cambios a la fila con id 1 deberían hacerse visibles. Sin embargo, la transacción 1
ya ha leído un valor distinto para edad en esa fila. En los niveles de aislamiento
SERIALIZABLE y REPEATABLE READ, el SGBDR debería devolver el valor
antiguo. En los niveles READ COMMITTED y READ UNCOMMITTED, el SGBDR
debería devolver el valor nuevo; esto es una lectura no repetible.
Hay dos estrategias básicas para prevenir las lecturas no repetibles. La primera
consiste en retrasar la ejecución de la transacción 2 hasta que la transacción 1 haya
cometido o haya deshecho. Este método se usa con bloqueos, y es equivalente a
la ejecución en serie T1, T2. La ejecución en serie no muestra efectos de lecturas
no repetibles.
La otra estrategia, la usada en MVCC, se permite cometer a la transacción 2
primero, lo que permite mejor concurrencia. Si embargo, la transacción 1, que
comenzó antes que la transacción 2, debe continuar operando sobre una versión
anterior de la base de datos —una instantánea del momento en que empezó.
Cuando la transacción 1 intenta cometer, el SGBDR verifica si el resultado de
cometer la transacción 1 sería equivalente a la ejecución serie T1, T2. Si fuera así
la transacción 1 podría proceder. Si no fuera así, la transacción 1 fallaría y debería
deshacerse.
Usando control de concurencia mediante bloqueos, al nivel de aislamiento
REPEATABLE READ, la fila con id 1 debería bloquearse, bloqueando de ese modo
la consulta 2 hasta que la transacción 1 se cometa o deshaga. En el modo READ
COMMITTED, la segunda vez que se ejecute la consulta 1, la edad habrá cambiado.
Usando MVCC, al nivel de aislamiento SERIALIZABLE, ambas consultas SELECT
ven una instantánea de la base de datos tomada al comienzo de la transacción 1.
Por ello devuelven los mismo datos. Sin embargo, si la transacción 1 intenta
entonces actualizar esa misma fila, ocurriría un fallo de serialización y la transacción
1 estaría forzada a deshacerse.
Al nivel de aislamiento READ COMMITTED, cada consulta ve una instantánea de
la base de datos tomada al principio de la consulta. Por ello, cada una ve datos
distintos en la fila actualizada. No puede producirse fallo de serialización en este
modo (ya que no se hace promesa de serializabilidad), y la transacción 1 no deberá
reintentarse.
LECTURAS FANTASMA
Una lectura fantasma ocurre cuando, durante una transacción, se ejecutan dos
consultas idénticas, y los resultados de la segunda son iguales a de los de la
primera.
Esto puede ocurrir cuando no se realizan bloqueos de rango al realizar una
operación SELECT ... WHERE.
La anomalía de las lecturas fantasma es una caso particular de las lecturas no
repetibles cuando la transacción 1 repite una consulta acotada en rango SELECT ...
WHERE y, entre ambas operaciones la transacción 2 crea (i.e. INSERT) nuevas
filas (en la misma tabla) que entran dentro de esa cláusula WHERE.

Transacción 1 Transacción 2
 /* Consulta 1 */
SELECT * FROM usuarios
WHERE edad BETWEEN 10 AND
30;

/* Consulta 2 */
INSERT INTO usuarios VALUES ( 3, 'Mica',
27 );
COMMIT;

/* Consulta 1 */
SELECT * FROM usuarios
WHERE edad BETWEEN 10 AND
30;

Nótese que la transacción 1 ejecuta la misma consulta dos veces. Si se mantuviera

el mayor nivel de aislamiento, los resultados de ambas consultas coincidirían (QUE
ES LO QUE SUCEDE), de hecho es lo que se pide a una base de datos operando
al nivel de aislamiento SERIALIZABLE. Sin embargo, a niveles de aislamiento
menores, pueden obtenerse resultados distintos.
Al nivel de aislamiento SERIALIZABLE, la consulta 1 bloquearía todos los registros
con edades comprendidas entre 10 y 30, de modo que la consulta 2 quedaría
bloqueada hasta que se cometiera la transacción 1. En modo REPEATABLE READ,
el rango de 10 a 30 no se bloquearía, permitiendo la inserción de modo que la
segunda ejecución de la consulta 1 sí incluirá la nueva fila en sus resultados.
Niveles de aislamiento en Base de Datos

El aislamiento es una parte importante de la propiedad ACID que garantiza

que las transacciones sean fiables. Esto permite que las transacciones que se
ejecutan simultáneamente no interfieran con otras, garantizando la
integridad de los datos, al no existir aislamiento en una transacción podría
modificar los datos que otra transacción está leyendo, por lo que se crea una
inconsistencia cuando se crean datos.
Ahora que entendemos que es el aislamiento en términos generales, vamos a
conocer cuales son los niveles de aislamiento, estos determinan como las
transacciones se comportan con otras transacciones, es como ser más o
menos restrictivo. Escoger cual es el mejor nivel depende de las necesidades
de la aplicación, primero debe entender cuales son los beneficios y
consecuencias de cada una de ellas.
InnoDB soporta los cuatro niveles de aislamiento estándar, a continuación se
describen los estándares usados en muchos maneadores de bases de datos
relacionales, no solo se aplica para MySQL, sino para Oracle, SQL Server y
PostgreSQL.

 READ-UNCOMMITTED (LECTURA NO CONFIRMADA): La ejecución de

la instrucciones 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 trasacció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”.

 READ-COMMITTED (LECTURA CONFIRMADA): Está es la opción

favorita de Oracle y la que se recomienda para muchos casos. Con éste
nivel de aislamiento se evita el fenómeno de la lectura sucia, porque los
cambios no confirmados no son visibles para cualquier otra transacción,
hasta que se confirme el cambio. Dentro de este nivel de aislamiento, cada
SELECT utiliza su propia instantánea de los datos que se confirmo
(commit) antes de la ejecución de la instrucción SELECT. Ahora, ya que
cada SELECT tiene su propia instantánea, por lo que el mismo SELECT
cuando se ejecuta varias veces durante la misma transacción podría
regresar diferentes conjuntos de resultados. Este fenómeno se le
llama lectura no repetible.
 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: Con éste nivel de aislamiento se evita el fenómeno de

fantasma. Coloca un bloqueo de rango en el conjunto de datos, cuando las
transacciones se ejecuta en este nivel de aislamiento se bloquean todos los
registros y recursos que se tiene acceso, así bloquea todo cambio,
impidiendo que otros usuarios actualizar o insertar filas en el conjunto de
datos hasta que la transacción se ha completado. Este nivel de aislamiento
es el más fuerte posible.
Cada uno de estos niveles de aislamiento tienen sus beneficios y
consecuencias, vamos a explicar cada situación:

Se puede evitar el nivel de aislamiento SERIALIZABLE

Si, Como vemos es el más restrictivo sacrificando consistencia por
rendimiento, un nivel de aislamiento parecido es REPEATABLE-READ, tiene
una forma de bloqueo especial que ayuda a evitar los fenómenos fantasmas,
podemos asegurarnos de hacer un buen bloqueo sin fenómenos fantasmas
usando la estructura SELECT con FOR UPDATE o LOCK IN SHARE MODE. El
bloqueo compartido permite a otras transacciones leer los registros
examinados, pero no actualizar o borrar mientras que otra transacción esté
interviniendo.
Realicación y Niveles de aislamiento
El tipo de replicación predeterminada en MySQL es la replicación basada en
declaraciones [Statement Based Replication (SBR)], mantiene los cambios de
los datos por la re-ejecución de las sentencias SQL ejecutadas en el maestro a
los esclavos. Esto requiere que el nivel de aislamiento sea más estricto, de
modo que los cambios de datos deben ser consistentes, de tal manera que el
mismo SQL debe garantizar los mismos cambios en el esclavo. Cuando usamos
este tipo de replicación puedes configurar el nivel de aislamiento en
SERIALIZABLE o REPEATABLE-READ. Si usas la versión 5.1 o superior de
MySQL debes usar el nivel de aislamiento READ-COMMITTED para garantizar
la consistencia de datos.

Los niveles de rendimiento y aislamiento

Como hemos podido ver, mientras más bloqueos menos rendimiento y mayor
consistencia, la intención es buscar un equilibrio según nuestras necesidades,
ya que los extremos son perjudiciales. Usar el nivel de aislamiento
SERIALIZABLE no es para nada favorable a nivel de rendimiento, pero usar
READ-UNCOMMITTED mejora mucho el rendimiento pero no garantiza la
integridad de los datos, por lo que nos quedan las dos opciones del medio.
 CONCLUSIONES

Anteriormente una transacción era complicada de hacer ya que se

realizaba por medio manual, es decir haciendo transferencias de forma
real de una cuenta a otra.

Los niveles de aislamiento dependen del nivel que se esté trabajando

donde depende de la forma de importancia de cada situación que se nos
presenta.