Dans un environnement multi-utilisateurs, il est essentiel de maintenir la simultanéité de troncature. Ces verrous sont des structures en mémoire d'une taille de 96 octets. Leur rôle est de maintenir l'intégrité des données, la cohérence et le contrôle de la concurrence pour chaque transaction. SQL Server suit le test ACID pour chaque transaction.
- Un tomicité :cette propriété garantit qu'une transaction impliquant deux processus ou plus est entièrement validée, ou qu'aucun des processus n'est validé.
- C onsistency :Cela vous donne une garantie sur l'état de la transaction validée. Une transaction doit soit créer un nouvel état des données, soit revenir à l'état existant (avant la transaction).
- Je Solation :Cela indique que les transactions sont isolées les unes des autres. Si une transaction est en cours d'exécution et qu'elle n'a pas validé de données, elle est isolée des autres transactions.
- D urabilité :la durabilité garantit que vos données validées ne sont jamais perdues. Il empêche les pannes d'alimentation et du système d'exploitation, ou d'autres erreurs induites par le logiciel.
Pour garantir les propriétés ACID, SQL Server impose différents types de verrous sur les objets. Dans ce cas, les autres transactions doivent attendre que le verrou soit libéré.
Modes de verrouillage
SQL Server utilise les modes de verrouillage suivants pour chaque transaction.
- Verrous partagés :
- Dans ce verrou, SQL Server permet à d'autres sessions d'effectuer les opérations sélectionnées pour lire les données. Cependant, il empêche les mises à jour tant que le verrou n'est pas activé.
- Plusieurs transactions peuvent imposer un verrou partagé en même temps sur une ligne ou une page.
- Il s'agit d'un verrou commun que vous voyez sur vos objets de base de données.
Dans le T-SQL suivant, nous récupérons l'enregistrement client pour un ID client spécifique. De plus, nous utilisons la vue de gestion dynamique sys.dm_tran_locks pour vérifier les verrous existants.
BEGIN TRAN
SELECT * FROM [SalesLT].[Customer] WITH (HOLDLOCK)
WHERE CustomerID=1
SELECT resource_type, request_mode, resource_description
FROM sys.dm_tran_locks
WHERE resource_type <> 'DATABASE'
ROLLBACK
Comme indiqué ci-dessous, il a un verrou partagé sur l'ID de ressource donné (8194443284a0) :
- Verrous exclusifs (X) :
- SQL Server utilise un verrou exclusif (X) pour les opérations DML (suppression, insertion ou mise à jour), nécessitant la modification d'une ligne ou de données de page.
- Il empêche d'autres utilisateurs d'accéder à la ressource jusqu'à ce qu'un verrou soit placé.
- SQL Server ne peut avoir qu'un seul verrou exclusif sur une page ou une ligne pour une transaction.
Dans cet exemple, nous voulons mettre à jour les enregistrements pour l'ID client 1. Par conséquent, SQL Server requiert un verrou exclusif sur la ressource. Aucune autre transaction ne peut acquérir le verrou exclusif sur cette ressource tant que la transaction n'est pas terminée.
BEGIN TRAN
UPDATE [SalesLT].[Customer]
SET Suffix='Mr.'
WHERE CustomerID=1
SELECT resource_type, request_mode, resource_description
FROM sys.dm_tran_locks
WHERE resource_type <> 'DATABASE'
ROLLBACK
- Mettre à jour les verrous (U) :
- Le verrou de mise à jour est similaire à un verrou exclusif. Il peut être placé sur un enregistrement ayant un verrou partagé.
- Le verrou de mise à jour place un autre verrou partagé sur une ligne spécifique. Une fois qu'il peut modifier les enregistrements, SQL Server convertit le verrou de mise à jour en un verrou exclusif.
- SQL Server ne peut pas placer un verrou partagé sur une ressource avec un verrou de mise à jour.
- Vous pouvez également utiliser WITH UPDLOCK pour forcer un verrouillage de mise à jour.
L'exemple suivant montre un verrou de mise à jour sur l'ID de ressource (8194443284a0) :
BEGIN TRAN
SELECT * FROM [SalesLT].[Customer] WITH (UPDLOCK)
WHERE CustomerID=1
SELECT resource_type, request_mode, resource_description
FROM sys.dm_tran_locks
WHERE resource_type <> 'DATABASE'
ROLLBACK
- Verrouillages d'intention :
- Son but est d'informer une transaction de son intention d'acquérir un verrou. Cela se produit lorsqu'une transaction nécessite un verrou partagé ou exclusif sur les ressources inférieures dans la hiérarchie.
- La transaction n'autorise pas d'autres transactions à obtenir un verrou exclusif sur la table à l'aide d'un verrou d'intention.
- Les types de verrous d'intention sont indiqués ci-dessous.
- Verrou Intent Shared (IS) :il indique l'intention de SQL Server de lire les ressources de la hiérarchie inférieure en acquérant un verrou partagé individuellement sur ces ressources de la hiérarchie inférieure.
- Verrou exclusif d'intention (IX) :il indique l'intention de SQL Server de modifier les ressources de la hiérarchie inférieure en obtenant un verrou exclusif sur ces ressources de la hiérarchie inférieure.
- Un verrou de mise à jour d'intention (IU) :il peut être acquis au niveau de la page uniquement pour les ressources hiérarchiques inférieures, et une fois la mise à jour terminée, il se convertit en verrou IX.
Comme indiqué ci-dessous, la transaction a un verrou exclusif sur une clé et un verrou exclusif d'intention au niveau de la page.
Verrous de conversion
SQL Server convertit les types de verrous pour prendre en charge plusieurs requêtes dans une transaction. Ces verrous sont appelés verrous de conversion.
- SIX – Verrou exclusif partagé avec intention :la transaction SQL Server détient un verrou partagé sur plusieurs pages et possède un verrou exclusif verrouiller sur plusieurs lignes.
- SIU - La transaction SQL Server détient un verrou partagé sur plusieurs pages et a une mise à jour verrouiller sur plusieurs lignes.
- UIX – Mettre à jour avec un verrou exclusif d'intention :la transaction SQL Server détient un verrou de mise à jour sur plusieurs pages et possède un verrou exclusif verrouiller sur plusieurs lignes.
Verrouillages de schéma
SQL Server acquiert deux types de verrous de schéma.
- Verrou de stabilité du schéma (Sch-S) :ce verrou est utilisé lorsque la requête dépendant du schéma se compile et que son plan d'exécution est en cours de génération. Le verrou Sch-S ne bloque aucun accès aux données de l'objet.
- Schema modification lock (Sch-M) :ce verrou résulte de l'exécution d'une requête DDL (Data Definition Language). SQL Server ne peut avoir qu'un seul verrou de modification de schéma sur un objet. Vous ne pouvez pas modifier un objet avec ce verrou de schéma.
Dans l'exemple ci-dessous, nous obtenons à la fois des verrous Sch-S et Sch-M lors de la modification d'une définition d'objet.
BEGIN TRAN
Alter TABLE DemoTable ADD new bit
SELECT resource_type, request_mode, resource_description
FROM sys.dm_tran_locks
WHERE resource_type <> 'DATABASE'
ROLLBACK
Compatibilité des serrures
La compatibilité des verrous est utile pour vérifier les verrous autorisés en cas de transactions multiples dans la même ressource simultanément. Si une transaction place un verrou, le nouveau verrou placé par une autre transaction doit être compatible avec celle-ci. Par conséquent, vous pouvez parcourir la liste de compatibilité des verrous suivante et trouver les verrous pris en charge lors de plusieurs transactions.
Verrouiller les escalades
SQL Server a introduit une fonctionnalité d'escalade de verrous pour éviter un trop grand nombre de verrouillages qui pourraient entraîner une pression sur la mémoire. SQL Server prend en compte le nombre de verrous détenus sur une analyse particulière et le nombre de verrous détenus par l'ensemble de la transaction et de la mémoire de manière dynamique. SQL Server convertit les verrous de bas niveau en verrous de haut niveau lors de l'escalade de verrous. Par exemple, il convertit les verrous de ligne en verrous au niveau de la page.
Il utilise le seuil suivant pour les escalades de verrous.
- Seuil de mémoire : Le seuil de mémoire de verrouillage est défini à 40 % de la mémoire de verrouillage.
- Seuil de verrouillage : Si le nombre de verrous acquis sur la table ou l'index actuel est supérieur à 5 000, des escalades de verrous peuvent être déclenchées.
Les utilisateurs peuvent contrôler les escalades de verrous à l'aide de l'instruction alter table. Vous pouvez complètement désactiver l'escalade de verrous pour cette table à l'aide d'une valeur de paramètre DISABLE.
ALTER TABLE Table_name SET (LOCK_ESCALATION = < TABLE | AUTO | DISABLE > –One of those options) GO
Vous pouvez vous référer à la documentation Microsoft pour comprendre en détail les escalades de verrouillage.
Remarque :Vous ne devez pas désactiver l'escalade de verrous tant qu'elle n'a pas été soigneusement testée dans un environnement inférieur, et il est recommandé de l'utiliser uniquement par des DBA expérimentés.
Conclusion
Cet article donne un aperçu détaillé des verrous SQL Server et DMV pour surveiller le verrou et son processus d'escalade. Le verrouillage est un comportement tout à fait normal dans SQL Server, et vous devez le connaître pour comprendre le fonctionnement de plusieurs transactions, simulant et fournissant des données cohérentes.