Plan d'exécution différent pour la même procédure stockée

Question

Nous avons une requête qui prend environ 5 secondes sur notre système de production, mais sur notre système miroir (aussi identique que possible à la production) et sur les systèmes de développement, cela prend moins d'une seconde.

Nous avons vérifié les plans de requête et nous pouvons voir qu'ils diffèrent. De ces plans, nous pouvons également voir pourquoi l'un prend plus de temps que l'autre. Les données, schame et les serveurs sont similaires et les procédures stockées identiques.

Nous savons comment résoudre ce problème en réarrangeant les jointures et en ajoutant des astuces. Cependant, pour l'instant, il serait plus facile de ne pas modifier le SProc (paperasserie). Nous avons également essayé un sp_recompile.

Ce qui pourrait causer la différence entre les deux plans de requête?

système: SQL 2005 SP2 Enterprise sur Win2k3 Enterprise

Mise à jour: Merci pour vos réponses, il se trouve que c'était des statistiques. Voir le résumé ci-dessous.

Answer 1

Vos statistiques sont très probablement démodées. Si vos données sont identiques, recalculez les statistiques sur les deux serveurs et recompilez. Vous devriez alors voir des plans de requête identiques.

Vérifiez également que vos index sont identiques.

Answer 2

est la taille des données de données & entre votre miroir et la production la plus proche possible de la même chose? Si vous savez pourquoi une requête prend plus de temps que l'autre? pouvez-vous poster plus de détails?

Les plans d'exécution peuvent être différents dans de tels cas en raison des données dans les tables et/ou les statistiques. Même dans les cas où les statistiques de mise à jour automatique sont activées, les statistiques peuvent devenir obsolètes (en particulier dans les très grandes tables) Vous pouvez trouver que l'optimiseur a estimé qu'une table n'est pas très grande et a opté pour un scan de table ou quelque chose comme ça .

Answer 3

Statistiques les plus probables.

Quelques réflexions: Effectuez-vous la maintenance sur vos systèmes non-prod? (par exemple, les index rebuidl, qui reconstruiront les statistiques)

Si oui, utilisez-vous le même facteur de remplissage et le même rapport d'échantillonnage statistique?

Est-ce que vous restaurez régulièrement la base de données sur le test, c'est donc 100% comme la production?

Answer 4

S'il n'y a pas d'option WITH RECOMPILE sur votre proc, le plan d'exécution sera mis en cache après la première exécution.

Voici un exemple trivial sur la façon dont vous pouvez obtenir le mauvais cache de plan de requête:

create proc spTest 
    @id int 
as 
select * from sysobjects where @id is null or id = id 

go 

exec spTest null 
-- As expected its a clustered index scan 

go 

exec spTest 1 
-- OH no its a clustered index scan 

Essayez d'exécuter votre sql QA sur le serveur de production en dehors de la procédure stockée pour déterminer si vous avez un problème avec vos statistiques étant périmées ou des index mystérieux manquant de production.

Answer 5

En se liant à la première réponse, le problème peut résider dans la fonction de reniflage de paramètres de SQL Server. Il utilise la première valeur qui a provoqué la compilation pour aider à créer le plan d'exécution. Habituellement c'est bon mais si la valeur n'est pas normale (ou quelque peu étrange), cela peut contribuer à un mauvais plan.Cela expliquerait également la différence entre la production et les tests. Désactiver le reniflage des paramètres nécessiterait de modifier le SProc, ce que je comprends n'est pas souhaitable. Cependant, après avoir utilisé sp_recompile, transmettez les paramètres que vous considéreriez comme "normaux" et il devrait être recompilé en fonction de ces nouveaux paramètres.

Je pense que le comportement de reniflage des paramètres est différent entre 2005 et 2008, donc cela peut ne pas fonctionner.

Answer 6

La solution consistait à recalculer les statistiques. J'ai négligé cela comme d'habitude nous avons prévu des tâches pour faire tout cela, mais pour une raison quelconque, les administrateurs n'ont pas mis un seul serveur, Doh.

Pour résumer tous les postes:

• Vérifiez la configuration est la même
  • Index
  • Tableau tailles
  • RESTORE DATABASE
• Plan d'exécution Mise en cache
  • Si la requête est exécutée même en dehors de la SProc, ce n'est pas le plan d'exécution
  • de sp_recompile si elle est différente
  • Paramètre renifler
• Statistiques Re-calculer