none
SET READ_COMMITTED_SNAPSHOT ON RRS feed

  • Pregunta

  • Estimados.

    En una BD si inicio una transaccion y no hago commit ni rollback para probar su funcionamiento, y abro otra transaccion en esta otra transaccion obviamente no me despliega los datos de la tabla hasta que termine la transaccion de la que lo tiene bloqueado.

    Dicho esto, hice lo siguiente

    USE [master]
    GO
    ALTER DATABASE BD SET READ_COMMITTED_SNAPSHOT ON WITH NO_WAIT
    GO

    ALTER DATABASE BD
    SET READ_COMMITTED_SNAPSHOT ON
    GO

    Entonces de esta manera al hacer SELECT puedo leer la tabla sin problemas, obviamente sin los datos que aun no confirmo.

    Cual serian los pro y contras de manejar de esta manera una BD ?

    Saludos.


    DBA SQL Server Santiago/Chile

    miércoles, 6 de junio de 2018 21:43

Respuestas

  • El "contra" es que es más lento y genera tráfico contra el tempdb (ahí es donde se guarda una copia de los datos que modifica la transacción para no bloquear los que se leen desde la otra transacción). Otro "contra" es que puedes tener un conflicto si cuando termine la transacción se hace un commit de unos cambios que entren en conflicto con otros cambios que mientras tanto se pudieron hacer desde otra transacción, al no quedar bloqueada. Pero si la lógica de tu programa ya controla esta situación, no hay problema.

    El "pro" obviamente es que aumenta la concurrencia gracias a que se evitan los bloqueos entre distintas transacciones.

    • Marcado como respuesta CMAPM jueves, 7 de junio de 2018 18:17
    jueves, 7 de junio de 2018 6:45

Todas las respuestas

  • El "contra" es que es más lento y genera tráfico contra el tempdb (ahí es donde se guarda una copia de los datos que modifica la transacción para no bloquear los que se leen desde la otra transacción). Otro "contra" es que puedes tener un conflicto si cuando termine la transacción se hace un commit de unos cambios que entren en conflicto con otros cambios que mientras tanto se pudieron hacer desde otra transacción, al no quedar bloqueada. Pero si la lógica de tu programa ya controla esta situación, no hay problema.

    El "pro" obviamente es que aumenta la concurrencia gracias a que se evitan los bloqueos entre distintas transacciones.

    • Marcado como respuesta CMAPM jueves, 7 de junio de 2018 18:17
    jueves, 7 de junio de 2018 6:45
  • Estimado Alberto.

    Muchas gracias, ya con la "contra" es mas lento, descarto utilisarla, pues pensaba que era más "rapido"

    Saludos y muchas gracias como siempre.


    DBA SQL Server Santiago/Chile


    • Editado CMAPM jueves, 7 de junio de 2018 18:18
    jueves, 7 de junio de 2018 18:18
  •  ya con la "contra" es mas lento, descarto utilisarla, pues pensaba que era más "rapido"

    Maticemos: La transacción en sí misma es un pelín más lenta debido a la escritura adicional en el tempdb. Pero si estás haciendo muchas transacciones simultáneas, el conjunto de todas ellas es más rápido debido a que no se bloquean las unas a las otras.

    jueves, 7 de junio de 2018 19:03