Réduction des blocages

Même si les blocages ne peuvent pas être totalement évités, le respect de certaines conventions de codage peut minimiser le risque d'en générer. La réduction des blocages peut augmenter le débit des transactions et réduire la charge du système, car il y a moins de transactions :

• restaurées, en annulant ce qui a été accompli par la transaction ;
• resoumises par les applications, car ces transactions ont été restaurées lors du blocage.

Pour réduire le nombre de blocages :

• Accédez aux objets dans le même ordre.
• Évitez les interactions utilisateur dans les transactions.
• Créez des transactions courtes dans le même lot d'instructions.
• Utilisez un niveau d'isolement plus faible.
• Utilisez un niveau d'isolement basé sur le versioning de ligne.
  • Affectez à l'option de base de données READ_COMMITTED_SNAPSHOT la valeur ON pour activer les transactions read-committed afin d'utiliser le versioning de ligne.
  • Utilisez un isolement de capture instantanée.
• Utilisez des connexions liées.

Accès aux objets dans le même ordre

Si toutes les transactions concurrentes accèdent aux objets dans le même ordre, le risque de blocage diminue. Par exemple, si deux transactions concurrentes obtiennent un verrou sur la table Supplier, puis sur la table Part, l'une des transactions est bloquée sur la table Supplier jusqu'à ce que l'autre transaction se termine. Après la validation ou la restauration de la première transaction, la seconde continue et aucun blocage ne se produit. L'utilisation de procédures stockées pour toutes les modifications de données peut standardiser l'ordre d'accès aux objets.

Aucune interaction utilisateur dans les transactions

Évitez d'écrire des transactions comprenant une interaction utilisateur, car la vitesse d'exécution des lots d'instructions sans intervention de l'utilisateur est beaucoup plus rapide que la vitesse à laquelle un utilisateur doit répondre manuellement aux requêtes telles que la demande d'un paramètre requis par une application. Par exemple, si une transaction attend une entrée de la part de l'utilisateur, et si ce dernier va déjeuner ou rentre chez lui pour le week-end, l'utilisateur empêche la transaction de se terminer. Ceci dégrade les performances du système, car tous les verrous détenus par la transaction ne sont libérés qu'une fois la transaction validée ou restaurée. Même si une situation de blocage ne se produit pas, toutes les autres transactions en attente de la même ressource sont bloquées, en attente de la fin de la transaction.

Transactions courtes dans un seul lot

Un blocage se produit souvent lorsque plusieurs transactions longues sont exécutées de manière concurrente dans la même base de données. Plus la transaction est longue, plus la durée de détention du verrou exclusif ou de mise à jour est importante, ce qui bloque les autres activités et peut entraîner une situation de blocage.

La création de transactions courtes dans un seul lot limite les allers-retours sur le réseau en réduisant les délais potentiels d'achèvement de la transaction et de suppression des verrous.

Niveau d'isolement faible

Déterminez si une transaction peut être exécutée à un niveau d'isolement faible. L'implémentation de la lecture validée (read committed) permet à une transaction de lire des données lues auparavant (non modifiées) par une autre transaction, sans attendre la fin de la première transaction. L'utilisation d'un niveau d'isolement faible (comme la lecture validée, par exemple) permet de conserver les verrous partagés pendant une durée inférieure à celle d'un niveau d'isolement supérieur (comme le niveau sérialisable) et réduit ainsi les délais de verrouillage.

Niveau d'isolement basé sur le versioning de ligne

Lorsque l'option de base de données READ_COMMITTED_SNAPSHOT a la valeur ON, une transaction qui s'exécute sous un niveau d'isolement read committed utilise le versioning de ligne plutôt que les verrous partagés lors des opérations de lecture.

Remarque :
Certaines applications se basent sur le comportement de verrouillage et de blocage de l'isolement de lecture validée. Avec ces applications, certaines modifications sont nécessaires pour pouvoir activer cette option.

L'isolement de capture instantanée utilise également le versioning de ligne, qui n'emploie pas de verrous partagés pendant les opérations de lecture. Pour qu'une transaction puisse s'exécuter sous un isolement de capture instantanée, l'option de base de données ALLOW_SNAPSHOT_ISOLATION doit avoir la valeur ON.

Implémentez ces niveaux d'isolement pour minimiser les blocages pouvant survenir entre les opérations de lecture et d'écriture.

Connexions liées

En utilisant des connexions liées, deux connexions ou plus ouvertes par la même application peuvent coopérer entre elles. Tout verrou acquis par la connexion secondaire apparaît comme s'il avait été posé par la connexion primaire et vice-versa. Ils ne se bloquent donc pas réciproquement.

Voir aussi

Concepts

Interblocage
Détection et fin des blocages
Gestion des blocages
Utilisation de niveaux d'isolement basés sur la gestion de la version des lignes
Utilisation de sessions associées

Aide et Informations

Assistance sur SQL Server 2005