Permettez-moi de résumer (et d'arrondir!) Les points de données importants dans votre feuille de calcul:
Total Use Count 1
--------------------------------------- -----------------------
Total Plans Total MBs Avg Use Count Total Plans Total MBs
----------- --------- ------------- ----------- ---------
Adhoc 55,987 3,054 3 38,314 2,036
Proc 709 1,502 1,549 135 527
Ainsi, la première ligne montre les mauvaises choses, occupant environ les 2/3 de votre cache de plan (des choses qui ne sont généralement utilisées qu'une seule fois, à quelques exceptions très mineures). Vous devez essayer de vous en débarrasser autant que possible. La deuxième rangée montre les bonnes choses. Ce sont les choses que vous voulez dans votre cache de plan (plans avec une grande quantité de réutilisation). Le reste des données est en grande partie hors de propos à mon humble avis. Un autre point cependant: vous dites que l'accès se fait exclusivement via des procédures stockées, mais si ces procédures utilisent du SQL dynamique, ces instructions sont mises en cache en tant que AdHocplans, pas de Procplans.
En 2008 ou plus, je dirais allumer optimize for ad hoc workloadset passer au problème suivant - cela réduirait la quantité de Mo que vos plans à usage unique occupent actuellement à presque rien. Malheureusement, en 2005, vos options sont assez limitées, en dehors de la refactorisation de ces procédures stockées pour utiliser le niveau d'instruction OPTION (RECOMPILE)et / ou moins / pas de SQL dynamique, ou l'activation du paramétrage forcé au niveau de la base de données - qui essaie d'obtenir une meilleure réutilisation du plan hors de requêtes similaires en traitant les littéraux comme des paramètres à des fins de correspondance de plan. J'hésite même à mentionner les guides de plan, car ils ne sont pas pour les timides et - comme je l'explique plus loin dans cette réponse - je ne suis pas sûr que cela vaille la peine de suivre cette voie à moins que vous ne sachiez que votre cache de plan est certainement la source de vos performances problème.
J'ai posé des questions sur, @@VERSIONcar, avant SP2, l'algorithme pour la quantité de mémoire qui pouvait être allouée au cache du plan était relativement lâche. À partir du SP2, ils ont resserré cela un peu (le changement est documenté et expliqué dans cet article et cet article ). Dans votre cas, le cache du plan est relativement plein, il n'est donc pas surprenant que vous ayez des échecs de cache. 26 Go = une limite supérieure de 5,8 Go; Je vois ~ 4,5 Go dans la feuille de calcul, mais il peut y avoir une différence de calcul ou de configuration ici que je ne connais pas.
Cet article MSDN parle du optimize for ad hoc workloadsparamètre de serveur ajouté en 2008 et mentionne l'indicateur de trace 8032, qui vous permettra d'allouer plus de mémoire à vos caches (probablement en l'absence de définition de ce paramètre au niveau du serveur, que je recommande maintenant à tous). nos clients, ou au moins les 99% qui ne sont plus en 2005). Je n'ai jamais testé cet indicateur de trace sur 2005 SP3 ou SP4, et honnêtement, je ne sais même pas quand il a été introduit. Je ne sais pas non plus si cela résoudra votre problème ou s'il le déplacera simplement, car je pense que même si vous aviez un% de RAM supplémentaire alloué aux caches, vous le rempliriez toujours et vous auriez beaucoup de cache manquant en raison de la nature de vos procédures stockées.
Ou, bien sûr, s'il y a même un problème à résoudre qui concerne directement le cache du plan. Ce n'est pas parce que votre taux d'accès au cache est aussi élevé que vous vous y attendez que cela cause votre problème, et bien sûr l'inverse est que même à 100% du taux d'accès au cache - ce qui ne semble pas réaliste étant donné que tant de vos plans sont à usage unique et ad hoc - vos utilisateurs peuvent encore souffrir de problèmes de performances causés par autre chose.
Ma suggestion est de chercher de meilleurs pistolets fumeurs que de prévoir le taux de réussite du cache. Obtenez plus de détails sur les plaintes de performances de vos utilisateurs. Toutes les requêtes sont-elles toujours lentes? Certaines requêtes? Certains moments de la journée / de la semaine / du cycle commercial? Seuls les rapports de requêtes sont-ils lents? Lisez attentivement ce document, certes sec et long, sur les meilleures pratiques de SQL Server , en particulier la section sur les attentes et les files d'attente, qui peut vous aider à formuler une approche logique pour identifier, diagnostiquer et résoudre les problèmes de performances. Rendre un certain nombre sur un tableau de bord plus beau - un nombre que vous ne connaissez même pas directement contribue au problème - peut être très satisfaisant, mais s'il ne résout pas les problèmes de performances de vos utilisateurs, il ne vous a pas vraiment aidé nulle part.
Ceux-ci peuvent également être utiles pour lire sur la compilation / recompilation et planifier la réutilisation du cache. Certaines d'entre elles se concentrent sur 2008 (en particulier celles concernant la configuration des charges de travail ad hoc), mais la plupart des informations sont toujours utiles pour 2005 et / ou pour mieux comprendre les avantages de la mise à niveau (indice, indice).