SQL Server: Lösungen für die 5 häufigsten Performance-Probleme

Im Umgang mit SQL Server kämpfen viele IT-Administratoren immer wieder mit ähnlichen Problemen und Fehlern. Schluss damit! Wir analysieren anhand von konkreten Fallbeispielen die 5 häufigsten Performance-Probleme und zeigen adäquate Lösungen auf.

Fehler sind menschlich und vielfach nicht durch Unwissenheit begründet. Insofern möchte ich Datenbank-Administratoren (DBAs) keineswegs an den Pranger stellen. Vielmehr möchte ich eine Lanze für all jene IT-Administratoren brechen, die neben Datenbanken zusätzlich noch Windows Server, Netzwerke, Storage, einzelne Applikationen, Virtualisierungstools und vieles mehr betreuen müssen. Oftmals ist ihr Verantwortungsbereich thematisch so umfangreich, dass sie sich nicht ausreichend in die einzelnen Themen einarbeiten können.

Insbesondere das Thema Performance ist ein Aspekt vom SQL Server, der vielfach unter den Tisch fällt, sei es bei der Einarbeitung oder für die einmalig durchzuführende, gut durchdachte Installation und Konfiguration einer Instanz. Die ersten beiden Probleme sind zwar hinsichtlich der Kundenaussage identisch, die Ursache ist jedoch unterschiedlich.

Der erste Schritt bei einer solchen Aussage ist für mich immer die Überprüfung der gruppierten und nicht gruppierten Indizes, genauer: deren Fragmentierung. Das folgende Skript liefert für jeden Index seinen Namen, den Namen und das Schema der Tabelle, für die er angelegt ist sowie den Grad der Fragmentierung und die Seitenanzahl des Index. Aufgrund der Einschränkungen innerhalb der WHERE-Klausel werden nur zu pflegende Indizes, d.h. Indizes ausreichender Größe, ausreichender Fragmentierung und der zu pflegenden Typen angezeigt. Gerade bei großen, viel genutzten Datenbanken sollte die Ausführung dieses Skripts innerhalb eines Wartungsfensters liegen, da der Wert für die durchschnittliche Fragmentierung zur Laufzeit bestimmt wird.

Columnstore Indizes sind oftmals noch nicht relevant, ihre Fragmentierung kann in der dynamischen Verwaltungssicht (DMV, Dynamic Management View) z.B. anhand gelöschter Einträge und der Gesamtzahl der Einträge berechnet werden.

In den Fällen, in denen an dieser Stelle Indizes angezeigt werden, muss geprüft werden, inwieweit Wartungspläne zu deren Pflege existieren und wie oft diese ggf. durchgeführt werden. Dementsprechend sollte ein Wartungsplan neu erstellt bzw., wenn möglich, öfter ausgeführt werden. SQL Server liefert für die Neuerstellung und das Neuorganisieren jeweils einen leider kaum zu konfigurierenden Wartungsplan mit. Eine weitere Möglichkeit sind eigene oder schon zur Verfügung stehende Skriptlösungen. Ich empfehle meinen Kunden die Verwendung und Anpassung der Lösung von Ola Hallengren. In Einzelfällen kann auch die Anpassung des Standardfüllfaktors für Indizes Abhilfe schaffen. Dabei sollte allerdings beachtet werden, dass dies eine instanzweite Konfigurationsoption ist und somit für alle Datenbanken gilt.

Obwohl Indexpflege zu den alltäglichen Aufgaben eines Datenbank-Administrators gehört, wird sie oftmals nicht durchgeführt. Dadurch sind nicht gewartete Indizes eine Hauptursache für Performance-Probleme. Allerdings sollte man als Datenbank-Administrator nicht so weit gehen, ohne Rücksprache mit dem Applikationshersteller selbst Indizes in Datenbanken anzulegen, da diese durchaus negative Auswirkungen auf z.B. Masseneinfügeoperationen haben können.

Natürlich habe ich bei dieser vertrauten Aussage das Skript aus dem ersten Beispiel verwendet. Es wurden keine zu pflegenden Indizes angezeigt. Alles in Ordnung also, an den Kunden gewandt meinte ich: „Ihre Indizes sind gepflegt.“, worauf mir der Kunde verwundert mit „Nein?!“ antwortete. Ein Blick auf die eingerichteten Jobs bestätigte seine Zweifel, die Abfrage

lieferte nur Ergebnisse folgender Art:

An dieser Stelle stößt selbst der beste DBA an seine Grenzen. Wo nur Heaps, also keine Indizes zu pflegen sind, kann er dies auch nicht tun.  

In diesem Fall war die Lösung recht einfach. Für die verwendete Applikation wurde schon schrittweise deren Nachfolger eingeführt, in dessen Datenbank die vermissten Indizes vorhanden waren. Der DBA wollte sich dann um eine schnellere Migration der einzelnen Applikationsteile bemühen. Eine Alternative wäre hier sicherlich die Kontaktaufnahme zum Applikationshersteller, um gemeinsam nach einer Lösung zu suchen.

Ein DBA kann nicht alle Ursachen beheben bzw. ist für deren Entstehung verantwortlich. Er sollte sie aber aufzeigen können, nicht nur als Rechtfertigung für bestehende Probleme, sondern auch um in Zusammenarbeit mit beispielsweise dem Hersteller die Probleme lösen zu können.

Ein erster Blick auf die Umgebung unter Verwendung des Performance Monitors (entsprechende Counter in Klammern) ergab: 

•  8GB RAM installiert

• ca. 4GB RAM verfügbar (Memory\Available Mbytes)

• CPU kaum ausgelastet (Processor\%ProcessorTime)

• SQL Server und Reporting Services sind installiert.
  

Bis hierhin deutete nichts auf Performance-Probleme hin. Nur die parallele Installation von SQL Server und Reporting Services wird nicht empfohlen.

Ein Blick auf die Auslagerungsdatei (Paging File\%Usage) offenbarte allerdings das Problem. Die Datei wurde sehr stark genutzt. Ursache waren 7GB maximal zulässiger Arbeitsspeicher für SQL Server. Diese wurden bei einem monatlich stattfindenden Import-Prozess benötigt und daher reserviert und nicht wieder freigegeben. Für das Betriebssystem sowie Reporting Services standen somit nur insgesamt 1GB zur Verfügung, daher auch die hohe Auslastung der Auslagerungsdatei beim Aufruf von Reporting Services. 

Der maximal zulässige Arbeitsspeicher wurde von 7GB auf 5GB reduziert. Dies löste das Problem kurzfristig. Allerdings benötigt SQL Server einmal monatlich 7GB. Dies musste im Nachgang behoben werden, Möglichkeiten sind

• mehr Arbeitsspeicher

• Erhöhung des Arbeitsspeichers für SQL Server nur während des monatlichen Imports

• Optimierung des Imports

Bei der Konfiguration des maximal zulässigen Arbeitsspeichers für SQL Server muss berücksichtigt werden, dass SQL Server Arbeitsspeicher reserviert, auch wenn er ihn aktuell nicht verwendet. Dies ist im Übrigen sinnvoll, wird doch dadurch ein erneutes Laden der Daten vom Storage vermieden, wenn sie abgerufen werden. Außerdem ist zu erwähnen, dass mit der Installation von SQL Server mit dem Performance Monitor von Windows Server überwachbare Performance Counter eingerichtet werden.

Die betroffene Anwendung generiert erwartungsgemäß aus vorhandenen 10GB Daten zusätzliche 20GB. Übliche Performance-Counter (Arbeitsspeicher, CPU) zeigen eher eine geringe Auslastung. Allerdings war die Datendatei ursprünglich 10GB groß und mit einem automatischen Wachstum von 1MB konfiguriert. Dies führte dazu, dass in 1MB-Schritten Daten geschrieben, Speicherplatz reserviert und mit Nullen überschrieben wurde. 

Das automatische Wachstum wurde auf 2GB erhöht. Zusätzlich erhielt das Dienstkonto des SQL Servers die Berechtigung „Perform volume maintenance tasks“ bzw. „Durchführen von Volumenwartungsaufgaben“. Die damit eingegangenen Risiken können in der Dokumentation von Microsoft nachgelesen werden.

Die Standard-Einstellungen für Dateigröße und –wachstum bei der Erstellung einer Datenbank müssen in der Regel an die Anforderungen der jeweiligen Applikation angepasst werden. Selbst wenn Applikationshersteller diesbezüglich schon Überlegungen anstellen, sollte die Plausibilität der konfigurierten Werte durch den DBA geprüft werden, da das Datenaufkommen je Anwender unterschiedlich sein kann. Im Übrigen empfehle ich diese Überlegungen auch immer im Rahmen einer Migration anzustellen.

Der virtuelle SQL Server des Kunden lief sehr langsam bzw. reagierte nicht mehr. Zweimal stürzte er mit Blue Screen und der Fehlermeldung CLOCK_WATCHDOG_TIMEOUT (101) ab

Durch Memory Ballooning wurde der der virtuellen Maschine (VM) zugeordnete Speicher um zwei Drittel reduziert.

Aufgrund des Speichermangels des Hosts wurde die VM auf einen anderen Host transferiert.

Grundsätzlich wird der Einsatz von SQL Server in virtualisierten Umgebungen unterstützt. Von den Herstellern der Virtualisierungslösung gibt es oftmals auch Whitepaper zu diesem Thema. Deren Lektüre ist, sollte man SQL Server in einer virtualisierten Umgebung betreiben wollen, unbedingt zu empfehlen.

Ich hoffe ich konnte an dieser Stelle verdeutlichen, dass Performance-Probleme mit SQL Server nicht notwendigerweise komplexe Ursachen haben müssen und vor allem, dass DBAs diesbezüglich ihre Hausaufgaben (Indexpflege, korrekte Konfiguration des maximalen Arbeitsspeichers der Instanz, korrekte Konfiguration der VM usw), die kurz mit „Lesen, Verstehen und Anwenden von Best Practices“ umschrieben sind, kennen sollten.