214
Chapitre 7. Transactions et verrous
relationnel. Lorsqu’une ligne est lue, par exemple, SQL Server doit protéger non
seulement la ligne, mais également la page (pour éviter qu’une insertion ne modifie
l’en-tête qui indique l’offset de la ligne). Les latches ne sont maintenus que sur des
pages de données présentes dans le buffer (alors que des verrous peuvent rester posés
sur des pages sur le disque), car toute page en cours d’utilisation physique est placée
dans le buffer. Cela aide ainsi à garantir une grande rapidité du latch.
Il existe aussi d’autres types de latches non-buffer, sur des structures internes.
Vous pouvez obtenir des statistiques sur la gestion des latches avec l’objet de
compteur de performances SQL:Latches.
Les latches d’entrées/sorties sont des types particuliers de latches de buffer, utilisés
pour la synchronisation entre les pages du buffer et les pages du disque, on les voit
dans les attentes de type PAGEIOLATCH. Ces attentes sont souvent typiques des latences du disque. Vous pouvez utiliser une requête comme celle-ci pour détecter ces
attentes :
SELECT wait_type,
waiting_tasks_count,
wait_time_ms
FROM sys.dm_os_wait_stats
WHERE wait_type like 'PAGEIOLATCH%'
ORDER BY wait_type
7.2.2 Granularité de verrouillage
Les verrous sont posés sur des ressources. Les verrous de données (il existe des
verrous posés sur des objets de code, pour éviter leur modification durant l’exécution) peuvent concerner les ressources suivantes : la ligne (ou la clé d’index), la
page, la table, et la base de données. On parle de granularité pour indiquer à quel
niveau de ressource s’effectue le verrouillage. En SQL Server, la granularité par
défaut est la ligne, ou la clé d’index. Cela permet de verrouiller le moins de
ressources possible et offre donc un excellent niveau de concurrence. Par exemple,
lors d’insertions, il prévient la contention sur la page qui se produit sur les tables
clustered dans les SGBDR dont la granularité minimale est la page.
Cette granularité comporte néanmoins un désavantage : si la commande affecte
un grand nombre de lignes, cela implique de poser un grand nombre de verrous.
Chaque verrou coûte du temps processeur et de la mémoire vive. Pour limiter les
coûts, SQL Server évalue le nombre de lignes à traiter, et lors de l’exécution, peut
convertir des verrous en granularité plus large. Pour saler le contenu de votre
assiette, vous prenez une pincée. Si vous devez saler la marmite d’un régiment, vous
versez à partir d’un grand sachet de sel, car le faire pincée par pincée vous prendrait
des heures.
Chapitre 7. Transactions et verrous
relationnel. Lorsqu’une ligne est lue, par exemple, SQL Server doit protéger non
seulement la ligne, mais également la page (pour éviter qu’une insertion ne modifie
l’en-tête qui indique l’offset de la ligne). Les latches ne sont maintenus que sur des
pages de données présentes dans le buffer (alors que des verrous peuvent rester posés
sur des pages sur le disque), car toute page en cours d’utilisation physique est placée
dans le buffer. Cela aide ainsi à garantir une grande rapidité du latch.
Il existe aussi d’autres types de latches non-buffer, sur des structures internes.
Vous pouvez obtenir des statistiques sur la gestion des latches avec l’objet de
compteur de performances SQL:Latches.
Les latches d’entrées/sorties sont des types particuliers de latches de buffer, utilisés
pour la synchronisation entre les pages du buffer et les pages du disque, on les voit
dans les attentes de type PAGEIOLATCH. Ces attentes sont souvent typiques des latences du disque. Vous pouvez utiliser une requête comme celle-ci pour détecter ces
attentes :
SELECT wait_type,
waiting_tasks_count,
wait_time_ms
FROM sys.dm_os_wait_stats
WHERE wait_type like 'PAGEIOLATCH%'
ORDER BY wait_type
7.2.2 Granularité de verrouillage
Les verrous sont posés sur des ressources. Les verrous de données (il existe des
verrous posés sur des objets de code, pour éviter leur modification durant l’exécution) peuvent concerner les ressources suivantes : la ligne (ou la clé d’index), la
page, la table, et la base de données. On parle de granularité pour indiquer à quel
niveau de ressource s’effectue le verrouillage. En SQL Server, la granularité par
défaut est la ligne, ou la clé d’index. Cela permet de verrouiller le moins de
ressources possible et offre donc un excellent niveau de concurrence. Par exemple,
lors d’insertions, il prévient la contention sur la page qui se produit sur les tables
clustered dans les SGBDR dont la granularité minimale est la page.
Cette granularité comporte néanmoins un désavantage : si la commande affecte
un grand nombre de lignes, cela implique de poser un grand nombre de verrous.
Chaque verrou coûte du temps processeur et de la mémoire vive. Pour limiter les
coûts, SQL Server évalue le nombre de lignes à traiter, et lors de l’exécution, peut
convertir des verrous en granularité plus large. Pour saler le contenu de votre
assiette, vous prenez une pincée. Si vous devez saler la marmite d’un régiment, vous
versez à partir d’un grand sachet de sel, car le faire pincée par pincée vous prendrait
des heures.