Première exécution lent dans une procédure stockée du serveur SQL

Question

J'ai une procédure stockée qui s'exécute neuf fois par jour, juste après minuit. Ce n'est pas une procédure stockée idéale, mais vous savez comment c'est. Aucun plan ne survit à un contact avec la réalité.

Cette procédure stockée prend normalement environ une minute pour s'exécuter, donner ou prendre du temps pour le volume de données qu'elle traite. Cependant, lors de la première manche pour un matin donné, il faudra parfois un temps excessif, parfois bien plus d'un ordre de grandeur plus long que le temps qu'il prend normalement (s'il se termine). Si je le tue et le redémarre, il fonctionne normalement.

Je suis à la recherche d'une solution élégante pour cela - au moins plus élégante que ma première idée, qui consiste à lancer une série supplémentaire en premier qui ne génère pas de données et dont l'échec peut être toléré.

Quelqu'un at-il déjà vu ce comportement? Comment as-tu résolu ça?

Answer 1

Il s'agit probablement d'une heure de compilation et d'un cache de données à froid (pool de mémoire tampon). Et si cela prend normalement une minute, alors je suppose que c'est aussi assez gros.

Heure de compilation: un plan d'exécution est invalidé lors de la mise à jour des statistiques. Si vous avez des processus en vrac ou une maintenance de nuit, vous frapperez probablement ceci

Cache caché: la page de données/index doit provenir du disque en mémoire.

Pour atténuer ces:

• Une course factice (comme indiqué)
• plus rapide IO de RAM ou plus
• plan guides

Nous avons les mêmes problèmes, parfois, en particulier sur le développement boîtes, dans la mesure où nos sites Web expirent par exemple. Nous cliquons à nouveau ...

Answer 2

Les procédures stockées sont compressées dans sqlserver. Si vous utilisez DBCC FREEPROCCACHE, il recompilera l'instruction SQL. Si votre serveur est redémarré (par exemple tous les soirs ou toutes les semaines), il est possible que son cache soit effacé, ce qui ralentirait la requête dès le premier essai.

Vous pouvez tester cela en exécutant la commande ci-dessus et en exécutant la requête pour voir si la même chose arrive ... si c'est le cas je dirais que votre cache est effacé.

Answer 3

Afin de fournir une solution, la première chose à faire est d'étudier la cause. Il pourrait y avoir beaucoup de problèmes qui se manifesteraient comme les symptômes que vous décrivez. Toujours commencer à résoudre les problèmes de performances en suivant une méthodologie d'enquête, comme Waits And Queues. cela révélera pourquoi est la procédure lente à la première exécution. coupables probables:

• un cache froid
• contention sur certaines ressources (serrures?) Avec un autre processus
paramètre
• renifler provoquant un mauvais plan

Selon ce que vous trouvez comme étant le problème, il y aura une solution appropriée.

Une chose que vous devriez et non est de changer aveuglément les paramètres et espérer que le problème disparaisse, sans jamais comprendre ce qui n'allait pas.

Answer 4

Est-ce que AUTO_UPDATE_STATISTICS ou AUTO_UPDATE_STATISTICS_ASYNC est activé pour la base de données? Il se peut que le premier passage remarque que les statistiques doivent être mises à jour et qu'il le fasse. Dans l'ancienne option set, il attend la fin de la mise à jour des statistiques et pour ce dernier, il n'attend pas la mise à jour des statistiques mais peut choisir un plan sous-optimal entraînant ainsi de mauvaises performances. Que se passe-t-il d'autre en même temps que le proc s'exécute la première fois chaque jour?

Answer 5

Pourrait-il obtenir des verrous à partir d'un autre processus (sauvegardes, mises à jour de statistiques, autres tâches planifiées)?