Comment corrigez-vous les requêtes qui s'exécutent lentement jusqu'à ce qu'elles soient mises en cache

Question

J'ai des requêtes qui provoquent des délais d'attente dans notre environnement en direct. (> 30 secondes)

Si j'exécute le profileur et saisis le code SQL exact exécuté à partir de Management Studio, l'exécution de la première fois prend beaucoup de temps, puis passe à quelques centaines de millisecondes à chaque exécution ultérieure.

C’est évidemment que SQL met en cache les données et les met en mémoire.

Je suis sûr que des optimisations peuvent être apportées au code SQL pour le rendre plus rapide.

Ma question est la suivante: comment puis-je & "corriger &"; ces requêtes lorsque la deuxième fois que je l'exécute, les données ont déjà été mises en cache et sont rapides?

Answer 1

Selon http: / /morten.lyhr.dk/2007/10/how-to-clear-sql-server-query-cache.html , vous pouvez exécuter ce qui suit pour vider le cache:

DBCC DROPCLEANBUFFERS   
DBCC FREEPROCCACHE  

EDIT: J'ai vérifié avec la documentation de SQL Server que j'ai et c'est tout au moins le cas de SQL Server 2000.

Answer 2

Puis-je vous suggérer de consulter le plan d'exécution pour les requêtes responsables de vos problèmes de performances médiocres.

Vous devez identifier, dans le plan d'exécution, les étapes ayant le coût le plus élevé et pourquoi. Il se peut que vos requêtes effectuent une analyse de table ou qu'un index inapproprié soit utilisé, par exemple.

Il existe un ebook gratuit et très détaillé disponible sur le site Web RedGate qui se concentre spécifiquement sur la compréhension du contenu des plans d'exécution.

https://www.red-gate.com/ Dynamique / Téléchargements / DownloadForm.aspx? Download = ebook1

Il se peut que vous souhaitiez utiliser un plan d'exécution particulier pour votre requête. Vous pouvez forcer le plan d'exécution utilisé pour une requête dans SQL Server à l'aide d'indicateurs de requête. Ceci est un concept assez avancé cependant et devrait être utilisé avec discrétion. Consultez le livre blanc Microsoft suivant pour plus de détails.

http://www.microsoft.com/technet/prodtechnol/ sql / 2005 / frcqupln.mspx

Je ne vous recommanderais pas non plus d'effacer le cache de procédure de votre environnement de production, car cela nuirait aux performances de toutes les autres requêtes de la plate-forme qui ne rencontrent actuellement aucun problème de performances.

Si vous exécutez une procédure stockée par exemple, vous pouvez vous assurer qu'un nouveau plan d'exécution est calculé pour chaque exécution de la procédure à l'aide de la commande WITH RECOMPILE.

Pour des informations générales sur le réglage des performances, le blog de Brent Ozar & # 8217;

http://www.brentozar.com/sql-server-performance-tuning /

J'espère que ça aide. Cheers.

Answer 3

Utiliser peut utiliser

DBCC DROPCLEANBUFFERS   
DBCC FREEPROCCACHE

Mais utilisez-le uniquement dans votre environnement de développement lors du réglage des requêtes pour le déploiement sur un serveur actif.

Answer 4

Je pense que les gens partent dans la mauvaise direction. Si je comprends bien, vous voulez que la performance soit bonne tout le temps? Ne courent-ils pas rapidement la deuxième (et les exécutions suivantes) et sont lents la première fois?

Les commandes DBCC ci-dessus effacent le cache, entraînant une performance WORSE.

Ce que vous voulez, je pense, est d’amorcer la pompe et de mettre en cache les données. Vous pouvez le faire avec certaines procédures de démarrage qui exécutent les requêtes et chargent les données en mémoire.

La mémoire étant une ressource finie, vous ne pouvez pas charger toutes les données, probablement, en mémoire, mais vous pouvez trouver un équilibre. Brent a quelques bonnes références ci-dessus pour aider à apprendre ce que vous pouvez faire ici.

Answer 5

L’optimisation des requêtes est un sujet complexe, il n’existe pas de réponse unique à votre question. Les indices sur ce qu'il faut faire sont tous dans le plan de requête, qui devrait être identique, que les résultats soient mis en cache ou non.

Recherchez les éléments usuels tels que les analyses de table, les index non utilisés lorsque vous prévoyez de les utiliser, etc. etc. En fin de compte, vous devrez peut-être revoir votre modèle de données et éventuellement mettre en œuvre une stratégie de dénormalisation.

Answer 6

À partir de MSDN:
" Utilisez DBCC DROPCLEANBUFFERS pour tester des requêtes à froid cache en mémoire tampon sans arrêter ni redémarrer le serveur. "