Commandes SQL Server pour effacer les caches avant d'exécuter une comparaison de performances

Lors de la comparaison du temps d'exécution de deux requêtes différentes, il est important d'effacer le cache pour s'assurer que l'exécution de la première requête ne modifie pas les performances de la seconde.

Dans une recherche Google, je pourrais trouver ces commandes:

DBCC FREESYSTEMCACHE
DBCC FREESESSIONCACHE
DBCC FREEPROCCACHE

En fait, mes requêtes prennent un temps plus réaliste à traiter après plusieurs exécutions qu'auparavant. Cependant, je ne suis pas sûr que ce soit la technique recommandée.

Quelle est la meilleure pratique?

Personnellement, pour une requête commune, la deuxième exécution et les exécutions suivantes importent davantage.

Est-ce que vous testez les performances d’interrogation ou de disque IO?

En supposant que votre requête s'exécute souvent et soit critique, vous souhaitez ensuite la mesurer dans des conditions réelles. Et vous ne voulez pas vider les caches du serveur de prod à chaque fois ...

Si vous voulez vous pouvez:

• DBCC DROPCLEANBUFFERSefface pages propres (non modifié) à partir du pool de mémoire tampon
  Precede qu'avec un CHECKPOINTpour rincer toutes les pages sales sur le disque premier
• DBCC FLUSHPROCINDB efface les plans d'exécution pour cette base de données

Voir aussi (sur DBA.SE)

• Résolution du temps de chargement élevé des pages à l'aide de SQL Profiler

Réponse tardive mais peut être utile à d'autres lecteurs

DBCC DROPCLEANBUFFERS est une commande souvent utilisée pour tester et évaluer la vitesse d'exécution d'une requête. Cette commande (lorsqu'elle est exécutée) ne laisse que les pages endommagées, qui représentent en réalité une petite partie des données. Il supprime toutes les pages propres pour un serveur entier.

Sachez que cette commande ne doit pas être exécutée sur un environnement de production. L'exécution de cette commande aura pour résultat un cache de mémoire tampon essentiellement vide. L'exécution de toute requête après l'exécution de la commande DBCC DROPCLEANBUFFERS utilisera des lectures physiques pour ramener les données dans le cache, ce qui risque fort d'être beaucoup plus lent que la mémoire.

Là encore, traitez cette commande de la même manière que DBCC FREEPROCCACHE. Elle ne doit être exécutée sur aucun serveur de production, à moins que vous ne sachiez absolument ce que vous faites.

Cela peut être un outil de développement utile car vous pouvez exécuter une requête dans un environnement de test de performances à plusieurs reprises sans modification de la vitesse / de l'efficacité en raison de la mise en cache des données en mémoire.

En savoir plus sur: http://www.sqlshack.com/insight-into-the-sql-server-buffer-cache/

On m'a toujours dit d'utiliser:

dbcc dropcleanbuffers;

De MSDN :

Utilisez DBCC DROPCLEANBUFFERS pour tester les requêtes avec un cache de tampon froid sans arrêter et redémarrer le serveur.

Pour supprimer les tampons vides du pool de tampons, utilisez d'abord CHECKPOINT pour générer un cache de tampon froid. Cela oblige toutes les pages modifiées de la base de données actuelle à être écrites sur le disque et nettoie les tampons. Cela fait, vous pouvez émettre la commande DBCC DROPCLEANBUFFERS pour supprimer tous les tampons du pool de tampons.

Les autres réponses sont correctes sur les raisons de ne pas courir DBCC FREEPROCCACHE. Cependant, il y a aussi deux raisons de le faire:

1. Cohérence

Si vous souhaitez comparer deux requêtes ou procédures différentes qui tentent de faire la même chose de différentes manières, elles risquent de s'afficher sur les mêmes pages. Si vous exécutez naïvement la requête n ° 1 puis la requête n ° 2, la seconde peut être beaucoup plus rapide simplement parce que ces pages ont été mises en cache par la première requête. Si vous effacez le cache avant chaque exécution, ils démarrent sur un pied d'égalité.

Si vous souhaitez tester les performances du cache dynamique, veillez à exécuter les requêtes plusieurs fois, en alternant, et à ignorer les deux premières exécutions. Moyenne des résultats.

2. Pire performance

Supposons que votre requête prenne une seconde par rapport à un cache chaud, mais une minute par rapport à un cache à froid. Une optimisation qui ralentit la requête en mémoire de 20% mais la requête liée aux entrées-sorties de 20% plus rapide pourrait être un avantage considérable: lors d'opérations normales, personne ne remarquera les 200 ms supplémentaires dans des circonstances normales, mais si quelque chose force une requête à courir sur le disque, prendre 48 secondes au lieu de 60 pourrait sauver une vente.

Cela pose moins de problèmes sur les systèmes modernes dotés de dizaines de giga-octets de mémoire et d'un stockage SAN et SSD relativement rapide, mais cela reste important. Si certains analystes exécutent une requête d'analyse de table volumineuse sur votre base de données OLTP qui efface la moitié de votre cache de mémoire tampon, les requêtes efficaces en termes de stockage vous permettront de revenir rapidement à la vitesse supérieure.