Beruflich Dokumente
Kultur Dokumente
Parte 1
Iniciar phpmyadmin y crear una base de datos de prueba, con una tabla llamada
Cliente en los siguientes atributos id_cli, nom-cli y valor (clave principal, nombre del cliente
y valor arbitrario)
Parte 2
Parte 3
Teclear help para observar e identificar los comandos de mysql asi como su
descripción.
Parte 4 EL COMMIT
begin;
no debe haber sucedido nada en absoluto de lo contrario sucedio un autocommit por que
no se verifico el comando begin o sucedio un error inesperadosi todo sale bien y no hay
cambios hacemos commit
commit;
Hacemos la misma prueba desde el inicio on begin luego update pero esta vez con
el comando rollback
begin;
rollback;
o Begin;
o Savepoint uno;
o Savepoint dos;
o Savepoint tres;
o Commit / rollback;
El comando “release savepoint”, elimina el savepoint para ello hay que indicar
como se nombra por ejemplo.
Paso 1
Iniciamos ahora la práctica del aislamiento en las transacciones, es decir como sucede la
concurrencia en las transacciones y para eso necesitamos dos procesos o sesiones abiertas que
simularan como si fueran dos usuarios diferentes viendo la misma tabla de datos, la idea es saber
que cambios ve un usuario respecto del otro cuando se inicia una transacción simple.
paso 2
Iniciaremos dos terminales por defecto es decir sin invocar ningún tipo de aislamiento por defecto
mysql asume predeterminado como repeatable read nivel 3 para evitar los problemas de lecturas
no repetidas ...como estamos en mysql una lectura confirmada o read commited no debe verse la
tabla modificada por ninguno de los dos usuarios sino hasta después del commit.
2 Set transation isolation level read Set transation isolation level read
uncommitted; uncommitted;
3 Select * from table; Select * from table;
4 Update set where;
5 Select * from table;
6 Select * from table;
7 Commit; Rollback;
En el tiempo 3 ambos usuarios ven lo mismo, en el tiempo 5 el usuario 1 lee el cambio, en el
tiempo 6 el usuario 2 también lee el cambio se produce la anomalia(lectura sucia) antes del
commit/rollback de ambos.
Paso 4 Lectura confirmada en nivel 2 de concurrencia poco alta y aislamiento poco bajo
Lectura confirmada en nivel 2 de concurrencia poco alta y poco bajo aislamiento produce
el Problema de anomalía de lectura no repetible
tiempo Usuario 1 Usuario 2
1 Begin; Begin;
2 Set transation isolation level read Set transation isolation level read
committed; committed;
3 Select * from table; Select * from table;
4 Update set where;
5 Select * from table;
6 Select * from table;
7 Commit;
8 Select * from table;
9 Rollback;
En el tiempo 3 ambos leen la misma lectura pero en el tiempo 5 el usuario 1 lee el cambio y
en el tiempo 6 el usuario 2 no lee el cambio, sigue leyendo el anterior, en el tiempo 8 el
usuario 2 lee el cambio(lectura no repetible) después que el usuario 1 da el commit, el
problema es que el usuario 2 no ha dado commit y lee el cambio lo que es irregular.
Observación: en la versión nueva 2015-16 de MySql no suceden los problemas fantasmas con el
nivel 3 repeatable read o lectura repetible, sino que funciona como si fuese serializable, y
realmente no es serializable sino que mysql implemento un algoritmo llamado Next-Key Locking.
InnoDB implementa un bloqueo a nivel de fila estándar, donde hay dos tipos de bloqueos:
X IX S IS -
X N S S N S
IX S S S S S
S S S S S S
IS S S S S S
- S S S S S
Los deadlocks son un problema clásico de las bases de datos transaccionales, pero no son
peligrosos a menos que sean tan frecuentes que no se puedan ejecutar en absoluto ciertas
transacciones. Normalmente, las aplicaciones deben ser escritas de modo que estén
preparadas para emitir nuevamente una transacción si ésta es cancelada debido a un
deadlock.
InnoDB emplea bloqueos automáticos a nivel de fila. Se pueden producir deadlocks aún en
el caso de transacciones que solamente insertan o eliminan una fila individual. Esto se debe
a que estas operaciones no son realmente “atómicas”; sino que establecen automáticamente
bloqueos en los (posiblemente varios) registros de índice de la fila insertada o eliminada.
Con las siguientes técnicas se puede estar a cubierto de los deadlocks y reducir la
probabilidad de que ocurran:
Emplear SHOW ENGINE innodb STATUS para determinar la causa del último deadlock.
Puede ayudar a afinar la aplicación para evitar que ocurran otros.
Siempre hay que estar preparado para emitir nuevamente una transacción que haya fallado
por un deadlock. Los deadlocks no revisten peligro, simplemente hay que intentar de
nuevo.
Si se están usando lecturas que establecen bloqueos (SELECT ... FOR UPDATE o ...
LOCK IN SHARE MODE), hay que intentar utilizar un nivel de aislamiento bajo, como
READ COMMITTED.
Acceder a las tablas y filas en un orden fijo. Entonces, las transacciones forman secuencias
bien definidas y no originan deadlocks.
Agregar a las tablas índices adecuadamente elegidos. Entonces las consultas necesitarán
examinar menos registros de índice y en consecuencia establecerán menos bloqueos.
Utilizar EXPLAIN SELECT para determinar los índices que MySQL considera más
apropiados para las consultas.
Utilizar menos el bloqueo. Si es aceptable que SELECT devuelva datos de una captura de
la base de datos que no sea la más actualizada, no hay que agregarle las cláusulas FOR
UPDATE o LOCK IN SHARE MODE. En este caso es adecuado utilizar el nivel de
aislamiento READ COMMITTED, porque cada lectura consistente dentro de la misma
transacción leerá de su propia captura más reciente.
Si nada de esto ayuda, habrá que serializar las transacciones con bloqueos a nivel de tabla.
La forma correcta de emplear LOCK TABLES con tablas transaccionales, como InnoDB,
es establecer AUTOCOMMIT = 0 y no invocar a UNLOCK TABLES hasta que se haya
confirmado explícitamente la transacción. Por ejemplo, si se necesitara escribir en una tabla
t1 y leer desde una tabla t2, se puede hacer esto:
SET AUTOCOMMIT=0;
COMMIT;
UNLOCK TABLES;
Otra manera de serializar transacciones es crear una tabla “semáforo” auxiliar que contenga
sólo una fila. Hay que hacer que cada transacción actualice esa fila antes de acceder otras
tablas. De ese modo, todas las transacciones se producirán en serie. Nótese que el algoritmo
de detección instantánea de deadlocks de InnoDB también funciona en este caso, porque el
bloqueo de serialización es un bloqueo a nivel de fila. Con los bloqueos a nivel de tabla de
MySQL, debe emplearse el método de timeout para solucionar deadlocks.