Stichprobengröße und die Dauer von UPDATE STATISTICS:Spielt es eine Rolle?

Für jede neue Datenbank, die in SQL Server erstellt wird, ist der Standardwert für die Option Statistik automatisch aktualisieren aktiviert . Ich vermute, dass die meisten DBAs die Option aktiviert lassen, da sie es dem Optimierer ermöglicht, Statistiken automatisch zu aktualisieren, wenn sie ungültig gemacht werden, und es wird im Allgemeinen empfohlen, sie aktiviert zu lassen. Statistiken werden auch aktualisiert, wenn Indizes neu erstellt werden, und obwohl es nicht ungewöhnlich ist, dass Statistiken über die Option zur automatischen Aktualisierung von Statistiken und durch Indexneuerstellungen gut verwaltet werden, kann es für einen DBA von Zeit zu Zeit erforderlich sein, einen regelmäßigen Job zum Aktualisieren von a einzurichten Statistik oder Satz von Statistiken.

Die benutzerdefinierte Verwaltung von Statistiken umfasst häufig den Befehl UPDATE STATISTICS, der ziemlich harmlos erscheint. Es kann für alle Statistiken für eine Tabelle oder indizierte Ansicht oder für eine bestimmte Statistik ausgeführt werden. Es kann die Standardstichprobe verwendet werden, eine bestimmte Stichprobenrate oder Anzahl der Zeilen für die Stichprobe kann angegeben werden, oder Sie können denselben Stichprobenwert verwenden, der zuvor verwendet wurde. Wenn Statistiken für eine Tabelle oder indizierte Sicht aktualisiert werden, können Sie wählen, ob Sie alle Statistiken, nur Indexstatistiken oder nur Spaltenstatistiken aktualisieren möchten. Und schließlich können Sie die Option zum automatischen Aktualisieren von Statistiken für eine Statistik deaktivieren.

Für die meisten DBAs ist das wann die größte Überlegung um die UPDATE STATISTICS-Anweisung auszuführen. Aber DBAs entscheiden auch bewusst oder unbewusst über die Stichprobengröße für die Aktualisierung. Die ausgewählte Stichprobengröße kann sich auf die Leistung der eigentlichen Aktualisierung sowie auf die Leistung von Abfragen auswirken.

Die Auswirkungen der Stichprobengröße verstehen

Die standardmäßige Stichprobengröße für UPDATE STATISTICS stammt von einem nichtlinearen Algorithmus, und die Stichprobengröße nimmt ab, wenn die Tabellengröße größer wird, wie Joe Sack in seinem Beitrag Auto-Update Stats Default Sampling Test gezeigt hat. In einigen Fällen ist die Stichprobengröße möglicherweise nicht groß genug, um genügend interessante Informationen zu erfassen, oder richtig Informationen für das Statistikhistogramm, wie von Conor Cunningham in seinem Post zu Statistik-Stichprobenraten angegeben. Wenn die Standardstichprobe kein gutes Histogramm erstellt, können DBAs wählen, Statistiken mit einer höheren Abtastrate zu aktualisieren, bis hin zu einem FULLSCAN (alle Zeilen in der Tabelle oder indizierten Ansicht werden gescannt). Aber wie Conor in seinem Beitrag erwähnte, ist das Scannen von mehr Zeilen mit Kosten verbunden, und der DBA steht vor der Herausforderung, zu entscheiden, ob er einen FULLSCAN ausführen soll, um zu versuchen, das „bestmögliche“ Histogramm zu erstellen, oder einen kleineren Prozentsatz abzutasten, um die Auswirkungen auf die Leistung zu minimieren das Update.

Um zu verstehen, wann ein Beispiel länger dauert als ein FULLSCAN, habe ich die folgenden Anweisungen mit Kopien der SalesOrderDetail-Tabelle ausgeführt, die mit dem Skript von Jonathan Kehayias vergrößert wurden:

Ich hatte drei Kopien der SalesOrderDetailEnlarged-Tabelle mit den folgenden Merkmalen*:

*Weitere Details zur Hardware finden Sie am Ende dieses Beitrags.

Alle Kopien der Tabelle hatten die folgenden Statistiken, und keine der drei Indexstatistiken enthielt Spalten:

Ich habe die obigen UPDATE STATISTICS-Anweisungen jeweils viermal mit der SalesOrderDetailEnlarged-Tabelle auf meinem Laptop und jeweils zweimal mit den SalesOrderDetailEnlarged-Tabellen auf dem TestServer ausgeführt. Die Anweisungen wurden jedes Mal in zufälliger Reihenfolge ausgeführt, und der Prozedur-Cache und der Puffer-Cache wurden vor jeder Aktualisierungsanweisung gelöscht. Die Dauer und die tempdb-Nutzung für jeden Satz von Anweisungen (gemittelt) sind in den folgenden Diagrammen dargestellt:

Durchschnittliche Dauer – Aktualisierung aller Statistiken für SalesOrderDetailEnlarged

Tempdb-Nutzung – Alle Statistiken für SalesOrderDetailEnlarged aktualisieren

Die Dauern für die Tabelle mit 23 Millionen Zeilen betrugen alle weniger als drei Minuten und werden im nächsten Abschnitt ausführlicher beschrieben. Für die Tabelle auf den SSD_2-Platten dauerte die FULLSCAN-Anweisung 1492 Sekunden (fast 25 Minuten) und die Aktualisierung mit einer Stichprobe von 25 % dauerte 2051 Sekunden (über 34 Minuten). Im Gegensatz dazu dauerte die FULLSCAN-Anweisung auf den 15K-Platten 2864 Sekunden (über 47 Minuten) und die Aktualisierung mit einer Stichprobe von 25 % dauerte 2147 Sekunden (fast 36 Minuten) – weniger als die Zeit für FULLSCAN. Die Aktualisierung mit einer Stichprobe von 50 % dauerte jedoch 4296 Sekunden (mehr als 71 Minuten).

Die Verwendung von Tempdb ist viel konsistenter, zeigt einen stetigen Anstieg mit zunehmender Stichprobengröße und verwendet mehr Tempdb-Speicherplatz als ein FULLSCAN zwischen 25 % und 50 %. Was hier bemerkenswert ist, ist, dass UPDATE STATISTICS es tut verwenden tempdb, was wichtig ist, wenn Sie die Größe von tempdb für eine SQL Server-Umgebung anpassen. Die Verwendung von Tempdb wird im UPDATE STATISTICS BOL-Eintrag erwähnt: