Lorsque j'exécute une certaine procédure stockée pour la première fois, il faut environ 2 minutes environ. Quand je l'exécute pour la deuxième fois, il finit dans environ 15 secondes. Je suppose que c'est parce que tout est mis en cache après la première course. Est-il possible pour moi de "réchauffer le cache" avant d'exécuter cette procédure pour la première fois? Les informations en cache que sont utilisées uniquement lorsque j'appelle la même procédure stockée avec les mêmes paramètres ou utilisera-t-il si j'appelle la même procédure stockée avec différents paramètres?
5 Réponses :
Le plan d'exécution (les informations mises en cache pour votre procédure) est réutilisée à chaque fois, même avec des paramètres différents. C'est l'un des avantages de l'utilisation de Procs stockés.
La première fois qu'une procédure stockée est exécutée, SQL Server génère un plan d'exécution et le met dans le cache de procédure.
Certaines modifications apportées à la base de données peuvent déclencher une mise à jour automatique du plan d'exécution (et vous pouvez également exiger explicitement un recompilement).
Les plans d'exécution sont supprimés du cache de procédure basé sur leur "âge". (de MSDN: Les objets référencés rarement sont bientôt éligibles à la répartition, mais ne sont pas réellement distribués à moins que la mémoire n'est requise pour d'autres objets.)
Je ne pense pas qu'il y ait un moyen de "réchauffer le cache", sauf pour effectuer la procédure stockée une fois. Cela garantira qu'il existe un plan d'exécution dans le cache et tous les appels ultérieurs le réutiliseront.
Des informations plus détaillées sont disponibles dans la documentation MSDN: http://msdn.microsoft.com/en-us/library/ms181055 (SQL.90) .aspx
Votre réponse, bien que je ne vois rien de mal à cela, manque le point. La compilation de requête ne prend pas 1m45s, ce n'est donc pas le problème de l'OP. Les problèmes de mise en cache OPS concernent le cache de la page de données, pas le cache de plan d'exécution.
Je ne pense pas que la génération du plan d'exécution coûtera plus de 1 seconde.
Je crois que la différence entre la première et la deuxième exécution est causée par la mise en cache des données en mémoire.
Les données dans le cache peuvent être réutilisées par toute requête supplémentaire (procédure stockée ou sélectionner simple).
Vous pouvez "réchauffer" le cache en lisant les données via n'importe quel choix qui lit les mêmes données. Mais cela coûtera même environ 90 secondes.
Vous pouvez vérifier le plan d'exécution pour savoir quelles tables utilisent et indexe vos utilisations de requête. Vous pouvez ensuite exécuter certains SQL pour obtenir les données dans le cache, en fonction de ce que vous voyez.
sélectionner * à partir de my_big_table pour forcer toutes les pages de données de la table dans le cache.
- Si vous voyez une demande d'index non clusteriée, vous pouvez essayer
Sélectionnez First_Column_in_index de My_Big_Table .
Pour forcer une charge d'un index spécifique, vous pouvez également utiliser le avec (index (index)) indice de table dans vos requêtes de réchauffement du cache.
Lorsque vous peignez votre requête, les données sont lues dans la mémoire en blocs. Ces blocs restent en mémoire mais ils obtiennent "vieilli". Cela signifie que les blocs sont étiquetés avec le dernier accès et lorsque SQL Server nécessite un autre bloc pour une nouvelle requête et que le cache de mémoire est plein, le bloc le moins récemment utilisé (le plus ancien) est expulsé de mémoire. (Dans la plupart des cas, les blocs de numérisation de tableaux complets sont instantanément vieillis pour empêcher la mémoire de la table complète et étouffer le serveur).
Qu'est-ce qui se passe ici est que les blocs de données en mémoire de la première requête n'ont pas encore été expulsés de mémoire afin que votre deuxième requête, ce qui signifie que l'accès du disque est évité et la performance est améliorée.
Alors, quelle est votre question pose vraiment est "puis-je obtenir les blocs de données dont j'ai besoin dans la mémoire sans les lire en mémoire (faire une requête)?". La réponse n'est pas non plus, à moins que vous ne souhaitiez cacher les tables entières et que vous puissiez résider en mémoire de manière permanente qui, à partir du temps de requête (et ainsi de taille de données), vous décrivez, n'est probablement pas une bonne idée.
Votre meilleur choix pour l'amélioration de la performance regarde vos plans d'exécution de la requête et que vous voyez si la modification de vos index peut donner un meilleur résultat. Il existe deux domaines majeurs qui peuvent améliorer les performances ici:
Données de cache SQL Server Lire du disque. Les lectures consécutives feront moins d'IO. Ceci est d'une grande aide puisque le disque IO est généralement le goulot d'étranglement.