¿cuál es la diferencia entre lectura no repetible y lectura fantasma?

Question

¿Cuál es la diferencia entre lectura no repetible y lectura fantasma?

He leído el Isolation (database systems) article from Wikipedia, pero tengo algunas dudas. En el siguiente ejemplo, ¿qué sucederá: lectura no repetible y phantom read?

Transacción A

SELECT ID, USERNAME, accountno, amount FROM USERS WHERE ID=1 

SALIDA:

1----MIKE------29019892---------5000 

transacción B

UPDATE USERS SET amount=amount+5000 where ID=1 AND accountno=29019892; 
COMMIT; 

Transacción A

SELECT ID, USERNAME, accountno, amount FROM USERS WHERE ID=1 

Otra duda es, en el ejemplo anterior, ¿qué nivel de aislamiento se debe utilizar? ¿Y por qué?

Answer 1

From Wikipedia (que tiene ejemplos grandes y detalladas para este):

se produce una lectura no repetible, cuando durante el curso de una transacción, una fila se recupera dos veces y los valores dentro de la fila difieren entre lee.

y

Una lectura fantasma se produce cuando, en el curso de una transacción, dos consultas idénticas se ejecutan, y la colección de filas devueltas por la segunda consulta es diferente de la primera.

ejemplos simples:

• Un usuario ejecuta la misma consulta dos veces.
• Mientras tanto, el usuario B ejecuta una transacción y se compromete.
• Lectura no repetible: La fila A que el usuario A ha consultado tiene un valor diferente por segunda vez.
• Phantom leer: Todas las filas en la consulta tienen el mismo valor antes y después, pero se están seleccionando diferentes filas (porque B ha eliminado o insertado algunas). Ejemplo: select sum(x) from table; devolverá un resultado diferente incluso si ninguna de las filas afectadas se ha actualizado, si se han agregado o eliminado filas.

En el ejemplo anterior, ¿qué nivel de aislamiento usar?

Qué nivel de aislamiento necesita depende de su aplicación. Hay un alto costo para un nivel de aislamiento "mejor" (como concurrencia reducida).

En su ejemplo, no tendrá una lectura fantasma, porque selecciona solo de una sola fila (identificada por la clave principal). Puede tener lecturas no repetibles, por lo tanto, si eso es un problema, es posible que desee tener un nivel de aislamiento que lo impida. En Oracle, la transacción A también podría emitir un SELECCIONAR PARA ACTUALIZAR, luego la transacción B no puede cambiar la fila hasta que A finalice.

Answer 2

En un sistema con lecturas no repetibles, el resultado de la segunda consulta de la Transacción A reflejará la actualización en la Transacción B; verá la nueva cantidad.

En un sistema que permite lecturas fantasmas, si la Transacción B fuera inserte una nueva fila con ID = 1, la Transacción A verá la nueva fila cuando se ejecute la segunda consulta; es decir, las lecturas ficticias son un caso especial de lectura no repetible.

Answer 3

Una forma sencilla me gusta pensar que es:

Ambos no sea repetible y las lecturas fantasma tiene que ver con las operaciones de modificación de datos de una transacción diferente, que se cometieron después del inicio de la transacción, y luego leído por su transacción.

Las lecturas no repetibles son cuando su transacción dice comprometida ACTUALIZACIONES de otra transacción. La misma fila ahora tiene valores diferentes a los que tenía cuando comenzó su transacción.

fantasma lee son similares, pero cuando se lee de cometidos INSERTS y/o ELIMINA de otra transacción. Hay nuevas filas o filas que han desaparecido desde que comenzó la transacción.

lecturas sucias son similares que no sea repetible y las lecturas fantasma, sino que se refieren a la lectura de datos no confirmados, y se producen cuando hay una actualización, insertar o eliminar de otra transacción se lee, y la otra transacción aún no ha cometido el datos. Está leyendo datos "en curso", que pueden no estar completos, y es posible que nunca se hayan confirmado.

Answer 4

Hay una diferencia en la implementación entre estos dos niveles de aislamiento de clases.
Para "lectura no repetible", es necesario el bloqueo de filas.
Para "lectura fantasma", se necesita un bloqueo de alcance, incluso un bloqueo de mesa.
Podemos implementar estos dos niveles utilizando el protocolo two-phase-locking.

Answer 5

La respuesta aceptada indica sobre todo que la llamada distinción entre los dos en realidad no es para nada significativa.

Si "una fila se recupera dos veces y los valores dentro de la fila difieren entre lecturas", entonces no son la misma fila (no la misma tupla en el habla correcta de RDB) y es por definición el caso que "la colección de filas devuelta por la segunda consulta es diferente de la primera".

En cuanto a la pregunta "¿Qué nivel de aislamiento se debe utilizar?", Cuantos más datos sean de vital importancia para alguien, en algún lugar, más será el hecho de que Serializable sea su única opción razonable.

Answer 6

Lectura sucia: lea los datos SIN COMPROMISO de otra transacción.

Lectura no repetible: lee los datos COMPORTADOS de una consulta de ACTUALIZACIÓN de otra transacción.

Lectura Phantom: lee datos COMPORTADOS de una consulta INSERTAR o ELIMINAR de otra transacción.

Tenga en cuenta que las ACTUALIZACIONES pueden ser un trabajo más frecuente en ciertas aplicaciones en lugar de las INSERTAS o LAS ELIMINACIONES reales; en estos casos, el peligro de lecturas no repetibles permanece solo; las lecturas fantasmas no son posibles en esos casos. Esto explica por qué las ACTUALIZACIONES se tratan de forma diferente a INSERT-DELETE y la anomalía en cuestión también recibe un nombre diferente.

También hay un costo de procesamiento adicional asociado con el manejo de INSERT-DELETES, en lugar de solo manejar las ACTUALIZACIONES.

El nivel de aislamiento TRANSACTION_READ_UNCOMMITTED no evita nada. Es el nivel de aislamiento cero.

El nivel de aislamiento TRANSACTION_READ_COMMITTED impide que solo uno, es decir. Dirty lee.

El nivel de aislamiento TRANSACTION_REPEATABLE_READ previene dos anomalías: lecturas sucias y lecturas no repetibles.

El nivel de aislamiento TRANSACTION_SERIALIZABLE previene las tres anomalías: lecturas sucias, lecturas no repetibles y lecturas Phantom.

¿Por qué no simplemente establecer la transacción SERIALIZABLE en todo momento?

Bueno, la respuesta a la pregunta anterior es: la configuración de SERIALIZABLE hace que las transacciones sean muy lentas, lo que de nuevo no deseamos.

De hecho el consumtion tiempo de la transacción se encuentra en la siguiente tarifa:

SERIALIZABLE> REPEATABLE_READ> READ_COMMITTED> READ_UNCOMMITTED.

La configuración READ_UNCOMMITTED es la más rápida.

En realidad, necesitamos analizar el caso de uso y decidir un nivel de aislamiento para optimizar el tiempo de transacción y también evitar la mayoría de las anomalías.

Tenga en cuenta que las bases de datos tienen de forma predeterminada la configuración REPEATABLE_READ.

Answer 7

Creo que hay alguna diferencia entre lectura no repetible & phantom-read.

El no repetible significa que hay transacción de remolque A & B. si B puede notar la modificación de A, entonces puede que suceda lectura sucia, por lo que dejamos que B note la modificación de A después de la confirmación.

Existe un nuevo problema: dejamos que B note la modificación de A después de confirmar, significa que A modifica un valor de fila que B está reteniendo, en algún momento B leerá nuevamente la fila, por lo que B obtendrá un nuevo valor diferente con la primera vez que lo recibimos, lo llamamos No repetible, para tratar el problema, dejamos que el B recuerde algo (porque no sé qué será recordado aún) cuando B comience.

Pensemos en la nueva solución, podemos notar que también hay un problema nuevo, porque dejamos que B recuerde algo, así que pase lo que pase en A, la B no puede verse afectada, pero si B quiere insertar algunos datos en la tabla y B verifique la tabla para asegurarse de que no haya ningún registro, pero esta información ha sido insertada por A, por lo que puede ocurrir algún error. Lo llamamos Phantom-read.