Descripción de la simultaneidad
Una característica principal de las bases de datos multiusuario es la simultaneidad. La simultaneidad usa el bloqueo con el fin de que los datos sigan siendo coherentes con muchos usuarios que actualizan y leen datos al mismo tiempo. Por ejemplo, debido a los costos de envío, todos nuestros productos tienen un aumento de precio de $5. Al mismo tiempo, debido al tipo de moneda, todos los productos tienen una reducción del precio del 3 %. Si estas actualizaciones se producen exactamente al mismo tiempo, el precio final será variable y es probable que haya muchos errores. Con el bloqueo, puede asegurarse de que se completará una actualización antes de que comience la otra.
La concurrencia se produce en el nivel de transacción. Una transacción de escritura puede impedir que otras transacciones actualicen e incluso lean los mismos datos. Igualmente, una transacción de lectura puede bloquear a otros lectores o incluso a algunos escritores. Por este motivo, es importante evitar transacciones o transacciones innecesariamente largas que abarcan cantidades excesivas de datos.
Hay muchos niveles de aislamiento de transacciones específicos que se pueden usar para definir cómo un sistema de base de datos controla varios usuarios. Para los fines de este módulo, veremos amplias categorías de nivel de aislamiento, bloqueo optimista y bloqueo pesimista.
Nota:
El detalle completo del bloqueo de transacciones más allá de la simultaneidad está relacionado con el rendimiento y no solo depende del código, aunque el código correcto funciona mejor. Revise la guía detallada sobre el bloqueo de transacciones y control de versiones de filas de SQL Server para obtener más detalles. Para obtener información sobre el bloqueo, revise también la documentación de rendimiento de SQL Server.
Simultaneidad optimista
Con el bloqueo optimista, se supone que ocurrirán pocos conflictos de actualizaciones. Al principio de la transacción, se registra el estado inicial de los datos. Antes de confirmar la transacción, el estado actual se compara con el estado inicial. Si los estados son los mismos, se completa la transacción. Si los estados son diferentes, la transacción se revierte.
Por ejemplo, tiene una tabla que contiene los pedidos de ventas de los últimos años. Estos datos se actualizan esporádicamente, pero los informes se elaboran con frecuencia. Mediante el bloqueo optimista, las transacciones no se bloquean entre sí y el sistema se ejecuta de forma más eficaz. Desafortunadamente, se han encontrado errores en los datos del año pasado y las actualizaciones deben realizarse. Aunque una transacción actualiza cada fila, otra transacción realiza una edición secundaria en una sola fila al mismo tiempo. Dado que el estado de los datos se cambió mientras se estaba ejecutando la transacción inicial, se revierte toda la transacción.
Simultaneidad pesimista
Con el bloqueo pesimista, se supone que se producen muchas actualizaciones en los datos al mismo tiempo. Al usar bloqueos, solo se puede producir una actualización al mismo tiempo y se impiden las lecturas de los datos mientras se realizan actualizaciones. Esto puede evitar reversiones de gran tamaño, como las del ejemplo anterior, pero puede hacer que las consultas se bloqueen innecesariamente.
Es importante tener en cuenta la naturaleza de los datos y las consultas que se ejecutan en los datos al decidir si usar simultaneidad optimista o pesimista para garantizar un rendimiento óptimo.
Aislamiento de instantáneas
Hay cinco niveles de aislamiento diferentes en SQL Server, pero para este módulo nos centraremos en solo READ_COMMITTED_SNAPSHOT_OFF y READ_COMMITTED_SNAPSHOT_ON. La opción READ_COMMITTED_SNAPSHOT_OFF es el nivel de aislamiento predeterminado para SQL Server. READ_COMMITTED_SNAPSHOT_ON es el nivel de aislamiento predeterminado para Azure SQL Database.
READ_COMMITTED_SNAPSHOT_OFF bloqueará las filas afectadas hasta el final de la transacción si la consulta usa el nivel de aislamiento de transacción de lectura confirmada. Aunque es posible que se produzcan algunas actualizaciones, como la creación de una nueva fila, esto impedirá la mayoría de los cambios conflictivos en los datos que se leen o actualizan. Esta es la simultaneidad pesimista.
READ_COMMITTED_SNAPSHOT_ON toma una instantánea de los datos. A continuación, las actualizaciones se realizan en esa instantánea, lo que permite que otras conexiones consulten los datos originales. Al final de la transacción, el estado actual de los datos se compara con la instantánea. Si los datos son los mismos, se confirma la transacción. Si los datos difieren, la transacción se revierte.
Para cambiar el nivel de aislamiento a READ_COMMITTED_SNAPSHOT_ON, emita el comando siguiente:
ALTER DATABASE *db_name* SET READ_COMMITTED_SNAPSHOT ON;
Para cambiar el nivel de aislamiento a READ_COMMITTED_SNAPSHOT_OFF, emita el comando siguiente:
ALTER DATABASE *db_name* SET READ_COMMITTED_SNAPSHOT OFF;
Si se modificó la base de datos para activar la instantánea de lectura confirmada, cualquier transacción que use el nivel de aislamiento de lectura confirmada predeterminada usará el bloqueo optimista.
Nota:
El aislamiento de instantánea solo se produce para las transacciones de lectura confirmada. Las transacciones que usan otros niveles de aislamiento no se ven afectadas.