Warum führen Abfragen zu einer Verschüttung von Tempdb?

Hintergrund

Ich bin dabei, eine 160-GB-Datenbank von MSSQL 2008 (Standard) auf einem Win 2008-Server mit 48 GB RAM auf einen neuen Server zu migrieren, auf dem MSSQL 2012 (64-Bit-Webedition) unter Win 2012 mit 64 GB RAM ausgeführt wird. Der alte Server ist aktiv und unter Last. Der neue Server ist nicht in Produktion. Der neue Server verfügt über 8 Tempdb-Dateien (jeweils 4 GB).

Problem

Beim Testen auf dem neuen Server werden in zahlreichen Abfragen Schritte angezeigt, die Warnungen auslösen, in denen "Der Operator hat Tempdb verwendet, um Daten während der Ausführung zu verschütten". Ich habe es geschafft, Sortierungen zu vermeiden, indem ich einige der Abfragen umgeschrieben habe, aber damit ist das Problem nicht wirklich gelöst. Dieselben Abfragen auf dem alten Server verursachen keine Verschüttungen. Ich habe gelesen, dass Verschüttungen passieren, wenn MSSQL eine Operation im Speicher nicht abschließen kann und in tempdb / page verschüttet werden muss. Sollte ich mir Sorgen wegen Verschüttungen machen?

Beispiele

Bildbeschreibung hier eingeben

Ich habe sp_updatestats in der Datenbank ausgeführt, daher sollten die Statistiken auf dem neuesten Stand sein, aber Sie werden feststellen, dass es einige Diskrepanzen zwischen der geschätzten und der tatsächlichen Anzahl von Zeilen gibt.

Gedächtnisbedenken

Ich habe eine maximale Gedächtniseinstellung für MSSQL von 58 des 64gb eingestellt. Derzeit hat MSSQL etwa 35 GB dieses Speichers verbraucht, verfügt jedoch über einen Arbeitssatz von nur 682 MB. Auf dem alten Server (obwohl er in Produktion ist und die Last verarbeitet) sind 44 GB Speicher für MSSQL reserviert, wovon 43,5 GB in seiner Arbeitsgruppe enthalten sind.

Bildbeschreibung hier eingeben

Ich weiß nicht, ob das Verschütten mit einer Gedächtniseinstellung zusammenhängt - hat jemand irgendwelche Ideen? MSSQL hat derzeit mehrere Hektar RAM zu sparen. Warum wird es für einige Sortierungen und Hash-Übereinstimmungen in Tempdb verschüttet?

sql-server sql-server-2012

— Andy W
quelle

Die Warnung im Ausführungsplan ist 2012 neu. Haben Sie überprüft, dass sie nicht die ganze Zeit auf dem alten Server verschüttet wurde? Haben Sie dies überwacht?

— Martin Smith

@MartinSmith ah, wusste nicht, dass die Warnung neu war. Ich habe den alten Server nicht auf Verschüttungen überwacht. Ich werde das untersuchen.

Etwas tangentialer Punkt, aber ich sitze vor einem 10-Tabellen-Join, der standardmäßig Merge-Joins mit sehr guten Zeilenschätzungen verwendet, die zu Überläufen auf Tempdb-Ebene 0 und zur Laufzeit von 25 Sekunden führen. Das Erzwingen von Hash-Verknüpfungen (und der Reihenfolge) beseitigt das Verschütten und läuft in 9s. Ich frage mich, ob es sich um das Zusammenführen mit dem Hash oder um den Unterschied handelt, der das Verschütten verursacht, und ob das Optimierungsprogramm den Effekt eines anscheinend bekannten bevorstehenden Verschießens richtig gewichtet (weil die Zeilenschätzungen sehr gut sind).

— Crokusek

Der neue Server hat Hardware numa?

— Stacylaray

Hier gibt es verschiedene Fragen:

F: Warum wurden die Abfragen vorher nicht verschüttet?

Dies war der Fall, aber SQL Server Management Studio hat dies vor SQL 2012 nicht als eindeutigen Fehler angezeigt. Dies ist ein hervorragendes Beispiel dafür, warum Sie bei der Leistungsoptimierung tiefer gehen müssen als im grafischen Ausführungsplan.

F: Warum werden Abfragen auf die Festplatte verschüttet?

Weil SQL Server ihnen nicht genügend Speicherplatz zur Verfügung stellte, um ihre Vorgänge abzuschließen. Vielleicht hat der Ausführungsplan die benötigte Speicherkapazität unterschätzt, oder die Box ist unter Speicherdruck, oder es handelt sich nur um große Anfragen. (Denken Sie daran, dass SQL Server Speicher für drei Dinge verwendet - für das Zwischenspeichern von Rohdatenseiten, für das Zwischenspeichern von Ausführungsplänen und für den Arbeitsbereich für Abfragen. Dieser Arbeitsbereichspeicher ist am Ende ziemlich klein.)

F: Wie kann ich Verschüttungen reduzieren?

Indem Sie zuverlässige T-SQL-Anweisungen schreiben, über aktuelle Statistiken verfügen, genügend Speicher auf dem Server bereitstellen, die richtigen Indizes erstellen und die Ausführungspläne interpretieren, wenn die Dinge nicht wie erwartet funktionieren. Ausführliche Erklärungen dazu finden Sie in Grant Fritcheys Buch SQL Server Query Performance Tuning .

— Brent Ozar
quelle