ıllı Internet y Tecnologías de la Información (2018)

internet, Hosting, dominios, seo, antivirus, banco de imágenes, páginas web, tiendas online

[Enciclopedia Online Gratuita] Diccionario de Internet y Tecnologías de la Información y la Comunicación (TIC):

ıllı Aislamiento (ACID) wiki: info, historia y vídeos

videos internet

salud  Aislamiento (ACID) 


De las 4 propiedades ACID de un Sistema de administración de bases de datos relacionales (SGBDR) la de aislamiento es la que más a menudo se relaja. Para conseguir el mayor nivel de aislamiento, un SGBDR por norma general hace un bloqueo de los datos o bien incorpora un Control de concurrencia a través de versiones múltiples (MVCC), lo que puede resultar en una pérdida de concurrencia. Por este motivo se precisa agregar lógica auxiliar al programa que accede a los datos para su funcionamiento adecuado.


La mayor una parte de los SGBDR ofrecen unos determinados niveles de aislamiento que controlan el grado de bloqueo a lo largo del acceso a los datos. Para la mayoría de aplicaciones, el acceso a los datos se puede efectuar de forma que se eviten altos niveles de aislamiento (i.e. nivel SERIALIZABLE), reduciendo de esta forma la sobrecarga debida a la necesidad de bloqueos por el sistema. El programador debe examinar pausadamente el código que accede a la base de datos para cerciorarse de que el descenso del nivel de aislamiento que ofrece el SGBD no genera fallos en el programa. Recíprocamente, si se utilizan altos niveles de aislamiento la posibilidad de bloqueo aumenta, lo que asimismo requiere análisis cauteloso del código.


Los niveles de aislamiento están definidos por ANSI/ISOSQL, y se alistan ahora.


Este es el nivel de aislamiento más alto. Detalla que todas y cada una de las transacciones ocurran de modo apartado, o bien dicho de otra forma, tal y como si todas y cada una de las transacciones se ejecutasen de modo serie (una tras otra). La sensación de ejecución simultánea de 2 o bien más transacciones que perciben los usuarios sería una ilusión producida por el SGBD.


Si el SGBDR hace una implementación basada en bloqueos, la serialización requiere que los bloques de lectura y escritura se liberen al final de la transacción. De igual forma deben efectuarse bloqueos de rango -sobre los datos elegidos con SELECT utilizando WHERE- para eludir el efecto de las lecturas espectro (ver más abajo).


Cuando se hace una implementación no basada en bloqueos, si el SGBDR advierte una colisión de escritura entre transacciones solo a una de ellas se le autoriza cometer.


Lecturas repetibles (Repeatable reads)


En este nivel de aislamiento, un SGBDR que implemente el control de concurrencia basado en bloqueos sostiene los bloqueos de lectura y escritura -de los datos elegidos- hasta el final de la transacción. No obstante, no se administran los bloqueos de rango, con lo que las lecturas espectro pueden acontecer (ver más abajo).


Lecturas cometidas (Read committed)


En este nivel de aislamiento, un SGBDR que implemente el control de concurrencia basado en bloqueos sostiene los bloqueos de escritura -de los datos elegidos- hasta el final de la transacción, al paso que los bloqueos de lectura se anulan tan pronto como termina la operación de SELECT (con lo que el efecto de las lecturas no repetibles puede suceder, como se explica más abajo). Al igual ocurría en el nivel precedente, no se administran los bloqueos de rango.


Lecturas no cometidas (Read uncommitted)


Este es el menor nivel de aislamiento. En él se dejan las lecturas sucias (ver más abajo), con lo que una transacción puede ver cambios no cometidos todavía por otra transacción.


El estándar ANSI/ISO SQL noventa y dos se refiere a 3 efectos de lectura diferentes cuando la transacción 1 lee datos que podría haber alterado la transacción dos.


En los próximos ejemplos se ejecutan 2 transacciones. La primera ejecuta la consulta 1. Entonces una segunda transacción ejecuta la consulta dos y la comete. Para finalizar, la primera transacción ejecuta la consulta 1 nuevamente.


Las consultas utilizan esta tabla:

usuariosidnombreedad1José202Juana25

Lecturas sucias


Una lectura sucia ocurre cuando se le deja a una transacción la lectura de una fila que ha sido cambiada por otra transacción concurrente mas aún no ha sido cometida.


Las lecturas sucias marchan de modo afín a las lecturas no repetibles; no obstante la segunda transacción no precisa ser cometida a fin de 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 y en toda circunstancia aparecerán ya antes que las actualizaciones siguientes.


En el ejemplo, la transacción dos cambia una fila, mas no comete los cambios. La transacción 1 entonces lee los datos sin cometer. Si ahora la transacción dos deshace sus cambios (ya leídos por la transacción 1) o bien efectúa otros cambios, entonces los datos que ha recuperado la transacción 1 van a ser equivocados.

Transacción 1Transacción 2
/* Query 1 */SELECTedadFROMusuariosWHEREid=1;/* va a leer veinte */
/* Consulta dos */UPDATEusuariosSETedad=21WHEREid=1;/* No se hace commit */
/* Query 1 */SELECTedadFROMusuariosWHEREid=1;/* va a leer veintiuno */
ROLLBACK;/* LECTURA SUCIA basada en bloqueo */

Pero no hay ningún usuario que tenga la edad de veintiuno, puesto que la Transacción dos jamás cometió los cambios.


Lecturas no repetibles


Una lectura no repetible ocurre cuando en el curso de una transacción una fila se lee un par de veces y los valores no coinciden.


El efecto de lecturas no repetible puede acontecer en una implementación de concurrencia a través de bloqueos cuando no se realizan estos al hacer un SELECT, o bien cuando los bloqueos se liberan solamente concluir la operación SELECT. Cuando se emplea el procedimiento MVCC, las lecturas no repetibles pueden aparecer cuando se relaja el requisito de que al cometer una transacción perjudicada por un enfrentamiento esta deba deshacerse.

Transacción 1Transacción 2
/* Consulta 1 */SELECT*FROMusuariosWHEREid=1;
/* Consulta dos */UPDATEusuariosSETedad=21WHEREid=1;COMMIT;/* en MVCC o bien READ COMMITTED basado en bloqueos */
/* Consulta 1 */SELECT*FROMusuariosWHEREid=1;COMMIT;/* REPEATABLE READ basado en bloqueos */

En este caso de ejemplo, la transacción dos comete adecuadamente, lo que quiere decir que sus cambios a la fila con id 1 deberían hacerse perceptibles.No obstante, la transacción 1 ya ha leído un valor diferente para edad en esa fila. En los niveles de aislamiento SERIALIZABLE y REPEATABLE READ, el SGBDR debería devolver el valor viejo. En los niveles READ COMMITTED y READ UNCOMMITTED, el SGBDR debería devolver el valor nuevo; esto es una lectura no repetible.


Hay 2 estrategias básicas para prevenir las lecturas no repetibles. La primera consiste en retrasar la ejecución de la transacción dos hasta el momento en que la transacción 1 haya cometido o bien haya deshecho. Este procedimiento se utiliza 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 utilizada en MVCC, se deja cometer a la transacción dos primero, lo que deja mejor concurrencia. Si embargo, la transacción 1, que empezó ya antes que la transacción dos, debe proseguir operando sobre una versión precedente de la base de datos —una instantánea del instante en que comenzó. Cuando la transacción 1 procura cometer, el SGBDR comprueba si el resultado de cometer la transacción 1 sería equivalente a la ejecución serie T1, T2. Si fuera de esta forma la transacción 1 podría proceder. Si no fuese de este modo, la transacción 1 fallaría y debería deshacerse.


Usando control de concurencia a través de bloqueos, al nivel de aislamiento REPEATABLE READ, la fila con id 1 debería bloquearse, bloqueando de esa manera la consulta dos hasta el momento en que la transacción 1 se cometa o bien deshaga. En el modo perfecto READ COMMITTED, la segunda vez que se ejecute la consulta 1, la edad va a haber alterado.


Usando MVCC, al nivel de aislamiento SERIALIZABLE, las dos consultas SELECT ven una instantánea de la base de datos tomada al principio de la transacción 1. Por esta razón devuelven los mismo datos. No obstante, si la transacción 1 procura entonces actualizar esa 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 comienzo de la consulta. Por esta razón, cada una ve datos diferentes en la fila actualizada. No puede generarse fallo de serialización en este modo (en tanto que no se hace promesa de serializabilidad), y la transacción 1 no va a deber reintentarse.


Lecturas fantasma


Una lectura espectro ocurre cuando, a lo largo de una transacción, se ejecutan 2 consultas idénticas, y los resultados de la segunda no son iguales a de los de la primera.


Esto puede acontecer cuando no se efectúan bloqueos de rango al efectuar una operación SELECT ... WHERE.


La anomalía de las lecturas espectro es una caso en particular de las lecturas no repetibles cuando la transacción 1 repite una consulta delimitada en rango SELECT ... WHERE y, entre las dos operaciones la transacción dos crea (i.e. INSERT) nuevas filas (en exactamente la misma tabla) que entran en esa cláusula WHERE.

Transacción 1Transacción 2
/* Consulta 1 */SELECT*FROMusuariosWHEREedadBETWEEN10AND30;
/* Consulta dos */INSERTINTOusuariosVALUES(tres,'Mica',27);COMMIT;
/* Consulta 1 */SELECT*FROMusuariosWHEREedadBETWEEN10AND30;

Nótese que la transacción 1 ejecuta exactamente la misma consulta un par de veces. Si se sostuviera el mayor nivel de aislamiento, los resultados de las dos consultas coincidirían (QUE ES LO QUE SUCEDE), en verdad es lo que se solicita a una base de datos operando al nivel de aislamiento SERIALIZABLE. No obstante, a niveles de aislamiento menores, pueden conseguirse resultados diferentes.


Al nivel de aislamiento SERIALIZABLE, la consulta 1 bloquearía todos y cada uno de los registros con edades comprendidas entre diez y treinta, de tal modo que la consulta dos quedaría bloqueada hasta el momento en que se cometiese la transacción 1. En modo REPEATABLE READ, el rango de diez a treinta no se bloquearía, dejando la inserción de forma que la segunda ejecución de la consulta 1 sí incluirá la nueva fila en sus resultados.


  ELIGE TU TEMA DE INTERÉS: 


autoayuda.es   Internet y Tecnologias 

Está aquí: Inicio > [ INTERNET ] > ıllı Aislamiento (ACID) wiki: info, historia y vídeos

Las cookies nos permiten ofrecer nuestros servicios. Al utilizar nuestros servicios, aceptas el uso que hacemos de las cookies. Ver políticas