SQL Server-Befehle zum Löschen von Caches vor dem Ausführen eines Leistungsvergleichs

Wenn Sie die Ausführungszeit von zwei verschiedenen Abfragen vergleichen, müssen Sie den Cache leeren, um sicherzustellen, dass die Ausführung der ersten Abfrage die Leistung der zweiten nicht beeinträchtigt.

In einer Google-Suche konnte ich folgende Befehle finden:

DBCC FREESYSTEMCACHE
DBCC FREESESSIONCACHE
DBCC FREEPROCCACHE

Meine Abfragen benötigen nach mehreren Ausführungen eine realistischere Zeit als zuvor. Ich bin mir jedoch nicht sicher, ob dies die empfohlene Technik ist.

Was ist die beste Vorgehensweise?

Persönlich sind für eine gemeinsame Abfrage die 2. und nachfolgende Ausführungen wichtiger.

Testen Sie die Festplatten-E / A- oder Abfrageleistung?

Angenommen, Ihre Abfrage wird häufig ausgeführt und ist von entscheidender Bedeutung, dann möchten Sie dies unter realen Bedingungen messen. Und Sie möchten nicht jedes Mal die Prod-Server-Caches löschen ...

Wenn Du willst, kannst Du:

• DBCC DROPCLEANBUFFERSLöscht saubere (unveränderte) Seiten aus dem Pufferpool.
  Stellen Sie dem voran, dass Sie CHECKPOINTalle verschmutzten Seiten zuerst auf die Festplatte spülen möchten
• DBCC FLUSHPROCINDB Löscht die Ausführungspläne für diese Datenbank

Siehe auch (auf DBA.SE)

• Lösen einer hohen Seitenladezeit mithilfe von SQL Profiler

Eine verspätete Antwort kann jedoch für andere Leser von Nutzen sein

DBCC DROPCLEANBUFFERS ist ein häufig verwendeter Befehl zum Testen von Abfragen und zum Messen der Ausführungsgeschwindigkeit von Abfragen. Dieser Befehl (wenn er ausgeführt wird) hinterlässt nur die schmutzigen Seiten, bei denen es sich tatsächlich um einen kleinen Teil der Daten handelt. Es werden alle bereinigten Seiten für einen gesamten Server entfernt.

Beachten Sie, dass dieser Befehl nicht in einer Produktionsumgebung ausgeführt werden sollte. Das Ausführen dieses Befehls führt dazu, dass der Puffer zum größten Teil leer ist. Das Ausführen einer Abfrage nach dem Ausführen des Befehls DBCC DROPCLEANBUFFERS verwendet physische Lesevorgänge, um die Daten in den Cache zurückzuspeichern. Dieser Vorgang ist sehr wahrscheinlich sehr viel langsamer als der Arbeitsspeicher.

Behandeln Sie diesen Befehl erneut ähnlich wie DBCC FREEPROCCACHE. Er sollte auf keinem Produktionsserver ausgeführt werden, es sei denn, Sie wissen genau, was Sie tun.

Dies kann ein nützliches Entwicklungstool sein, da Sie eine Abfrage in einer Leistungstestumgebung immer wieder ausführen können, ohne dass sich die Geschwindigkeit / Effizienz aufgrund des Zwischenspeicherns von Daten im Speicher ändert.

Weitere Informationen finden Sie unter: http://www.sqlshack.com/insight-into-the-sql-server-buffer-cache/

Mir wurde immer gesagt, zu verwenden:

dbcc dropcleanbuffers;

Von MSDN :

Verwenden Sie DBCC DROPCLEANBUFFERS, um Abfragen mit einem Cold-Buffer-Cache zu testen, ohne den Server herunterzufahren und neu zu starten.

Verwenden Sie zuerst CHECKPOINT, um einen kalten Puffercache zu erstellen, um saubere Puffer aus dem Pufferpool zu löschen. Dies erzwingt, dass alle schmutzigen Seiten für die aktuelle Datenbank auf die Festplatte geschrieben werden, und bereinigt die Puffer. Anschließend können Sie den Befehl DBCC DROPCLEANBUFFERS ausgeben, um alle Puffer aus dem Pufferpool zu entfernen.

Die anderen Antworten beziehen sich auf Gründe, warum sie nicht ausgeführt werden DBCC FREEPROCCACHE. Es gibt jedoch auch einige Gründe dafür:

1. Konsistenz

Wenn Sie zwei verschiedene Abfragen oder Verfahren vergleichen möchten, die versuchen, dasselbe auf unterschiedliche Weise zu tun, werden sie wahrscheinlich auf die gleichen Seiten gelangen. Wenn Sie Abfrage Nr. 1 und Abfrage Nr. 2 naiv ausführen, ist die zweite möglicherweise viel schneller, weil diese Seiten von der ersten Abfrage zwischengespeichert wurden. Wenn Sie den Cache vor jeder Ausführung leeren, werden sie auf einer gleichmäßigen Grundlage gestartet.

Wenn Sie die Hot-Cache-Leistung testen möchten, müssen Sie die Abfragen mehrmals abwechselnd ausführen und die ersten paar Durchläufe verwerfen. Durchschnitt die Ergebnisse.

2. Schlechteste Leistung

Angenommen, Sie haben eine Abfrage, die für einen Hot-Cache eine Sekunde und für einen Cold-Cache eine Minute dauert. Eine Optimierung, die die In-Memory-Abfrage um 20% verlangsamt, die IO-gebundene Abfrage jedoch um 20% beschleunigt, könnte ein großer Gewinn sein: Während des normalen Betriebs wird niemand die zusätzlichen 200 ms bemerken, aber wenn etwas eine Abfrage erzwingt Laufen Sie gegen die Festplatte, dauert es 48 Sekunden anstatt 60 Sekunden, um einen Verkauf zu retten.

Dies ist bei modernen Systemen mit zehn Gigabyte Speicher und relativ schnellem SAN- und SSD-Speicher weniger problematisch, spielt aber dennoch eine Rolle. Wenn ein Analyst eine umfangreiche Table-Scan-Abfrage für Ihre OLTP-Datenbank ausführt, bei der die Hälfte Ihres Puffercaches gelöscht wird, werden Sie durch speichereffiziente Abfragen schneller wieder auf den neuesten Stand gebracht.