Le Blog SQL Server d'ElSüket » lock

L’escalade de verrous

elsuket — Sun, 07 Jul 2013 12:09:41 +0000

Quoi de plus naturel pour un moteur de base de données relationnelles SQL que le verrouillage ? En effet, toute exécution de requête entraîne l’acquisition de verrous. Comme je me rends compte que c’est un sujet quelque peu méconnu, je vous propose ici d’explorer dans quelles conditions une escalade de verrous se produit, après avoir succinctement décrit ce qu’est le verrouillage.

Qu’est-ce que le verrouillage ?

Le verrouillage est un mécanisme qui permet à plusieurs utilisateurs d’accéder à des ressources, tout en évitant que cela résulte en des incohérences de données. Des verrous sont acquis lorsque le moteur de base de données a besoin d’accéder à une ressource pour la lire ou la modifier. Sous SQL Server, cette opération est purement logique, et sert le support de l’ACIDité de toute transaction.

Ce mécanisme est entièrement géré par le moteur de stockage de SQL Server, avec lequel l’utilisateur n’a que peu de moyens d’interagir (et tant mieux !).
On peut bien sûr affecter le comportement d’une transaction en indiquant le niveau d’isolation de transaction sous lequel elle doit être traitée. Il est rarement nécessaire d’indiquer à SQL Server quel doit être le type de verrouillage à choisir à l’aide d’indicateurs de table ou de requête. SQL Server a de toute façon la primauté sur ce choix, puisqu’il outrepasse parfois les recommandations du développeur ou du DBA. Globalement, le moteur de base de données SQL Server effectue le meilleur choix.

Tout ceci fait qu’outre le niveau d’isolation de transaction, lorsqu’on code pour SQL Server, on n’a pas à se soucier de ce que telle ou telle opération DML va produire en termes de verrouillage. Cependant, l’accès concurrent à une même ressource provoque parfois des situations de blocage, voire d’étreinte mortelle (deadlock) : il est alors nécessaire de comprendre ce qui a provoqué cette situation pour pouvoir orienter les choix de SQL Server, de sorte à éviter qu’un tel phénomène se reproduise. A ce titre, il est nécessaire de savoir :

– quelles sont les ressources sur lesquelles les transactions acquièrent des verrous (ligne ou clé ou page, partition, table, schéma, base de données)
– quel est le type de verrou qui a été acquis sur la ressource (intentionnel, partagé, de mise à jour, exclusif, de copie en bloc)

Dans quelles conditions une escalade de verrou se produit-elle ?

SQL Server choisit toujours d’acquérir des verrous de faible granularité, de façon à maximiser la concurrence d’accès. Donc la plupart du temps, SQL Server acquiert des verrous de ligne/clé, ou de page. Il faut noter que l’acquisition de verrous se fait directement soit au niveau ligne/clé, soit au niveau page : l’escalade de verrous ne se fait jamais de ligne/clé à page. En effet, si le moteur de base de données a calculé qu’il devra accéder à toutes les lignes d’un jeu de pages, autant qu’il acquière un unique verrou sur chacune desdites pages. Tout verrou, quelle que soit sa granularité, consomme 96 octets de mémoire, et est une structure purement logique.

Le principe général de l’escalade de verrou est de remplacer un grand nombre de verrous par un verrou de plus forte granularité, de façon à consommer moins de mémoire. Cela se fait au détriment de la concurrence d’accès, mais en faveur :

– de la vitesse d’exécution : un verrous a forte granularité est acquis pour une durée plus courte
– mais aussi et surtout de la consommation de mémoire : moins on acquiert de verrous, moins on consomme de mémoire.

Au niveau requête, l’escalade est réalisée dès qu’elle acquiert ou requiert plus de 5000 verrous.

Au niveau instance, lorsque SQL Server détecte que la gestion des verrous consomme 24% de la taille du cache de données (à l’exclusion de la mémoire AWE sur les systèmes x86), il va scruter les sessions qui en détiennent en grand nombre, et escalader les verrous de celles-ci. Par ailleurs, l’option de configuration locks permet de contrôler l’escalade de verrous : si la valeur configurée est différente zéro (valeur par défaut), alors SQL Server réalisera une escalade de verrous dès que 40% de cette valeur en nombre de verrous acquis ou requis est dépassée. Il réalisera ensuite une nouvelle escalade de verrous après chaque bloc de 1250 verrous acquis ou requis dans ces conditions. L’utilisateur n’a aucun contrôle sur les sessions que SQL Server va sélectionner pour l’escalade de verrous, mais gageons que comme pour bien d’autres fonctionnalités, il n’ait pas besoin d’aide.

Enfin, si la gestion des verrous consomme 60% de la mémoire allouée à SQL Server à travers l’option max server memory (MB), ce dernier peut prendre la décision d’annuler une ou plusieurs requêtes responsables de cette grande consommation. Dans ce cas, les requêtes impactées lèvent une exception de numéro 1204, dont le libellé est le suivant :

L’instance du moteur de base de données SQL Server ne peut pas obtenir une ressource LOCK en ce moment. Réexécutez votre instruction lorsque le nombre d’utilisateurs actifs est moindre. Demandez à l’administrateur de base de données de vérifier la configuration du verrou et de la mémoire pour cette instance, ou de vérifier les longues transactions.

ou en Anglais :

The instance of the SQL Server Database Engine cannot obtain a LOCK resource at this time. Rerun your statement when there are fewer active users. Ask the database administrator to check the lock and memory configuration for this instance, or to check for long-running transactions.

Cette erreur est aussi écrite dans les journaux de SQL Server.

Quelques requêtes

La DMV sys.dm_os_memory_clerks nous permet de trouver la taille du gestionnaire de verrous. Voici la requête pour jusqu’à SQL Server 2008 R2 inclus :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
GO

SELECT type
, name
, SUM(single_pages_kb) AS cache_size_from_buffer_pool_KB
, SUM(multi_pages_kb) AS cache_size_out_buffer_pool_KB
FROM sys.dm_os_memory_clerks
--WHERE name LIKE 'Lock Manager%'
GROUP BY type, name
ORDER BY security_token_cache_size_from_buffer_pool_KB DESCcode>

Et dès SQL Server 2012 :

<code>SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
GO

SELECT type
, name
, SUM(pages_kb) AS cache_size_KB
FROM sys.dm_os_memory_clerks
--WHERE name LIKE 'Lock Manager%'
GROUP BY type, name
ORDER BY cache_size_KB DESC

On trouve un gestionnaire de verrous par noeud NUMA. Si nous laissons la clause WHERE de ces deux requêtes en commentaire, on doit trouver CACHESTORE_SQLCP et CACHESTORE_OBJCP sur les deux premières lignes du résultat de la requête, puisque le premier représente le cache de plan de requêtes ad-hoc ou en SQL dynamique, et le second celui des procédures stockées et déclencheurs. Si on y trouve OBJECTSTORE_LOCK_MANAGER, c’est que le gestionnaire de verrous consomme probablement une trop grande quantité de mémoire.

LOCK_ESCALATION : cas des tables partitionnées

Dès SQL Server 2008, il est possible de réaliser l’escalade de verrous au niveau partition, avant que celle-ci se produise au niveau table. Mais pour ce faire, il est nécessaire que celle-ci soit positionnée à AUTO : or par défaut, elle est à TABLE. On trouve les tables candidates à ce changement à l’aide de la requête suivante :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

;WITH
PARTITIONNED_TABLE AS
(
SELECT DISTINCT object_id
FROM sys.dm_db_partition_stats
WHERE partition_number > 1
)
SELECT S.name + '.' + T.name AS table_or_indexed_view_name
, T.lock_escalation_desc
, CASE T.lock_escalation_desc
WHEN 'TABLE' THEN 'ALTER TABLE ' + S.name + '.' + T.name + ' SET (LOCK_ESCALATION = AUTO)'
ELSE NULL
END AS sql_change_lock_escalation_level
FROM sys.schemas AS S
INNER JOIN sys.tables AS T
ON S.schema_id = T.schema_id
INNER JOIN PARTITIONNED_TABLE AS PT
ON PT.object_id = T.object_id
--WHERE T.lock_escalation_desc = 'TABLE'

Bon verrouillage à tous !

ElSüket.

Auditer les processus bloqués : l’événement blocked process report

elsuket — Sat, 15 Jun 2013 10:46:31 +0000

SQL Server 2005 a introduit un évènement capturable par SQL Profiler et par les Notifications d’évènements, qui permet de retrouver les processus qui ont été bloqués. Avec la sortie de SQL Server 2008 et l’introduction des Évènements Étendus, il nous est également possible de capturer cet évènement.

Dans cet article, je vous propose de voir comment paramétrer SQL Server pour capturer cet évènement, puis de vous aider à interpréter le document XML qui décrit la situation de blocage.

Toute exécution de requête résulte en l’acquisition de verrous, dont la granularité (ligne, page, clé, partition, table, base de données, ou encore et plus rarement compilation) et le mode (partagé, exclusif, de mise à jour, ou d’intention) varient. Le verrouillage de ressources est une opération de base pour le moteur de stockage de tout moteur de bases de données SQL, qui garantit l’intégrité de la base de données à travers toutes les opérations de manipulation de données que celle-ci supporte. Cependant, il arrive que lorsqu’un processus a posé un verrou sur une ressource, d’autres processus doivent simultanément accéder à cette même ressource : ces processus sont alors bloqués. Comme il est possible que le processus bloquant ne libère ledit verrou qu’après une durée relativement longue, les effets possibles d’une telle situation sur nos applications peuvent aller de requêtes dont la durée d’exécution est élevée jusqu’à l’expiration du délai d’attente d’une réponse pour l’exécution d’un requête : le fameux timeout.

Il est néanmoins possible, à l’aide d’une trace SQL Profiler ou des Évènements Étendus, de capturer ces situations, qui sont décrites par un document XML.

Configurer l’instance SQL Server

Le seuil de durée de blocage à partir de laquelle on souhaite capturer un tel évènement est configurable à l’aide de l’option d’instance blocked process threshold. On accède à ce paramètre :

– soit à l’aide de SQL Server Management Studio (SSMS), après un clic-droit sur l’instance dans l’Explorateur d’Objets (F8), et avoir choisi l’option Propriétés :

– soit à l’aide de la procédure stockée système sp_configure :

1
2
3

SELECT *
FROM sys.configurations
WHERE name LIKE '%block%'

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

-- Activation de la modification d'options d'instance avancées
EXEC sys.sp_configure 'show advanced options', 1
GO
RECONFIGURE
GO

-- Configuration du seuil de durée de blocage à 5 secondes
EXEC sys.sp_configure 'blocked process threshold', 5
GO
RECONFIGURE;
GO

-- Désactivation de la modification d'options d'instance avancées
EXEC sys.sp_configure 'show advanced options', 0
GO
RECONFIGURE
GO

La console de SSMS affiche, à l’exécution de ce lot de requêtes :

Veillez à ne pas mettre un seuil trop bas : sans cela, on aurait le processus d’arrière plan LOCK MONITOR qui s’exécuterait constamment. Or ce dernier, qui est aussi en charge de détecter les deadlocks, est gourmand en ressources CPU. En s’exécutant fréquemment, il pourrait donc impacter négativement les performances générales de l’instance SQL Server. D’un autre côté, 5 secondes est une durée très longue sur une base de données qui supporte une charge de travail OLTP conséquente. On trouve ce processus avec la requête suivante :

1
2
3
4
5
6
7
8

SELECT session_id
, status
, command
, wait_type
, wait_time
, last_wait_type
FROM sys.dm_exec_requests
WHERE command = 'LOCK MONITOR'

Si l’on exécute maintenant cette requête de façon répétée, on voit que la valeur de la colonne wait_time croit jusqu’à atteindre 5000, mais ne dépasse jamais cette valeur : cette colonne affiche sa valeur en millisecondes, et montre bien que le processus cherche les processus bloqués toutes les 5 secondes.

Il faut aussi noter qu’avec cette configuration, si un processus reste bloqué 15 secondes, l’évènement sera généré 3 fois pour la même situation de blocage.

Capture avec SQL Profiler

Une fois cela fait, nous démarrons SQL Profiler, et dans l’onglet de sélection des évènements, dans la catégorie Errors and Warnings (et non pas dans la catégorie Locks), nous trouvons l’évènement Blocked process report :

Nous configurons l’évènement comme suit, où le champ TextData contiendra le document XML décrivant la situation de blocage :

N.B. : N’oubliez pas le champ Mode, qui procure le type de verrou acquis.

Capture avec les Évènements Étendus (XE)

Pour les lecteurs qui n’ont pas encore eu le temps de se familiariser avec cette fonctionnalité, qui est vouée au remplacement futur de SQL Profiler, et dont la puissance en fait mon outil de diagnostic favori, vous pouvez vous aider de l’article que j’ai publié sur le sujet.

Si l’on souhaite capturer en permanence toute situation de blocage, l’avantage revient à XE, puisqu’on peut stocker ces évènements dans une cible dite anneau de mémoire (ring buffer). Cette structure consomme très peu de mémoire et fonctionne à l’image d’un FIFO : lorsqu’il est plein, la capture d’un nouvel évènement donne lieu à l’éviction du plus vieil évènement pour le stockage de celui-ci. Avec SQL Profiler, il est nécessaire de mettre en place une trace côté serveur et de gérer le fichier de trace et l’espace disque. En revanche, une fois que l’on a démarré la session XE, on peut « l’oublier ».

Pour les lecteurs familiers de XE et de Profiler, sachez que le document XML produit par ces deux fonctionnalités pour un même évènement de blocage est identique, ce qui n’est pas le cas avec les deadlocks (XE produit un document XML mal formé, qui rend impossible son enregistrement en document de type .xdl en vue de son interprétation graphique dans SSMS).

La définition d’une telle session est simple :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

-- Définition de la session
CREATE EVENT SESSION blocked_process_report_RB ON SERVER
ADD EVENT sqlserver.blocked_process_report
ADD TARGET package0.ring_buffer (SET MAX_MEMORY = 4096)
WITH (MAX_DISPATCH_LATENCY = 5 SECONDS)
GO

-- Démarrage de la session
ALTER EVENT SESSION blocked_process_report_RB ON SERVER
STATE = START

-- Vérification
SELECT name
, create_time
FROM sys.dm_xe_sessions
WHERE name = 'blocked_process_report_RB'

Le test

Pour l’exemple, nous avons la trace SQL Profiler et la session XE ci-dessus actifs.
Nous créons la table suivante :

1
2
3
4
5
6

CREATE TABLE blocked_process_report_test
(
cle varchar(16) NOT NULL
CONSTRAINT UQ_blocked_process_report_test UNIQUE CLUSTERED
, valeur tinyint NOT NULL
)

Puis, dans une première fenêtre de requête (A) sous SSMS, nous ajoutons la ligne suivante, sans valider la transaction :

1
2
3
4
5
6
7
8
9
10
11

BEGIN TRANSACTION
INSERT INTO dbo.blocked_process_report_test
(
cle
, valeur
)
VALUES
(
'TEST'
, 12
)

Dans une seconde fenêtre de requête (B), nous exécutons :

1
2
3

UPDATE dbo.blocked_process_report_test
SET valeur = 15
WHERE cle = 'TEST'

Ceci fait que la requête B doit attendre que la requête A soit terminée pour réaliser l’UPDATE, ce qui ne peut se faire que si l’on valide (COMMIT) ou annule (ROLLBACK) la transaction : nous ne le faisons pas ici, pour l’exemple. Nous laissons aussi la requête B s’exécuter 10 secondes, de façon à bien voir que l’évènement est capturé deux fois pour la même situation de blocage.

Ce que capture SQL Profiler

L’interface affiche bien deux captures de l’évènement :

Notez que les valeurs pour la colonne Duration sont données ici en microsecondes : on voit donc qu’il y a un léger décalage entre la détection du blocage et sa capture. Toutes les informations dont nous avons besoin sont donc sous nos yeux: la ressource à la source de la situation de blocage, ainsi que les requêtes impliquées dans celle-ci.

Il est possible de charger le fichier de trace dans une table à l’aide de la fonction sys.fn_trace_gettable(). Cela permet l’écriture d’une requête utilisant les méthodes SQLXML, qui extrait directement les informations intéressantes de chaque document XML. La requête est similaire à celle que je donne dans la section suivante.

Ce que capture la session XE

Ici il nous est nécessaire d’écrire une requête faisant appel aux fonctions SQLXML pour dépouiller le document XML sans se fatiguer :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

SELECT DATEADD(hour, DATEDIFF(hour, GETUTCDATE(), GETDATE()), doc.value('(event/@timestamp)[1]', 'datetime')) AS log_date_time
, doc.value('(event/data[@name="transaction_id"]/value)[1]', 'bigint') AS transaction_id
, doc.value('(event/data[@name="database_name"]/value)[1]', 'nvarchar(128)') AS database_name
, doc.value('(event/data[@name="duration"]/value)[1]', 'int') / 1000 AS duration_ms
, doc.value('(event/data[@name="resource_owner_type"]/text)[1]', 'varchar(10)') AS resource_owner_type
, doc.value('(event/data[@name="lock_mode"]/text)[1]', 'varchar(10)') AS lock_mode
, doc.value('(event/data[@name="blocked_process"]/value/blocked-process-report/blocked-process/process/@waitresource)[1]', 'varchar(max)') AS wait_resource
, doc.value('(event/data[@name="blocked_process"]/value/blocked-process-report/blocked-process/process/@isolationlevel)[1]', 'varchar(max)') AS blocked_tran_iso_level
, doc.value('(event/data[@name="blocked_process"]/value/blocked-process-report/blocking-process/process/@isolationlevel)[1]', 'varchar(max)') AS blocking_tran_iso_level
, doc.value('(event/data[@name="blocked_process"]/value/blocked-process-report/blocked-process/process/inputbuf)[1]', 'varchar(max)') AS blocked_statement
, doc.value('(event/data[@name="blocked_process"]/value/blocked-process-report/blocking-process/process/inputbuf)[1]', 'varchar(max)') AS blocking_statement
FROM (
SELECT D.n.query('.') AS doc
FROM (
SELECT CAST(target_data AS xml) AS data
FROM sys.dm_xe_sessions AS S
INNER JOIN sys.dm_xe_session_targets AS ST
ON S.address = ST.event_session_address
WHERE S.name = 'blocked_process_report_RB'
AND ST.target_name = 'ring_buffer'
) AS sub
CROSS APPLY data.nodes('RingBufferTarget/event') AS D(n)
) AS T

La capture d’écran du résultat a été coupée en deux pour faciliter un peu la lecture :

Interprétation du résultat

Notre intérêt dans l’interprétation de ce document se portera sur la propriété waitresource, que l’on peut décrypter à l’aide de la documentation (Voir la section Waitresource).

Ici, waitresource est : KEY: 5:72057594039107584 (2158b2b5a6d5), ce qui signifie :

– Database ID : 5
– Partition ID : 72057594039107584
– (2158b2b5a6d5) : le hash de la clé d’index

Sur ce dernier point, il faut savoir que SQL Server utilise le hash, stocké sur 6 octets, de la clé de l’index qui supporte la requête. Ceci conduit SQL Server à générer des valeurs de hash identiques pour des valeurs de clé différentes, ce qui peut causer d’autre problèmes de concurrence d’accès. C’est une raison de plus pour choisir des clés d’index les plus « étroites » possible, de façon à éviter ce type de collisions.

Voyons comment retrouver la ressource qui a été verrouillée :

1
2
3
4
5
6
7
8
9
10
11
12
13
14

USE ELSUKET
GO

SELECT O.name AS table_name
, I.name AS index_name
, P.partition_number
, P.rows
FROM sys.partitions AS p
INNER JOIN sys.objects AS O
ON O.object_id = P.object_id
INNER JOIN sys.indexes AS I
ON P.object_id = I.object_id
AND P.index_id = I.index_id
WHERE p.partition_id = 72057594039107584

Voyons maintenant comment retrouver la clé qui a été utilisée :

1
2
3

SELECT *
FROM dbo.blocked_process_report_test WITH(INDEX = UQ_blocked_process_report_test)
WHERE %%lockres%% = '(2158b2b5a6d5)'

La fonction %%lockres%% n’est pas documentée : il est donc recommandé de l’utiliser avec parcimonie. La même méthodologie est utilisable dans le diagnostic des deadlocks.

Bon déblocage à tous !

ElSüket.

Cadeau de Noël de Kalen Delaney : un livre sur le verrouillage, le blocage et le versionnement de ligne

elsuket — Sat, 22 Dec 2012 07:24:37 +0000

Le site de RedGate, créé par Bard Mc Gehee, publie depuis quelques années déjà de nombreux ouvrages, dont certains abordent des thèmes que l’on voit rarement explorés en détails, parfois même par les mêmes auteurs chez d’autres éditeurs.

Vous n’avez plus grand chose à vous mettre sous la dent après avoir lu comment fonctionne l’optimiseur de requêtes ? On ne peut pas déclarer cela sérieusement avec la sortie récente de SQL Server 2012, et de ses nombreuses innovations ou améliorations

Malgré toutes ces nouveautés à décortiquer, les fondamentaux du fonctionnement de SQL Server demeurent. Donc pour Noël, Kalen Delaney nous fait le cadeau de son dernier ouvrage, SQL Server Concurrency: Locking, Blocking and Row Versioning, et que l’on peut déjà télécharger gratuitement en PDF (d’habitude RedGate ne le permet qu’après quelques mois).

Bonne lecture de Noël à tous !