Trois audits, et ce qu'ils ont trouvé
Categories:
5 minutes à lire
Trois audits réels, anonymisés. Les mesures sont celles des collectes, aux dates indiquées.
Une distinction est tenue partout dans cette page, et elle compte : ce qui a été mesuré est écrit comme mesuré, ce que l’analyse calcule comme gain attendu est écrit comme attendu. Aucun chiffre de gain constaté après correction n’est avancé, parce qu’aucune de ces trois missions n’a encore fait l’objet d’une collecte de contrôle.
Un groupe industriel : une requête, et 7,8 % du processeur
Capture du 18 juin 2026, vingt-six minutes, 178 419 appels, 1 565 documents de facturation traités. Le progiciel est celui d’un éditeur tiers, et son SQL est généré.
Mesuré : une seule requête consomme 24,19 secondes de processeur pour 24,2 secondes de durée. Elle n’attend donc rien, elle sature un cœur, et comme sa consommation processeur n’excède pas sa durée, elle ne se répartit même pas sur les autres. Elle fait 9 637 784 lectures logiques pour rendre 1 053 lignes, soit 9 152 lectures par ligne et 23 millisecondes de processeur par ligne. À elle seule, elle pèse 7,8 % de tout le processeur du serveur sur la fenêtre.
Mesuré aussi, et cela change les conclusions : l’instance est intégralement en cache, avec 204 lectures physiques contre 14,7 millions de lectures logiques. Les neuf millions de lectures ne sont pas du disque, ce sont des parcours de pages en mémoire. Le gain à attendre est donc du processeur et du temps de traitement, pas de l’entrée-sortie, ce qui est un gain réel mais plus étroit que le volume brut ne le laisse croire.
Attendu, calculé par l’analyse : la réécriture récupère la quasi-totalité de ces 24 secondes. L’activation de l’isolation par instantané en lecture validée retire 51 % du temps de blocage mesuré et aurait évité 51 des 66 verrous mortels capturés, pour un coût de magasin de versions de quelques dizaines de mégaoctets. Le retrait des curseurs côté serveur vaut 9 à 14 % du temps de traitement par lot et 63 % des allers-retours réseau, mais seulement 3 % du processeur.
Ce dernier écart est la raison d’être d’un audit. Les trois changements sont présentés ensemble par l’intuition, et l’un d’eux vaut cinq fois les autres.
Un éditeur de logiciel : la fonctionnalité neuve qui traite 2,5 % du problème
Analyse du 28 juillet 2026, sur une capture des processus bloqués entre 8 heures et 20 heures.
Mesuré : 786 incidents de blocage distincts et 122,7 minutes d’attente bloquée sur la fenêtre. La question posée était celle d’une fonctionnalité annoncée dans SQL Server 2025 et présentée comme la réponse aux blocages.
Mesuré également, incident par incident : elle en adresse 20 sur 786, et
104,8 secondes sur 7 361, soit 2,5 % des incidents et 1,4 % du temps. La
première cause de blocage, 41,7 % du temps d’attente, est un embouteillage sur
des verrous de compilation, que le mécanisme ne touche pas. La deuxième, 39,1 %,
est une file d’attente sur des instructions MERGE, explicitement exclues.
Le vrai constat de ce dossier est ailleurs, et il n’a pas de prix affiché : 2 032 procédures sur 3 525, soit 58 %, forcent la lecture non validée, sur des données de santé. Le blocage était masqué, pas résolu.
Un audit sert autant à écarter une solution qu’à en proposer une. Le résultat négatif est celui qui a fait économiser une migration.
Une instance de gestion : payée en 2022, exécutée en 2016
Collecte du 27 août 2026, 106 secondes, 82 requêtes abouties, aucune permission manquante. C’est l’instance dont le compte rendu complet est publié comme exemple de livrable.
Mesuré :
- les quatre fichiers de tempdb écrivent à 1 694,7, 1 718,7, 1 720,0 et 1 862,0 millisecondes de moyenne. Une écriture sur tempdb prend une seconde et sept dixièmes ;
- 225 687 712 lectures d’enregistrements déplacés depuis le redémarrage, sur 18 tas, dont 198 152 342 sur une seule table de 46 464 519 lignes ;
- les 482 tables de la base applicative sont toutes des tas, aucune n’a de clé primaire, et il n’y a ni clé étrangère, ni contrainte de vérification, ni vue, ni procédure stockée ;
- les quatre configurations de portée base apportées par les versions 2019 et 2022 sont activées et sans effet, le niveau de compatibilité étant resté à celui de 2016.
Ce dernier point est le meilleur rapport entre ce qu’il coûte et ce qu’il rapporte de tout le dossier. La licence payée est celle de 2022, l’optimiseur qui s’exécute est celui de 2016, et l’écart se referme par une commande.
Une réserve, portée dans le compte rendu comme ici : 1 192 unités de stockage sur 1 193 sont sans compression, pour 52 285 Mo réservés et 645 millions de lignes, mais le gain de la compression n’a pas été estimé. La commande qui le chiffre n’a pas été exécutée pendant la collecte, donc aucun pourcentage n’est avancé.
Ce que ces trois dossiers ont en commun
Aucun des problèmes ci-dessus n’est matériel, et aucun ne se serait vu sans mesure. Dans les trois cas, l’instance avait déjà tout ce qu’il fallait pour dire ce qui n’allait pas.