212
Chapitre 7. Transactions et verrous
attendre leur libération. Lorsque la seconde transaction essaie à son tour de modifier
les données, elle doit également attendre sur la première, d’où situation inextricable
et deadlock (également nommé interblocage ou verrou mortel). Pour éviter cela,
SQL Server pose également un verrou de mise à jour. Un seul verrou U peut-être
posé dans le même temps, sur la même ressource. Cela permet à la transaction de
convertir le verrou S en verrou X sans attendre, si elle possède le verrou U.
Les verrous intentionnels (intent, I) permettent de protéger les ressources aux
granularités supérieures, contre un verrouillage incompatible. Si une transaction
pose un verrou sur une ligne, il est nécessaire d’empêcher les autres transactions de
poser des verrous sur la page qui contient cette ligne, ou sur la table, afin de ne pas se
retrouver avec des verrous incompatibles par une voie détournée. Les verrous
d’intention permettent d’optimiser les performances de verrouillage, en évitant la
recherche des verrous de granularité plus fine. Si une transaction veut verrouiller la
table, elle n’a pas besoin de chercher s’il existe des verrous de ligne ou de page, il lui
suffit de vérifier la présence de verrous effectifs ou d’intention, sur la table.
Prenons un exemple, exécutons une requête de modification sur une table
d’AdventureWorks :
USE AdventureWorks
GO
BEGIN TRAN
UPDATE TOP (1) Sales.Currency
SET ModifiedDate = current_timestamp
Examinons les verrous :
SELECT
tl.resource_type,
tl.resource_subtype,
DB_NAME(tl.resource_database_id) as db,
tl.resource_description,
CASE tl.resource_type
WHEN 'OBJECT' THEN OBJECT_NAME(tl.resource_associated_entity_id)
ELSE COALESCE(OBJECT_NAME(p.object_id),
CAST(tl.resource_associated_entity_id as sysname))
END as obj,
tl.request_mode,
tl.request_status
FROM sys.dm_tran_locks tl
LEFT JOIN sys.partitions p
ON tl.resource_associated_entity_id = p.hobt_id
WHERE
tl.request_session_id = @@SPID AND
tl.resource_database_id = DB_ID()
ORDER BY
CASE resource_type
WHEN 'KEY' THEN 1
WHEN 'RID' THEN 1
WHEN 'PAGE' THEN 2
Chapitre 7. Transactions et verrous
attendre leur libération. Lorsque la seconde transaction essaie à son tour de modifier
les données, elle doit également attendre sur la première, d’où situation inextricable
et deadlock (également nommé interblocage ou verrou mortel). Pour éviter cela,
SQL Server pose également un verrou de mise à jour. Un seul verrou U peut-être
posé dans le même temps, sur la même ressource. Cela permet à la transaction de
convertir le verrou S en verrou X sans attendre, si elle possède le verrou U.
Les verrous intentionnels (intent, I) permettent de protéger les ressources aux
granularités supérieures, contre un verrouillage incompatible. Si une transaction
pose un verrou sur une ligne, il est nécessaire d’empêcher les autres transactions de
poser des verrous sur la page qui contient cette ligne, ou sur la table, afin de ne pas se
retrouver avec des verrous incompatibles par une voie détournée. Les verrous
d’intention permettent d’optimiser les performances de verrouillage, en évitant la
recherche des verrous de granularité plus fine. Si une transaction veut verrouiller la
table, elle n’a pas besoin de chercher s’il existe des verrous de ligne ou de page, il lui
suffit de vérifier la présence de verrous effectifs ou d’intention, sur la table.
Prenons un exemple, exécutons une requête de modification sur une table
d’AdventureWorks :
USE AdventureWorks
GO
BEGIN TRAN
UPDATE TOP (1) Sales.Currency
SET ModifiedDate = current_timestamp
Examinons les verrous :
SELECT
tl.resource_type,
tl.resource_subtype,
DB_NAME(tl.resource_database_id) as db,
tl.resource_description,
CASE tl.resource_type
WHEN 'OBJECT' THEN OBJECT_NAME(tl.resource_associated_entity_id)
ELSE COALESCE(OBJECT_NAME(p.object_id),
CAST(tl.resource_associated_entity_id as sysname))
END as obj,
tl.request_mode,
tl.request_status
FROM sys.dm_tran_locks tl
LEFT JOIN sys.partitions p
ON tl.resource_associated_entity_id = p.hobt_id
WHERE
tl.request_session_id = @@SPID AND
tl.resource_database_id = DB_ID()
ORDER BY
CASE resource_type
WHEN 'KEY' THEN 1
WHEN 'RID' THEN 1
WHEN 'PAGE' THEN 2