El TecnoBaúl de Kiquenet

Kiquenet boring stories

Transacciones: Gestión de bloqueos en SQL Server

Posted by kiquenet en 18 septiembre 2010

Se ha comentado el funcionamiento de las transacciones en este gestor de base de datos (SGBD). Sin embargo, para acabar de comprender su funcionamiento debemos conocer cómo se manejan los bloqueos en SQL Server. El correcto funcionamiento y la eficiencia de nuestra aplicación que maneja usuarios concurrentes accediendo a nuestra base de datos dependen de la configuración de SQL Server y de la programación de la aplicación, así que, tanto para una cosa como para la otra, debemos comprender y manejar estos conceptos.

Bloqueos y rendimiento

Los bloqueos son los encargados de hacer que las transacciones tengan la propiedad de aislamiento. La realización de bloqueos en un entorno concurrente proporciona aislamiento en los siguientes casos:

  • Múltiples transacciones intentan modificar la misma fila.
  • Datos no confirmados por una transacción son leídos por otras transacciones. Esto se conoce como lecturas sucias.
  • Los datos leídos con la misma cláusula “select” durante varias etapas de la transacción dan lugar a valores diferentes con el mismo conjunto de datos. Conocido como lecturas no repetibles.
  • Los datos leídos con la misma cláusula “select” durante varias etapas de la transacción dan lugar a diferentes conjuntos de datos. Es lo que se conoce como “lecturas fantasma”.

El establecimiento de los bloqueos es automático en SQL Server, no teniéndose que preocupar, por tanto, el programador directamente por ellos, aunque debe tener en cuenta qué tipo de bloqueos establece cada operación atendiendo a las cláusulas incluidas, etc., para minimizar los interbloqueos.

Recursos de los bloqueos. Granularidad del bloqueo

El establecimiento de bloqueos es automático en SQL Server. El gestor de bloqueos es el encargado de decidir el tipo y la granularidad del bloqueo.

Los bloqueos se pueden producir tanto a nivel de página de datos como a nivel de página de índice. El gestor de bloqueo puede decidir bloquear los recursos: tabla, extensión, página, fila y rango de clave.

La granularidad del bloqueo incide de forma directa sobre la concurrencia y el rendimiento del sistema. El optimizador de consultas decide la granularidad del bloqueo automáticamente. No obstante, SQL Server proporciona extensiones de T-SQL que proporcionan un mecanismo para controlar la granuralidad de los bloqueos.

Tipos de bloqueo en SQL Server

El procedimiento almacenado “sp_lock” proporciona los bloqueos activos en el sistema gestor de bases de datos. También ofrecen información sobre bloqueos el administrador corporativo, el monitor de rendimiento, el administrador de memoria y el objeto de SQL Server bloqueos.

Dependiendo del tipo de transacción, el gestor de bloqueos establece distintos tipos de bloqueos.

Bloqueos compartidos

Se establecen para operaciones de sólo lectura, por ejemplo “select”.

Varias transacciones pueden mantener varios bloqueos compartidos simultáneamente sobre el mismo recurso ya que dichas transacciones no interfieren entre sí.

Si una transacción intenta modificar un dato de un recurso sobre el que se ha establecido un bloqueo compartido, se bloqueará hasta que todos los bloqueos compartidos se liberen.

Un bloqueo compartido se libera en cuanto se finaliza la operación de lectura de datos, es decir, no permanece a lo largo de la transacción. Existen cláusulas de las que se hablará más adelante para modificar este comportamiento.

Bloqueos de actualización

Los bloqueos de actualización se usan para instrucciones que modifican datos.

Cuando una transacción intenta actualizar una fila primero ha de leerla para asegurarse de que la fila en cuestión es realmente la que se quiere modificar. En este momento establece un bloqueo compartido. Una vez se ha asegurado que es la fila correcta procederá a modificarla, para lo que necesita establecer un bloqueo exclusivo que será liberado al terminar la transacción. Los bloqueos de actualización se emplean como bloqueo intermedio entre los dos anteriores para evitar interbloqueos.

Bloqueos exclusivos

Se concede un bloqueo de este tipo a una transacción cuando ésta está lista para modificar los datos. Un bloqueo exclusivo sobre un recurso asegura que ninguna otra transacción pueda interferir las acciones llevadas a cabo por la primera transacción sobre los recursos bloqueados.

SQL Server libera el bloqueo al finalizar la transacción.

Bloqueos de intención

El bloqueo de intención es un mecanismo que utilizan las transacciones para declarar su intención de obtener un bloqueo compartido, de actualización o exclusivo sobre un recurso.

No establece ningún bloqueo en si, excepto por el hecho de que otra transacción no podrá adquirir un bloqueo de actualización sobre un recurso sobre el que se haya establecido un bloqueo de intención.

Bloqueos de esquema

Se utilizan para mantener la integridad estructural de las tablas SQL Server. A diferencia de otros bloqueos, que proporcionan aislamiento para los datos, los bloqueos de esquema proporcionan aislamiento para el esquema de objetos de la base de datos.

Compatibilidad de bloqueos

En la siguiente lista se muestra la compatibilidad entre los distintos tipos de bloqueo. Para cada bloqueo que puede llegar a estar activo sobre una conexión al sistema gestor de bases de datos SQL Server se lista qué tipos de bloqueo pueden solicitarse concurrentemente (por ejemplo, si existe un bloqueo de modificación de esquema no puede solicitarse ningún otro tipo de bloqueo, tal y como muestra el último elemento de esta lista).

  • De intención compartido: de intención compartido, compartido, de actualización, de intención exclusivo, compartido de intención exclusivo y de estabilidad de esquema.
  • Compartido: de intención compartido, compartido, de actualización y de estabilidad de esquema.
  • De actualización: de intención compartido, compartido y de estabilidad de esquema.
  • De intención exclusivo: de intención compartido, de intención exclusivo y de estabilidad de esquema.
  • Compartido de actualización exclusivo: de intención compartido y de estabilidad de esquema.
  • Exclusivo: estabilidad de esquema.
  • Estabilidad de esquema: de intención compartido, compartido, de actualización, de intención exclusivo, compartido de intención exclusivo, exclusivo y de estabilidad de esquema.
  • Modificación de esquema: ningún bloqueo es compatible con el bloque de modificación de esquema.
Bloqueos de índices

De forma similar a los bloqueos de páginas de datos, SQL Server gestiona los bloqueos de las páginas de índices internamente.

Con el comando “sp_indexoption” se puede modificar el gestor permitiendo o no bloqueos a nivel de filas.

Se recomienda no realizar modificaciones sobre el comportamiento por defecto del gestor de bloqueos en lo referente a las páginas de índices ya que suele hacer buenas elecciones.

Notas:

Todas las técnicas comentadas tratan en todo momento de mantener la integridad de la base de datos si no, solucionar el problema de mejorar el acceso concurrente nos crearía un problema más grave aún.

A esto que acabo de decir, tengo que añadir dos matices:
El primero de ellos es que siempre hay que tener presente que las cosas que hagas se pueden hacer bien o mal. Por ejemplo, cambiar los niveles de aislamiento de las transacciones puede provocar el colapso de la base de datos, que tus aplicaciones empiecen a mostrar datos sobre los que no se ha hecho commit (que puede ser un problema o no)… En fin, que hay que saber lo que se está haciendo.
El segundo es, en parte, continuación de lo anterior, y es que cada solución, como todo en este mundo tiene sus cosas buenas y sus cosas malas por lo que se adaptan mejor o peor a un tipo de problema determinado, dependiendo del coste de implementación, de la forma en que resuelven el problema de bloqueo, etc. Por poner un ejemplo, la solución más “sencillita” que sería utilizar un flag con un plan de contingencia, puede dejar registros bloqueados en el caso que comentas, por eso es necesario un plan de contingencia que consiste en una aplicación auxiliar que libere esos registros en caso de que se vaya la luz, etc… Sin embargo, implementarla es muy sencillo y no hay que controlar ningún otro efecto colateral… El bloqueo pesimista utilizando caducidad del bloqueo es, en general, el que mejor se ajusta a todo tipo de problemas pero requiere más implementación…

Como comentaba, todo depende del problema en cuestión.

Del Mister Alcalde

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

 
A %d blogueros les gusta esto: