307
9.3 Cache des requêtes ad hoc
Cache des requêtes ad hoc
Nous l’avons vu, les procédures ne sont pas seules à être cachées, tout plan d’exécution d’une requête isolée est potentiellement réutilisable. Une première réaction
serait de penser que cette fonctionnalité rend la procédure stockée moins intéressante, puisque toutes les requêtes peuvent profiter d’un cache de leur plan d’exécution. Ce n’est pas vraiment le cas, la procédure reste nettement plus performante,
non seulement par les avantages que nous avons déjà abordés (diminution du trafic
réseau, centralisation du code, sécurité facilitée), mais aussi parce que le cache de
requêtes est soumis à quelques contraintes. Nous allons le voir.
Lorsqu’une requête ad hoc (c’est-à-dire un ordre SQL composé par le client, par
opposition à du code stocké sur le serveur comme une procédure) est envoyée au serveur, SQL Server essaie de trouver une correspondance de texte de requête dans le
cache SQLMGR. Cette correspondance est recherchée en comparant le hachage
généré par la requête entrante avec les hachages présents dans le cache, puisque ces
chaînes de hachages représentent un résumé de toute la requête cachée. Cela permet
d’effectuer une recherche très rapide, mais cela signifie aussi que la moindre différence de syntaxe invalide la recherche, puisqu’elle produit un résultat de hachage
différent. Une espace de plus, une différence de casse dans la requête (même sur un
serveur dont la collation par défaut est insensible à la casse, cela n’a pas de rapport
avec la gestion du cache) suffit à générer une nouvelle entrée dans le cache. Vérifions-le simplement :
DBCC FREEPROCCACHE
GO
SELECT * FROM dbo.test
GO
SELECT * FROM dbo.test
GO
SELECT * FROM dbo.TEST
GO
select * from dbo.test
GO
SELECT
cp.usecounts,
cp.size_in_bytes,
st.text
FROM sys.dm_exec_cached_plans cp
OUTER APPLY sys.dm_exec_sql_text (cp.plan_handle) st
JOIN sys.dm_exec_query_stats qs ON qs.plan_handle = cp.plan_handle
GO
Le code suivant provoque l’insertion de quatre entrées de cache, comme nous
pouvons le constater dans la figure 9.5.
9.3 Cache des requêtes ad hoc
Cache des requêtes ad hoc
Nous l’avons vu, les procédures ne sont pas seules à être cachées, tout plan d’exécution d’une requête isolée est potentiellement réutilisable. Une première réaction
serait de penser que cette fonctionnalité rend la procédure stockée moins intéressante, puisque toutes les requêtes peuvent profiter d’un cache de leur plan d’exécution. Ce n’est pas vraiment le cas, la procédure reste nettement plus performante,
non seulement par les avantages que nous avons déjà abordés (diminution du trafic
réseau, centralisation du code, sécurité facilitée), mais aussi parce que le cache de
requêtes est soumis à quelques contraintes. Nous allons le voir.
Lorsqu’une requête ad hoc (c’est-à-dire un ordre SQL composé par le client, par
opposition à du code stocké sur le serveur comme une procédure) est envoyée au serveur, SQL Server essaie de trouver une correspondance de texte de requête dans le
cache SQLMGR. Cette correspondance est recherchée en comparant le hachage
généré par la requête entrante avec les hachages présents dans le cache, puisque ces
chaînes de hachages représentent un résumé de toute la requête cachée. Cela permet
d’effectuer une recherche très rapide, mais cela signifie aussi que la moindre différence de syntaxe invalide la recherche, puisqu’elle produit un résultat de hachage
différent. Une espace de plus, une différence de casse dans la requête (même sur un
serveur dont la collation par défaut est insensible à la casse, cela n’a pas de rapport
avec la gestion du cache) suffit à générer une nouvelle entrée dans le cache. Vérifions-le simplement :
DBCC FREEPROCCACHE
GO
SELECT * FROM dbo.test
GO
SELECT * FROM dbo.test
GO
SELECT * FROM dbo.TEST
GO
select * from dbo.test
GO
SELECT
cp.usecounts,
cp.size_in_bytes,
st.text
FROM sys.dm_exec_cached_plans cp
OUTER APPLY sys.dm_exec_sql_text (cp.plan_handle) st
JOIN sys.dm_exec_query_stats qs ON qs.plan_handle = cp.plan_handle
GO
Le code suivant provoque l’insertion de quatre entrées de cache, comme nous
pouvons le constater dans la figure 9.5.