Lectura sucia en SQL – Part 1

Requisito previo: tipos de programaciones , niveles de aislamiento de transacciones en DBMS
Existen principalmente cuatro tipos de problemas comunes de concurrencia: lectura sucia, lectura perdida, lectura no repetible y lectura fantasma.

Lecturas sucias:
cuando se permite que una transacción lea una fila que ha sido modificada por otra transacción que aún no se ha confirmado en el momento en que se produjeron las lecturas sucias . Ocurre principalmente debido a múltiples transacciones en un momento que no está comprometido.

Ejemplo –

Tabla – Registro

Transacción:
transfiera 10 de la cuenta de S Adam a la cuenta de Zee Young:

Input:
BEGIN TRY
  BEGIN TRANSACTION
    UPDATE Table SET Balance = Balance - 10 WHERE ID=1;
    UPDATE Table SET Balance = Balance + 10 WHERE ID='C';
  COMMIT TRANSACTION
  PRINT 'Committed'
END TRY
BEGIN CATCH
  ROLLBACK TRANSACTION
  PRINT 'Not Committed'
END CATCH

Output:
Not committed 

Al ejecutar la consulta anterior, el resultado será «No comprometido» porque hay un error, no hay ID = C. Entonces, en ese momento, si queremos ejecutar otra transacción con esa fila, se produce Dirty Reads . No hay compromiso parcial si ambas consultas de ACTUALIZACIÓN tienen éxito solo entonces la salida será «Confirmado».

Antes de la ejecución:

Tabla – Registro

Después de la ejecución:

Input: 
        BEGIN TRY
          BEGIN TRANSACTION
            UPDATE Table SET Balance = Balance - 10 WHERE ID=1;
            UPDATE Table SET Balance = Balance + 10 WHERE ID='C';
          COMMIT TRANSACTION
          PRINT 'Committed'
        END TRY
        BEGIN CATCH
          ROLLBACK TRANSACTION
          PRINT 'Not Committed'
        END CATCH

Output: 
        (1row affected)
        (0row affected)
      Not Committed 

Tenga en cuenta que si colocamos una ID válida, el primer resultado de la transacción aparecerá como comprometido o 1 fila afectada, pero la segunda no se verá afectada.

Explicación:
si tenemos un sistema de reserva de boletos y un cliente está tratando de reservar un boleto en ese momento, el número disponible del boleto es 10, antes de completar el pago, el segundo cliente desea reservar un boleto en ese momento, esta segunda transacción mostrará el segundo cliente que el número de boletos disponibles es 9. El giro está aquí si el primer cliente no tiene fondos suficientes en su tarjeta de débito o en su billetera, entonces la primera transacción retrocederá, ese tiempo 9 asiento disponible que es leído por el La segunda transacción es lectura sucia .

Ejemplo:
Ticket disponible: Para 1er cliente

• 1er paso –

  Input:
  -- Transaction 1
  Select *from Bus_ticket; 

  Producción:

  IDENTIFICACIÓN	Bus_Name	Asiento disponible
  1	KA0017	10

• 2.º paso:
  reserva de tiempo para el 1.er cliente

  Input:  
  --Transaction 1
          BEING Transaction
          UPDATE Bus_Ticket set Available_Seat=9
          WHERE ID=1
          
          --Payment for Transaction 1
          Waitfor Delay '00.00.30'
          Rollback transaction 

  Boleto disponible: Para el 2° cliente mientras el 1° cliente paga el boleto.

• 3er Paso –

  Input:  
  -- Transaction 1
  
  set transaction isolation level read uncommitted
  Select *from Bus_ticket where ID=1; 

  Producción:

  IDENTIFICACIÓN	Bus_Name	Asiento disponible
  1	KA0017	9

Tenga en cuenta que durante el pago del primer cliente, la segunda transacción, el asiento 9 está disponible si, de alguna manera, la reversión de la primera transacción y luego el asiento 9 disponible son datos de lectura sucios. Después de la reversión de la primera transacción, el asiento disponible vuelve a ser 10. 2do y 3er paso sucediendo al mismo tiempo.

Asiento realmente disponible después de la reversión de la transacción 1: