Ich wurde vor einigen Tagen von einem Kollegen angesprochen. Er habe da einen SQL Server, der ganz fürchterlich schlecht laufe. Dedizierter Server für eine neue SharePoint-Umgebung, 8 logische Cores, CPU-Auslastung 99%. In SharePoint lief ein Verarbeitungsprozess, der eine große Liste mit 25.000+ Einträgen schrittweise abarbeitete, also List-Item laden, aktualisieren, laden, aktualisieren usw. Aus SQL-Sicht nicht schön, aber sicherlich kein Grund dafür die CPU zum Glühen zu bringen.

Hohe CPU Auslastung (Abbildung ähnlich)

Hohe CPU Auslastung (Abbildung ähnlich)

Eine Analyse zeigte schnell, dass das Verhalten nur mit einer bestimmten ContentDB auftrat. Der Verdacht fiel nun auf die Indizes und eine Stichprobe bestätigte dies. Sie waren hochgradig fragmentiert (98% und mehr) und die Abfragezeiten lagen teilweise bei über 15 Sekunden pro verarbeitetem Item. Also schnell eine Indexwartung durchgeführt, was Gott sei Dank zu dem Zeitpunkt möglich war. Ergebnis: Die CPU Auslastung ging zurück auf nur noch 10 bis 15%, die Abfragedauer sank auf wenige 100 Millisekunden.

Dies ist nur ein Beispiel dafür wie viel Performance durch fehlende Wartung oder falsche Konfiguration verloren gehen kann, gerade wenn nur das SQL Server-Setup durchgeklickt wird und keine sinnvolle Erstkonfiguration vorgenommen wird.

Man sollte sich also grundsätzlich Gedanken zur Indexwartung machen und natürlich zur Aktualisierung der Statistiken. Selbst bei Systemen, die eigene Wartungsmechanismen mitliefern, wie die Health Analyzer Checks des SharePoint, kann es sinnvoll sein, dort ein Sicherheitsnetz einzuplanen. Das funktioniert z.B. sehr gut mit der Maintenance Solution von Ola Hallengren (https://ola.hallengren.com/). Aber auch mit den SQL Server-Wartungsplanbordmitteln lassen sich inzwischen granulare Indexwartungen mit wenigen Klicks einrichten. Damit konnte beispielsweise ein 72-stündiger Index Rebuild für 1+ TB Daten auf 12 Stunden mit gezielten Reorgs und Rebuilds reduziert werden.