Definitive Liste der Schritte für SQL Server-Basistests?

Bevor Sie einen Leistungstest / eine Baseline für eine App ausführen, die SQL Server verwendet, möchte ich die Instanz in einen "sauberen" Zustand versetzen können, ohne die Instanz neu zu starten. Es gibt Schritte, denen ich tendenziell folge, aber ich möchte eine endgültige Liste erstellen, die in der richtigen Reihenfolge vorliegt und keine redundanten Schritte enthält.

Schafft diese Liste von Schritten das Setzen von SQL Server in einen "sauberen" Zustand?

Ist die Reihenfolge logisch / korrekt?

Gibt es redundante Schritte?

CHECKPOINT              -- Write all dirty pages

DBCC DROPCLEANBUFFERS   -- All should be clean after checkpoint?

DBCC FREEPROCCACHE      -- Clear the plan cache

DBCC FREESYSTEMCACHE    -- Is this necessary after FREEPROCCACHE?

DBCC FREESESSIONCACHE   -- May not be necessary if distributed queries aren't used, but want to catch all scenarios

EXEC SP_UPDATESTATS     -- Refresh stats

'BEGIN TESTING!'

— Eric Higgins
quelle

Zu Ihrer Information, das DROPCLEANBUFFERSist schön zum Testen, aber nicht immer genau. Wenn Sie auf eine Tabelle mit hohem Volumen verweisen, haben Sie höchstwahrscheinlich fast immer Seiten im Speicher, und die E / A-Zeit spielt bei dieser Abfrage keine große Rolle. Möglicherweise legen Sie mehr Gewicht auf E / A, als in diesem Fall realistisch ist.

— JNK

Sprechen Sie über das Testen in einer Produktionsumgebung oder einer isolierten Testumgebung?

— bopapa_1979

Jeder, der in einer Prod-Umgebung testet, sollte entlassen werden. :) Ja, Testumgebungen.

— Eric Higgins

Zuerst würde ich zurücktreten und fragen, welche Messungen Sie während des Tests sammeln möchten. Wenn Sie beispielsweise logische Lesevorgänge per Abfrage zählen, müssen Sie den Cache nicht freigeben. Ich bin ein großer Fan von logischen Lesevorgängen, da dies unabhängig davon ist, ob die Daten zwischengespeichert oder auf der Festplatte gespeichert sind. In der Produktion ist es schwer zu erraten, ob die Daten einer Abfrage zwischengespeichert werden oder nicht (es sei denn, Sie speichern die gesamte Datenbank im Speicher zwischen). . Wenn Sie die logischen Lesevorgänge minimieren, wird die App schneller ausgeführt, unabhängig davon, ob sich die Daten im Cache befinden oder nicht.

Als nächstes würde ich fragen, was sich zwischen den Läufen ändert. Wenn Sie beispielsweise EXEC SP_UPDATESTATS in jeder Datenbank ausführen, wie Sie vorgeschlagen haben, werden Sie die Statistiken für aktualisierte Tabellen erneut abtasten. Wenn Sie jedoch keine Statistiken mit Fullscan aktualisieren, erhalten Sie zufällige Zeilen aus der Tabelle - das ist nicht zu wiederholbar, und ich glaube nicht, dass Sie das wirklich wollen. Stattdessen möchten Sie möglicherweise die Datenbanken zwischen den einzelnen Läufen wiederherstellen, damit Sie immer genau dieselben Daten testen. Wenn Ihre Tests Einfügungen / Aktualisierungen / Löschungen durchführen, haben sie möglicherweise bei jedem Lauf unterschiedliche Leistungsprofile, wenn Sie die Datenbank nicht wiederherstellen (weil sie Daten hinzufügen / ändern sowie Statistiken zu den Daten ändern) - und noch schlimmer:

— Brent Ozar
quelle

Sehr gute Punkte, das Ziel ist es, dass zwischen den Läufen alles identisch ist. Die Messungen, die ich in diesem Fall @ hand durchführe, sind Laufzeiten für bestimmte Funktionen in einer App (x Sekunden, um die Liste an die App zurückzugeben, y Sekunden, um ein Warteschlangenelement hinzuzufügen usw.). Was sich zwischen den Tests ändert, können Teile des App-Codes und keine SQL-Objekte, SQL-Objekte und kein App-Code oder Einstellungen auf Instanz- / DB-Ebene wie Parallelität ohne Änderungen am App-Code sein. Wenn ich vor jedem Test eine Wiederherstellung aus dem Gatter heraus hinzufügen würde, wie beurteilen Sie meine Liste über diesem Punkt? Vermisse ich etwas oder braucht die Sequenz etwas Arbeit?

— Eric Higgins

Brent, berücksichtigen Sie bei Ihren Tests die CPU?

— AK

@EricHiggins Anstatt mehrere Dinge gleichzeitig zu testen, würde ich die Teile einzeln testen. Ich möchte Abfragen lieber direkt testen und sehen, welche Änderungen sich dort auf die Leistung auswirken. Führen Sie beispielsweise eine SQL-Ablaufverfolgung aus, während Sie bestimmte Funktionen in der App ausführen, und spielen Sie diese Ablaufverfolgung dann erneut ab, während Sie Index- / Konfigurationsänderungen vornehmen, um die Leistung zu verbessern, und beobachten Sie beispielsweise logische Lesevorgänge und CPU-Metriken in Ablaufverfolgungen.

— Brent Ozar

@AlexKuznetsov Ich bin eigentlich nicht derjenige, der die Tests durchführt - Eric ist derjenige, der die Frage gestellt hat. Wenn ich diese Art von Arbeit mache, betrachte ich die CPU-Metriken sowohl auf Abfrageebene als auch auf dem Server insgesamt.

— Brent Ozar

Wir verwenden einen Lastgenerator eines Drittanbieters (und haben eine Vollzeitkraft, die sich mit der Entwicklung von Lasttests befasst). Meine Tests sind also genau auf die Transaktion, die Reihenfolge, die Anzahl der Benutzer, die genauen Schritte in der App ... alles. Ich muss mir also nicht unbedingt die Metriken des SQL-Dashboard-Typs ansehen. Die Lasttest-Software verfolgt die Antwortzeiten für die App-Module in Millisekunden. Eine DB-Wiederherstellung ist daher eine gute Idee. Ich muss die anderen Schritte, die ich mache, überprüfen, um sicherzugehen, dass ich vor jeder Testrunde den Status "Clean Slate" erreiche, den ich suche.

— Eric Higgins