Le blog de SQLpro » verrou

Une peste nommée NOLOCK… et comment l’éviter

SQLpro — Sun, 08 Jul 2018 14:55:07 +0000

L’utilisation du tag de table NOLOCK, hélas largement prisé par de nombreux développeurs, est, la plupart du temps, une absurdité conduisant à des résultats potentiellement faux. Est-il possible de faire autrement pour minimiser les blocages induit par les verrouillages dans SQL Server ? Réponse OUI !

À la suite de cette remarque :
« …je passe aussi sur le NOLOCK qui est une véritable connerie en production et donne des valeurs fausses ! »
Publiée ici :

Mon interlocuteur me répondais :
« Merci pour cette précision. Comme vous abordez le sujet du NOLOCK effectivement j’ai constaté certaines fois en production on avait des valeurs totalement erronées, mais je n’arrivais pas à me l’expliquer. J’ai maintenant une piste et je vais creuser du côté du NOLOCK que nous utilisons beaucoup en production sur une base de données CRM 2013. Aussi par quoi pouvons nous remplacer le NOLOCK ?? »

Je lui donnais donc l’explication suivante…

Le « NOLOCK » peut parfaitement se remplacer par le niveau d’isolation SNAPSHOT par exemple…

NOLOCK ne signifie pas « je ne pose pas de verrou« , mais plus précisément : « j’ignore qu’il y a des verrous et je lit ce que je peut » (ceci est plus connu dans la littérature professionnelle sous le nom de lecture dans le chaos…). Vous pouvez donc lire plusieurs fois les mêmes données ou encore ne pas lire certaines.

Quid du mode SNAPSHOT ?

SNAPSHOT fait du verrouillage optimiste pour les lectures. Par défaut SQL Server fait du verrouillage pessimiste, c’est à dire que les lectures posent des verrous qui permettent d’autres lectures concurrentes (verrous partagés, mode « SHARE »), mais empêchent les écritures des autres utilisateurs. Conceptuellement, le verrouillage optimiste (donc via le mode d’isolation SNAPSHOT) fait une copie (si besoin) des données avant de permettre leurs lectures. Comme vous travaillez sur une copie, les utilisateurs concurrent peuvent modifier les vraies ligne sans que cela vous concerne. Bien entendu il peut toujours y avoir des conflits, mais cela réduit considérablement le nombre de verrous bloquants tout en gardant l’intégrité et la consistante de la base, ce qui n’est pas du tout le cas du NOLOCK.

Alors, à quoi sert le NOLOCK ?

Cela peut servir pour certains cas ou l’on désire des résultats dont on se fout de l’intégrité ou de la précision. Souvent dans le domaine de la statistique.
par exemple si vous voulez savoir combien les français ont d’enfant par foyer et scrutez donc, pour ce faire, une table de 60 millions de lignes (population française), je ne suis pas sûr que dans un camembert représentant la chose, on fasse la distinction des quelques pixels de l’imprécision de la 6e décimale du résultat liées à quelques mauvaises lectures de lignes !
On utilise d’ailleurs très souvent le NOLOCK pour des tâches d’administration systèmes dans SQL Server afin d’éviter tout blocage au risque de perdre quelques lignes, ce qui n’a pas toujours une importance capitale lorsque l’on veut remonter quelques informations concernant les 20% de requêtes les moins performantes !

Mais alors, le SNAPSHOT fait la même chose en mieux ?

Oui et non… Certes il permet de garantir l’intégrité, la consistance, etc… mais son mécanisme est plus lourd (un peu moins rapide) et consomme des ressources pour générer les copies (SNAPSHOT). Rassurez-vous il est assez malin pour ne faire ces copies qui s’il a besoin de les faire… En d’autres termes si aucun utilisateur concurrent veut faire des modif sur le jeu de lignes que vous manipulez en mode SNAPSHOT, aucune copie ne sera générée. Mais si, lorsque vous avez démarré une lecture en mode SNAPSHOT, un utilisateur concurrent veut modifier des lignes, et bien la copie sera réalisée au cours de votre lecture sans que vous vous en aperceviez… En quelque sorte le système fonctionne à l’envers… Bien évidemment il faut un espace de stockage pour ces copies et c’est la base tempdb qui s’y colle. Il faut donc, la dimensionner correctement…
Tiens, à nouveau un travail de DBA !

Des conflits ! Quels conflits ?

J’ai précédemment parlé de conflits possible avec l’utilisation du mode SNAPSHOT. En effet, si vous voulez modifier des données lors d’une transaction en mode d’isolation SNAPSHOT, c’est possible, mais ces modifications seront faites sur la copie, et non sur la base originale, et seront reportées sur la base originale au moment du COMMIT. Deux hypothèses se font alors jour :
■ soit aucune ligne visée par vos modifications faites en mode SNAPSHOT n’a été modifié dans une autre session directement sur la base, alors la mise à jour est appliquée.
Ou alors :
■ s’il existe au moins une ligne qui a été modifiée par une autre session entre temps sur la base originale, alors vos modifications ne pourront être appliquées aux données originales et vont êtres abandonnées.
Dans ce dernier cas vous obtiendrez une message d’erreur (3960) assez abscons, qui indique :
« La transaction d’isolement d’instantané a été abandonnée en raison d’un conflit de mise à jour. … »

Notez qu’il existe un autre tag plus intéressant que le NOLOCK…. Le READPAST !… Qui fait presque la même chose, mais ignore tout ce qui est verrouillé !

Les modes d’isolation selon la norme SQL

Sachez que le mode d’isolation SNAPSHOT ne fait pas partie de la norme SQL qui n’autorise que les modes d’isolation suivants :
0 – READ UNCOMMITTED : lecture des données invalides (non « committées »)
1 – READ COMMITTED : lecture de données valides (ce qui n’empêche pas certaines anomalies transactionnelles comme la lecture non répétable, ou l’apparition de lignes fantômes)
2 – REPEATABLE READ : lecture répétable de données (ce qui n’empêche pas certaines anomalies transactionnelles comme l’apparition de lignes fantômes)
3 – SERIALIZABLE : lecture en mode série (aucun accès concurrent aux tables lors des mises à jour, ce qui empêche toute anomalies)
Évidemment plus on monte le niveau d’isolation, plus le verrouillage est important et moins les accès concurrents peuvent travailler.
La norme SQL considère que les manipulation des données doivent porter sur des valeurs « vivantes ». Hors, en utilisant le mode SNAPSHOT et son versionnement des lignes, ont est appelé à lire potentiellement des valeurs antérieurs des données, ce n’est donc pas une lecture de l’état actuel des valeurs dans la base…

Pour informations, des SGBRD comme Oracle, ou PostGreSQL fonctionnent nativement en mode d’isolation SNAPSHOT, autrement dit utilisent systématiquement le verrouillage optimiste et ne savent pas faire autres choses (verrouillage pessimiste en particulier) voir ne savent même pas utiliser certains autres niveau d’isolation. Par exemple PostGreSQL ne permet pas de faires des transaction en mode READ UNCOMMITTED et Oracle ne permettent pas d’utiliser le niveau d’isolation REPEATABLE READ…

Activer le mode s’isolation SNAPSHOT

Pour permettre ce mode d’isolation, vous devez d’abord autoriser la base à utiliser le mode SNAPSHOT. Ce paramétrage est à deux niveaux :

ALTER DATABASE { CURRENT | nom_base } SET ALLOW_SNAPSHOT_ISOLATION ON;

permet d’utiliser à tout moment le mode d’isolation SNAPSHOT qui doit être introduit préalablement par la commande SET TRANSACTION ISOLATION SNAPSHOT ou par un tag de table (SNAPSHOT)
… et :

ALTER DATABASE { CURRENT | nom_base } SET READ_COMMITTED_SNAPSHOT ON;

qui place d’office toutes les lectures en mode SNAPSHOT (comme le fait Oracle ou PostGreSQL);
ATTENTION : pour assurer le versionnement des lignes, SQL Server rajoute à toutes les lignes de toutes les tables une information de version qui est codé sur 14 octets. Ceci peut prendre du temps à mettre en œuvre, en particulier sur de grosses bases.

Appendice :

Pour une démonstration des effets du NOLOCK : http://mssqlserver.fr/les-dangers-du-nolock/

Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES
Expert S.G.B.D relationnelles et langage S.Q.L
Moste Valuable Professionnal Microsoft SQL Server
Société SQLspot : modélisation, conseil, formation,
optimisation, audit, tuning, administration SGBDR
Enseignant: CNAM PACA, ISEN Toulon, CESI Aix en Prov.

L’entreprise SQL Spot
Le site web sur le SQL et les SGBDR

Déblocage d’une instance SQL Server bloquée

SQLpro — Thu, 12 Jan 2017 14:12:46 +0000

Il arrive, souvent à cause d’un mauvais développement (voir en gras italique plus loin), qu’un serveur SQL se bloque du fait des verrous. Une session en bloque autre qui en bloque plusieurs autres… et c’est l’effet boule de neige. La plupart du temps, les développeurs ou pseudo DBA réagissent mal en relaçant le service SQL Server ce qui fait perdre une grande partie des mises à jour demandées, empêchent les utilisateurs de travailler et pour peu qu’une longue transaction n’ai pas encore enregistrées les données, rend indisponible la base après le redémarrage du serveur, souvent pendant de longues minutes… Tout cela pouvant être évité avec un peu d’analyse et surtout la bonne requête que je vous présente, destinées à débloquer sans frustrer !

Un blocage est une situation normale dans une base de données, comme dans la vie courante. Les feux rouges, l’accès à des toilettes, les portiques de sécurité des aéroports, sont autant de points ou vous pouvez vous retrouvé bloqué pendant un certain temps, et cela est normal et fait partie de la vie. Les bases de données devant assurer la cohérence entre ceux qui lisent les données et ceux qui les écrivent, doivent poser des verrous afin de bloquer les utilisateurs concurrents dans certaines situations. Le principe est le suivant :

un utilisateur qui lit des données, doit bloquer l’accès aux utilisateurs qui veulent modifier les mêmes données, mais n’empêchent pas d’autres utilisateurs de lire en même temps les mêmes données. Dans ce cas la base pose un verrou partagé (shared), qui peut être pessimiste (posé préventivement) ou optimiste (actionné après coup).
un utilisateur qui écrit des données doit empêcher toute lecture et toute écriture concurrente. On parle alors de verrou exclusif.

Si une session doit faire différentes modification au sein d’une même transaction, les verrous vont être maintenus jusqu’à ce qu’intervienne la finalisation de la transaction, par un COMMIT (validation) ou un ROLLBACK (annulation). Pendant ce temps, si d’autres utilisateurs doivent accéder à ces données, il faut qu’ils patientent. C’est la notion de blocage. Un blocage est donc une situation normale dans une base de données, comme c’est le cas de madame Michu qui patiente dans sa 4L au feu rouge pour laisser passer les automobiliste de la voie latérale.
Ce qui n’est pas toujours normal, c’est un blocage qui dure, longtemps, voire, très, très longtemps… mais jamais de manière éternelle, car la situation doit se débouquer à la fin du traitement bloquant, c’est une certitude !
Dans ce cas, il est possible que d’autres utilisateurs se retrouvent bloqués, alors que même, ils ont déjà entamé des modification de données, susceptible d’entrainer d’autres blocages ! D’où l’effet boule de neige… Là encore cette situation peut être normale, si le bloqueur de tête met à jour une très importante quantité de données alors que beaucoup d’utilisateurs sont en train de parcourir ces mêmes données ! Mais dans bien des cas, c’est une situation anormale, généralement due à des mauvaises pratiques de développement, tel que des transaction démarré côté client, des transactions avec interactions de l’utilisateur, le forçage de verrous (les SGBDR se débrouillent généralement mieux tous seuls), des transactions non finalisées, l’usage d’un niveau d’isolation inappropriée, l’utilisation de code itératif eu lieu de code ensembliste, l’oubli de poser les index adéquats, l’utilisation de tables obèses, le recours systématique aux curseur, l’usage immodéré des déclencheurs, etc !
Bref, la question est, en présence d’un tel blocage, comment faire ?

LA SOLUTION

Elle consiste tout simplement à recherche qui bloque qui, et remonter jusqu’à bloqueur de tête pour le forcer à abandonner son traitement. Problème, cela nécessite de parcourir récursivement l’arbre de blocage de blocage… Second problème, il peut y avoir plusieurs chaines de blocage !
La DMV sys.dm_exec_requests permet de savoir qui bloque qui dans l’état actuel de l’instance. Les deux colonnes qui nous intéressent pour ce faire sont :

session_id : l’identifiant de la session en cours
blocking_session_id : l’identifiant de la session qui bloque

Différentes chaines de blocage de sessions dans SQL Server (en fait des arbres)

Dans la figure ci avant, les sessions 53 et 57 sont les leaders et bloquent respectivement :

pour le 53, 11 session avec une profondeur maximale de 5
pour le 57, 3 sessions avec une profondeur maximale de 3

Il faudrait débloquer en priorité le 53, attendre quelques instants pour voir si cela ne débloque pas le 57.

À partir de ces seules deux informations (session_id et blocking_session_id), nous pouvons remonter jusqu’aux bloqueurs de tête. L’écriture de cette requête doit procéder en deux temps :
rechercher les bloquers de tête, c’est à dire ceux qui ne sont pas bloqués par d’autres, mais qui en bloque d’autres. Une fois ces « leaders » trouvés, il suffit de descendre dans l’arbre de blocage pour comptabiliser le nombre de sessions bloquées et la profondeur du blocage.
Il suffit alors de tuer les « lead blockers » les plus prégnants, c’est à dire en général ceux qui bloquent le plus de session, ceux qui ont la plus grande profondeur de blocage, ceux dont le temps de traitement a été le plus long, ceux ayant consommé le plus d’IO, ceux ayant la requête la moins critique…. À vous de choisir !

La requête !

WITH
T_SESSION AS
(
-- on récupère les sessions en cours des utilisateurs
SELECT session_id, blocking_session_id
FROM sys.dm_exec_requests AS tout
WHERE session_id > 50
),
T_LEAD AS
(
-- on recherche les bloqueurs de tête
SELECT session_id, blocking_session_id
FROM T_SESSION AS tout
WHERE session_id > 50
AND blocking_session_id = 0
AND EXISTS(SELECT *
FROM T_SESSION AS tin
WHERE tin.blocking_session_id = tout.session_id)
),
T_CHAIN AS
(
-- requête récursive pour trouver les chaines de blocage
SELECT session_id AS lead_session_id, session_id, blocking_session_id, 1 AS p
FROM T_LEAD
UNION ALL
SELECT C.lead_session_id, S.session_id, S.blocking_session_id, p+1
FROM T_CHAIN AS C
JOIN T_SESSION AS S
ON C.session_id = S.blocking_session_id
),
T_WEIGHT AS
(
-- calculs finaux
SELECT lead_session_id AS LEAD_BLOCKER,
COUNT(*) -1 AS BLOCKED_SESSION_COUNT,
MAX(p) - 1 AS BLOCKED_DEEP,
'KILL ' + CAST(lead_session_id AS VARCHAR(16)) + ';' AS SQL_CMD
FROM T_CHAIN
GROUP BY lead_session_id
)
SELECT T.*,
DB_NAME(r.database_id) AS database_name, host_name, program_name,
nt_user_name,
q.text AS sql_command,
DATEDIFF(ms, last_request_start_time,
COALESCE(last_request_end_time, GETDATE())) AS duration_ms,
s.open_transaction_count,
r.cpu_time, r.reads, r.writes, r.logical_reads, r.total_elapsed_time
FROM T_WEIGHT AS T
JOIN sys.dm_exec_sessions AS s
ON T.LEAD_BLOCKER = s.session_id
JOIN sys.dm_exec_requests AS r
ON s.session_id = r.session_id
OUTER APPLY sys.dm_exec_sql_text(sql_handle) AS q
ORDER BY BLOCKED_SESSION_COUNT DESC, BLOCKED_DEEP DESC;

Cette requête présente les sessions bloquant les autres sessions, en déterminant la session à la tête d’une chaine de blocage (LEAD_BLOCKER), avec le nombre de sessions bloquées (BLOCKED_SESSION_COUNT) et la longueur maximale de la chaîne de blocage (BLOCKED_DEEP). Ceci permet de déterminer quelle session est à annuler en priorité en cas de blocage intempestif et d’utiliser la commande KILL (SQL_CMD) qui termine la session fautive en forçant un ROLLBACK. Les autres colonnes donnent des informations sur la requête qui a bloqué (texte SQL, base, origine du code, métriques diverses…)

ATTENTION
Ne pas confondre blocage et interblocage (ou étreinte fatale, ou encore verrou mortel…). Dans un interblocage, une session bloque des ressources qu’une autre session veut obtenir, tandis que cette même session demandeuse a bloqué des objets que la première a besoin. Dans ce cas, nous pouvons atteindre éternellement, car le blocage ne peut être résolu par l’attente. Le seul moyen consiste donc à sacrifier une des victimes de ce blocage et lui forçant une annulation de la transaction. Ceci est détecté automatiquement dans les bons SGBDR, qui procèdent automatiquement à l’achèvement d’une des victimes. Dans SQL Server, le message est intentionnellement significatif : « La transaction (ID de processus %1!) a été bloquée sur les ressources … par un autre processus et a été choisie comme victime. Réexécutez la transaction. »

LE CODE * LE CODE * LE CODE * LE CODE * LE CODE * LE CODE * LE CODE * LE CODE * LE CODE
Le code !

L’entreprise SQL Spot
Le site web sur le SQL et les SGBDR

Développez et administrez pour la performance avec SQL Server 2014