Das Anzeigen eines geschätzten Ausführungsplans generiert Wartezeiten für CXPACKET, PAGELATCH_SH und LATCH_EX [ACCESS_METHODS_DATASET_PARENT]

Ich bin mit Microsoft SQL Server 2016 SP2-CU6 (13.0.5292.0) auf einem 4 vCPU VM mit max degree of parallelismSatz 2und cost threshold for parallelismSatz 50.

Wenn ich morgens versuche, einen geschätzten Ausführungsplan für eine SELECT TOP 100- Abfrage anzuzeigen , muss ich massiv warten, und der Vorgang zum Rendern des geschätzten Plans dauert Minuten, häufig 5 bis 7 Minuten. Dies ist wiederum nicht die tatsächliche Ausführung der Abfrage, sondern lediglich der Prozess zum Anzeigen eines geschätzten Ausführungsplans .

sp_WhoIsActivewird entweder PAGEIOLATCH_SHwaits oder LATCH_EX [ACCESS_METHODS_DATASET_PARENT]waits anzeigen und wenn ich das Skript WaitingTasks.sql von Paul Randal während des Vorgangs ausführe, werden CXPACKETwaits mit den Worker-Threads angezeigt, die waits anzeigenPAGEIOLATCH_SH :

* Ressourcenbeschreibungsfeld = exchangeEvent id=Port5f6069e600 WaitType=e_waitPortOpen waiterType=Coordinator nodeId=1 tid=0 ownerActivity=notYetOpened waiterActivity=waitForAllOwnersToOpen

Die Worker-Threads scheinen die gesamte statsTabelle in den Speicher zu bringen (da diese Seitenzahlen sowie nachfolgende Seitenzahlen, die aus Paul Randals Abfrage hervorgehen, auf den gruppierten Schlüssel für die statsTabelle verweisen ). Sobald der Plan wieder verfügbar ist, ist er für den Rest des Tages im Grunde genommen sofort verfügbar, auch wenn statsnur noch verschiedene Datensätze übrig sind (von denen ich annehme, dass sie aufgrund von Suchvorgängen aus ähnlichen Abfragen abgerufen wurden).

Ich würde dieses anfängliche Verhalten erwarten, wenn die Abfrage tatsächlich mit einem Plan ausgeführt würde, der SCAN-Operatoren verwendet. Warum geschieht dies jedoch, wenn Ausführungspläne ausgewertet werden, um nur zu einem SEEK-Operator zu gelangen, wie im oben verknüpften Plan gezeigt? Was kann ich tun (abgesehen von der Ausführung dieser Anweisung vor den Bürozeiten, damit meine Daten ordnungsgemäß zwischengespeichert werden), um die Leistung hier zu verbessern? Ich gehe davon aus, dass ein paar Covering-Indizes von Vorteil wären, aber würden sie wirklich Verhaltensänderungen garantieren? Ich muss hier innerhalb einiger Einschränkungen des Speicher- und Wartungsfensters arbeiten, und die Abfrage selbst wird aus einer Herstellerlösung generiert. Daher sind an dieser Stelle alle anderen Vorschläge (außer einer besseren Indizierung) willkommen.

Es wird Ihre Anfrage nach einem tatsächlichen Ausführungsplan angezeigt, der die Aktualisierung der Statistiken auslöst. Da Sie erwähnen, dass dies morgens geschieht, stelle ich mir vor, dass über Nacht zahlreiche Änderungen an den betreffenden Tabellen vorgenommen werden.

Daher verwendet SQL Server die Statistiken, um den Plan zu erstellen, hat den Änderungsschwellenwert erreicht und führt als Teil des Vorgangs automatische Aktualisierungen der Statistiken durch.

In der XML-Datei für den geschätzten Plan, den Sie geteilt haben, werden die folgenden Aktualisierungstermine für Statistiken von heute Morgen angezeigt:

LastUpdate="2019-05-06T09:12:49.92"
LastUpdate="2019-05-06T09:12:58.3"
LastUpdate="2019-05-06T09:13:20.33"
LastUpdate="2019-05-06T09:13:09.67"
LastUpdate="2019-05-06T09:12:59.05"
LastUpdate="2019-05-06T09:12:39.56"

Wenn diese sind sehr groß, beschäftigt Tabellen (scheint auf den Stichprobenprozentsätze wahrscheinlich basiert), dann ist es nicht allzu überraschend , dass die Statistiken Updates viel PS einnehmen.

Wenn ich lange geschätzte Planzeiten in SSMS sehe, ist dies in der Reihenfolge der Wahrscheinlichkeit eine der folgenden:

1. Das Abfrageoptimierungsprogramm hat entschieden, dass Statistiken erstellt oder aktualisiert werden müssen.
2. Der geschätzte Plan ist sehr groß (z. B.> 10 MB), und es dauert einfach lange, bis SSMS ihn anzeigt.
3. Die eigentliche Abfragekompilierung hat aufgrund der CPU-Auslastung bei der Suche nach einem ausreichend guten Plan viel Zeit in Anspruch genommen.
4. Der Server ist extrem belastet. Beispielsweise muss ich möglicherweise warten, bis ein Gateway verfügbar ist.
5. Verschiedene Fehler, die zu extrem langen Kompilierzeiten führen.

Für Ihre Situation lautet die Antwort mit ziemlicher Sicherheit, dass SQL Server Statistiken aktualisiert oder erstellt. Es gibt einige Hinweise: Die Größe des Abfrageplans ist klein, der Abfrageplan ist relativ einfach und kostengünstig, und die Kompilierungs-CPU ist erheblich kürzer als die Kompilierungszeit:

Der neue Mitwirkende Josh Darnell wies auch auf einen guten Hinweis mit der zuletzt aktualisierten Zeit für Statistiken im XML hin.

SQL Server 2019 führt den neuen Wartetyp WAIT_ON_SYNC_STATISTICS_REFRESH ein , wenn Abfragen auf Statistikaktualisierungen warten. Es ist viel einfacher, dieses Problem in dieser Version zu diagnostizieren. Bis dahin müssen Sie sich nur auf indirekte Techniken verlassen.

Problemumgehungen umfassen das Aktualisieren von Statistiken während eines Wartungszeitraums oder das Aktivieren von Auto Update Stats Async für die Datenbank. Bitte verstehen Sie die vollständigen Auswirkungen dieser Option, bevor Sie sie ändern. Abfragepläne werden vor der Aktualisierung der Statistiken erstellt und nicht nach der Aktualisierung der Statistiken. Für einige Workloads kann dies ein enormer Gewinn sein. Für andere kann es mehr schaden als nützen.