Bei der Untersuchung einer langsamen Abfrage stellte sich heraus, dass der Ausführungsplan außergewöhnlich suboptimal war (eine verschachtelte Schleife, die 9 Millionen Ausführungen einer Suche ausführt, bei der die geschätzte Anzahl der Ausführungen 1 betrug). Nachdem ich bestätigt habe, dass einige relevante Statistiken, die tatsächlich veraltet sind, die Statistiken neu erstellt haben und das Leistungsproblem effektiv gelöst ist.
In dieser Datenbank ist die automatische Aktualisierungsstatistik aktiviert (standardmäßig aktiviert). Ich verstehe, dass es einen Schwellenwert für automatische Statistikaktualisierungen gibt, basierend auf 20% + 500 Zeilenänderungen (Aktualisieren / Einfügen / Löschen). Dieser Schwellenwert scheint bei mehreren Indizes in hohem Maße überschritten worden zu sein. Daher scheint es entweder (A) ein Problem mit automatischen Updates zu geben oder (B) die Update-Strategie enthält mehr, als ich online finden konnte Dokumentation.
Ich schätze, dass eine geplante Aufgabe eingerichtet werden kann, um Statistiken zu aktualisieren, und dies ist wahrscheinlich der Ansatz, den wir verfolgen, wenn keine andere Lösung gefunden werden kann, aber wir sind verwirrt darüber, warum eine so große Anzahl von Änderungen keine auslösen würde Automatische Aktualisierung für einige Statistiken - Verstehen, warum wir möglicherweise entscheiden können, welche Statistiken von einer geplanten Aufgabe aktualisiert werden müssen.
Einige zusätzliche Hinweise:
1) Das Problem wurde in einer Datenbank festgestellt, in der die Daten durch einen Auslastungstest erstellt werden und daher in kurzer Zeit eine große Datenmenge hinzugefügt wird, wenn die automatische Aktualisierung regelmäßig erfolgt (z. B. einmal täglich um meistens) dann kann dies einige der beobachteten Verhaltensweisen erklären. Auch unsere Auslastungstests belasten die Datenbank in der Regel stark. Daher frage ich mich, ob SQL Statistikaktualisierungen bei hoher Auslastung aufschiebt (und anschließend die Statistiken aus irgendeinem Grund nicht aktualisiert).
2) Beim Versuch, dieses Problem mit einem Testskript mit aufeinanderfolgenden INSERT-, SELECT- und DELETE-Anweisungen neu zu erstellen, ist das Problem nicht aufgetreten. Ich frage mich, ob der Unterschied darin besteht, dass diese Anweisungen jeweils viele Zeilen pro SQL-Anweisung betreffen, während unser Lasttest-Skript dazu neigt, Zeilen einzeln einzufügen.
3) Die betreffende Datenbank ist auf das Wiederherstellungsmodell 'Einfach' eingestellt.
Einige relevante Links:
- Checkliste zum Analysieren langsam laufender Abfragen
- Verwenden von Statistiken zur Verbesserung der Abfrageleistung
Ich habe dieses Problem auch über Microsoft Connect angesprochen:
UPDATE 30.06.2011:
Bei weiteren Untersuchungen glaube ich, dass Statistiken, die über die Schwellenwerte hinaus veraltet sind (z. B. 500 Zeilen + 20%), Statistiken sind, die von der Problemabfrage nicht verwendet werden. Daher werden sie wahrscheinlich aktualisiert, wenn eine Abfrage ausgeführt wird das erfordert sie. Für die Statistiken , die sich von der Abfrage verwendet, diese werden regelmäßig aktualisiert. Das verbleibende Problem ist dann, dass diese Statistiken für den Abfrageplanoptimierer nach nur relativ wenigen Einfügungen grob irreführend sind (z. B. die oben genannten 9 Millionen Suchanfragen verursachen, bei denen die geschätzte Anzahl 1 war).
Meine Vermutung zu diesem Zeitpunkt ist, dass das Problem mit einer schlechten Auswahl des Primärschlüssels zusammenhängt. Der Schlüssel ist eine eindeutige Kennung, die mit NEWID () erstellt wurde. Dadurch wird sehr schnell ein stark fragmentierter Index erstellt - insbesondere als Standardfüllfaktor in SQL Server ist 100%. Meine Vermutung ist, dass dies nach relativ wenigen Zeileneinfügungen zu irreführenden Statistiken führt - weniger als der Schwellenwert für die Neuberechnung der Statistiken. Dies alles ist möglicherweise kein Problem, da ich viele Daten generiert habe, ohne die Indizes teilweise neu zu erstellen. Daher können die schlechten Statistiken eine Folge der daraus resultierenden sehr hohen Indexfragmentierung sein. Ich denke, ich muss meinem Auslastungstest SQL Server-Wartungszyklen hinzufügen, um eine bessere Vorstellung von der Leistung auf einem realen System über lange Zeiträume zu erhalten.
UPDATE 10.01.2012:
Ein weiterer zu berücksichtigender Faktor. SQL Server 2005 wurden zwei Ablaufverfolgungsflags hinzugefügt (und scheinen 2008 noch vorhanden zu sein), um bestimmte Mängel im Zusammenhang mit dem Auftreten veralteter und / oder irreführender Statistiken zu beheben. Die fraglichen Flaggen sind:
DBCC TRACEON(2389)
DBCC TRACEON(2390)
MSDN: Ian Joses WebLog: Aufsteigende Schlüssel und automatisch schnell korrigierte Statistikstatistiken zu aufsteigenden Spalten, Fabiano Amorim
Sie sollten natürlich sehr vorsichtig sein, wenn Sie diese Flags aktivieren, da sie sich nachteilig auswirken können.
quelle