Identifier les allocations excessives de mémoire
Dans le cas où un plan d’exécution doit effectuer un tri, ou construire un tableau de hachage en mémoire, le moteur d’optimisation doit évaluer le mémoire à réserver pour ces opérations.
Prenons les requête d’exemple suivante.
SELECT *
FROM Contact.Contact c
ORDER BY c.Nom, c.Prenom;
Il s’agira, pour SQL Server, de réserver suffisament de mémoire pour placer toute la table (on demande tout avec un SELECT *) et effectuer le tri.
L’estimation du volume de mémoire à réserver dépend de l’estimation de la cardinalité et de la taille des données. Une mauvaise estimation peut donc avoir deux causes :
- une mauvaise estimation de cardinalité ;
- un mauvais dimensionnement des types variables.
Allocations excessives
Par exemple, si vous définissez systématiquement vos colonnes varchar à une taille maximum trop grand, comme varchar(max), vous forcez l’optimiseur à demander trop de mémoire.
Les informations de mémoire réservée, et réellement utilisées, sont visibles dans le plan d’exécution réalisé.
Vous pouvez tracer les opérations d’utilisation de cette mémoire avec l’évènement qlserver.query_memory_grant_usage, en récupérant le script sur mon Github.
Soyez notamment attentif au champ d’évènement usage_percent.
Spills dans Tempdb
Une sous-allocation peut provoquer des jets de tris ou de hachages sur le disque, dans Tempdb.