SQL Server recréant des plans chaque jour

Nous avons ce problème dans notre environnement de production.

Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64) - Enterprise Edition (64 bits) sur Windows NT 6.1 (Build 7601: Service Pack 1).

SQL Server supprime tous (presque 100%) les anciens plans d'exécution et les recrée tous les jours du jour au lendemain (de 23h00 à 8h00). Cela se produisait même lorsque les «statistiques de mise à jour automatique» étaient désactivées. Nous avons activé les «statistiques de mise à jour automatique» au cours des 2-3 dernières semaines. Mais ça continue.

Nous ne savons pas vraiment ce qui déclenche cette régénération de plans, mais nous sommes sûrs que nous ne le faisons pas manuellement.

La seule chose qui coïncide vraiment avec le calendrier de régénération des plans est un travail de maintenance de base de données que nous avons: la réorganisation quotidienne de l'index (lorsque la fragmentation est de 5-30%) et la reconstruction quotidienne de l'index (lorsque la fragmentation est supérieure à 30% ) emploi. Habituellement, ce travail de maintenance quotidienne ne fait que se réorganiser (car la fragmentation de l'indice n'est jamais supérieure à 30% sur une base quotidienne).

Impact:

Ces plans nouvellement créés font que certains appels UDF / appels de requête (qui sont appelés à partir de l'interface utilisateur / des pages Web) prennent beaucoup plus de temps (minutes par opposition à moins de 1 seconde), et donc les sessions s'empilent en prenant le CPU près de 90% .

Le problème disparaît au moment où ces sessions bloquées sont supprimées de force (côté DB), et 1) lorsque tous les plans d'exécution correspondants sont effacés manuellement (pour les requêtes) ou 2) lorsque les FDU sont modifiés (pour les fonctions). Tous les nouveaux plans créés par SQL Server à partir de ce moment fonctionnent parfaitement tout au long de la journée jusqu'à ce qu'ils finissent par avoir le même problème le lendemain matin. De plus, ce comportement n'est pas cohérent à 100%, nous ne le voyons pas vraiment tous les matins. Mais il y a eu des périodes où nous l'avons vu de façon constante pendant 4 à 5 jours consécutifs.

Le problème se produit le matin des affaires, c'est à ce moment-là que les pages UI / Web sont accessibles de manière plus intensive, semble-t-il.

Quelqu'un a-t-il une idée de ce qui cause cela et comment résoudre ce problème? Toute aide serait très appréciée.

— peter.petrov
source

le plancache peut être libéré lorsque la machine est sous pression de mémoire ou si vous modifiez les paramètres au niveau de la base de données. (modifier db). Puisque vous avez dit que vous ne les supprimiez pas "manuellement", je suppose que cela pourrait être une pression mémoire. De combien de mémoire dispose la machine? quels sont vos paramètres de mémoire max? avez-vous un environnement virtuel et peut-être une RAM surutilisée?

— RayofCommand

Pourquoi êtes-vous au SP1. Avant de faire quoi que ce soit, appliquez le SP3. SQL Server peut forcer les plans s'il trouve une pression mémoire et a besoin de plus de mémoire pour accueillir des pages spécialement à partir de la reconstruction d'index spécialement si vous avez de grandes tables. La reconstruction d'index essaierait d'apporter autant de pages que possible. Ce que vous pouvez faire, c'est cesser d'utiliser MP et utiliser la solution d'Ola Hallengren et voir si cela aide. Qu'est-ce que la mémoire maximale du serveur?

— Shanky

Les gars, je ne suis pas un DBA, seulement un développeur SQL. Je demande simplement tout cela car cela dure depuis un certain temps. Merci pour vos commentaires, je vais essayer de répondre à tous, même si pour l'instant je trouve ça difficile à suivre (et tout cela vous semble assez évident). Qu'est-ce que MP?

— peter.petrov

@ peter.petrov nous essayons de vous aider en apprenant à connaître votre environnement. MP = Plans de maintenance.

— Kin Shah

Le vrai problème est que vos plans de requête sont si fragiles. Les recompilations peuvent se produire à tout moment, même pendant la journée. Aucune garantie. Corrigez vos requêtes afin que les plans deviennent stables. OPTION RECOMPILE ou OPTIMIZE FOR UNKNOWN sont des approches de marteau qui peuvent être appropriées et être une solution rapide.

— usr

Eh bien, j'ai quelques idées qui pourraient provoquer ce comportement.

Surveillez-vous la pression de votre mémoire? Peut-être que vos requêtes augmentent une certaine limite qui provoquera le vidage du cache du plan. Je ne connais pas votre application, mais ce correspondant avec vos logs de vos serveurs frontaux? Y a-t-il aussi de la pression pendant ce temps?
Avez-vous un serveur SQL dédié ou le serveur partage-t-il son matériel avec d'autres processus / services? Sinon, essayez plutôt d'externaliser votre serveur SQL vers une machine dédiée. Cela réduira les effets secondaires des autres services.
Vous voudrez peut-être utiliser optimize for ad hoc workloads, qui enregistrera simplement un talon de plan et le compilera si nécessaire. Cela réduira la charge de votre plancache, ce qui réduira les risques de rinçage de la plancache. Vous pouvez l'activer à l'aide de sp_configure 'optimize for ad hoc workloads',1; reconfigure. Cela peut être fait si vous avez activé l' advanced optionsutilisation sp_configure 'show advanced options',1; reconfigure.
Une autre idée peut être les sauvegardes. Juste de simples sauvegardes. S'ils sont agressifs, il peut arriver que votre machine soit également sous pression. Le moment où vous mentionnez sonne juste comme un bon délai pour planifier une sauvegarde.
C'est peut-être un bug assez simple dans votre script de maintenance. Avez-vous vérifié s'il existe un problème logique qui fait que votre script reconstruit tous les index au lieu de ceux qui correspondent aux critères. Cela peut aussi en être la cause.

Juste à côté de toutes ces possibilités, il peut être utile de vérifier les fichiers journaux pour certaines modifications aux options affinity mask, affinity I/O masket leurs partenaires x64. Une autre chose peut être un changement de l' MAXDOPoption de votre instance. Veuillez également vérifier les journaux pour eux. Ils devront également rincer la plancache.

Enfin, vous pouvez toujours exécuter une trace côté serveur (il suffit de la configurer à l'aide du profileur, de la démarrer, de l'arrêter et d'utiliser la commande sql pour la redémarrer sur le côté serveur). À côté de ça, perfmonc'est votre ami. Il peut regarder et surveiller vos valeurs de performances pendant un certain temps. Peut-être que vous pouvez voir des parallèles dans la pression avec certaines actions sur votre serveur qui peuvent provoquer celles-ci.

J'espère que cela vous aidera, même si la réponse viendra un peu plus tard.

— Ionique
source