Lorsque vous activez l' option " Optimiser pour les charges de travail ad hoc ", les requêtes ad-hoc exécutées la deuxième fois sont aussi lentes que la première, car vous allez compiler un plan d'exécution et extraire les mêmes données ( sans le mettre en cache) ces 2 premières fois.
Ce n'est peut-être pas grave, mais vous le remarquerez lors du test des requêtes.
Alors que se passe-t-il maintenant, sans cette option activée et un cache plein de requêtes Ad-Hoc 1-Off?
L'algorithme de gestion de la mise en cache:
Lorsque cette fonctionnalité d'optimisation a été introduite, l'algorithme de gestion de la mise en cache a également été mis à jour.
L'article de Kimberly Tripp fait également référence à l'article de Kalen Delaney sur ce changement d'algorithme.
Elle explique le mieux:
La modification calcule en fait une taille de cache de plan à laquelle SQL Server reconnaît qu'il existe une pression de mémoire et commence à supprimer les plans du cache. Les plans à supprimer sont les plans bon marché qui n'ont pas été réutilisés, et c'est une bonne chose.
Cela signifie que ces plans fastidieux à minuterie unique seront les premiers à disparaître lorsque vous aurez besoin de libérer des ressources.
Alors maintenant, la question devient:
« Pourquoi avons-nous besoin « Optimize pour les workloads ad hoc » lorsque SQL Server prend en charge la suppression des plans non utilisés en cas de besoin? »
Ma réponse à cette question est, si vous avez régulièrement une s-tonne de oodles de production-sql dynamiques de publicité non-paramétrés -hoc, il est donc logique d'activer cette fonctionnalité.
Vous souhaitez éviter de surcharger les ressources système, de manière à forcer la suppression de la planification / du plan mis en cache une fois que vous avez utilisé au maximum la mémoire cache.
Comment savoir quand j'ai besoin de l'activer?
Voici une requête que j'ai écrite pour vous montrer combien de plans ad-hoc que vous avez actuellement mis en cache et combien d'espace disque ils consomment (les résultats changeront au cours de la journée - testez-le pendant une période de forte charge):
--Great query for making the argument to use "Optimize for Ad Hoc Workloads":
SELECT S.CacheType, S.Avg_Use, S.Avg_Multi_Use,
S.Total_Plan_3orMore_Use, S.Total_Plan_2_Use, S.Total_Plan_1_Use, S.Total_Plan,
CAST( (S.Total_Plan_1_Use * 1.0 / S.Total_Plan) as Decimal(18,2) )[Pct_Plan_1_Use],
S.Total_MB_1_Use, S.Total_MB,
CAST( (S.Total_MB_1_Use * 1.0 / S.Total_MB ) as Decimal(18,2) )[Pct_MB_1_Use]
FROM
(
SELECT CP.objtype[CacheType],
COUNT(*)[Total_Plan],
SUM(CASE WHEN CP.usecounts > 2 THEN 1 ELSE 0 END)[Total_Plan_3orMore_Use],
SUM(CASE WHEN CP.usecounts = 2 THEN 1 ELSE 0 END)[Total_Plan_2_Use],
SUM(CASE WHEN CP.usecounts = 1 THEN 1 ELSE 0 END)[Total_Plan_1_Use],
CAST((SUM(CP.size_in_bytes * 1.0) / 1024 / 1024) as Decimal(12,2) )[Total_MB],
CAST((SUM(CASE WHEN CP.usecounts = 1 THEN (CP.size_in_bytes * 1.0) ELSE 0 END)
/ 1024 / 1024) as Decimal(18,2) )[Total_MB_1_Use],
CAST(AVG(CP.usecounts * 1.0) as Decimal(12,2))[Avg_Use],
CAST(AVG(CASE WHEN CP.usecounts > 1 THEN (CP.usecounts * 1.0)
ELSE NULL END) as Decimal(12,2))[Avg_Multi_Use]
FROM sys.dm_exec_cached_plans as CP
GROUP BY CP.objtype
) AS S
ORDER BY S.CacheType
Résultats:
Je ne vais pas dire " Quand vous avez X MB " ou " Si X% de vos Ad Hoc sont à usage unique " pour l'activer.
Cela n'affecte pas les Sprocs, les déclencheurs, les vues ni les instructions SQL préparées / préparées, mais uniquement les requêtes ad hoc.
Ma recommandation personnelle est simplement d'activer votre environnement de production, mais d'envisager de le laisser dans votre environnement de développement.
Je ne dis cela que pour Dev, car si vous optimisez une requête qui prend une minute ou plus à s'exécuter, vous ne voulez pas l'exécuter 3 fois avant de voir à quelle vitesse elle ira avec elle mise en cache - chaque Une seule fois, vous la modifiez pour trouver la meilleure conception d'optimisation.
Si votre travail ne consiste pas à le faire toute la journée, allez-y et demandez à votre DBA de l'activer partout.