COMPAREX AG
SQL Server: Lösungen für Performance-Probleme, Header

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.

Ein Blogbeitrag von Frank Sander, SQL Server Consultant

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.

 

Problem 1:

„Meine Anwendung wird immer langsamer.“

 

Analyse

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.

SQL-Server: Problembehebung mit Columnstore Indizes

Columnstore Indizes sind oftmals noch nicht relevant, ihre Fragmentierung kann in der dynamischen Verwaltungssicht (DMV, Dynamic Management View)

SQL-Server: Problemhebung Code

z.B. anhand gelöschter Einträge und der Gesamtzahl der Einträge berechnet werden.

Lösung

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.

Fazit

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.

Problem 2:

„Meine Anwendung wird immer langsamer.“ (bei anderer Ursache)

 

Analyse

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

SQL-Server: Code für Problem-Abfrage

lieferte nur Ergebnisse folgender Art:

object_id

name

index_id

type

type_desc

...

8

NULL

0

0

HEAP

...

149575571

NULL

0

0

HEAP

...

565577053

NULL

0

0

HEAP

...

...

 

 

 

 

 

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.

Lösung

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.

Fazit

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.

Problem 3:

„Meine Reports (SSRS) werden extrem langsam generiert“

 

Analyse

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.

Lösung

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

Fazit

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.

Problem 4:

„Die Generierung der Daten innerhalb meiner Anwendung dauert 1 Woche.“

 

Analyse

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.

Lösung

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.

Fazit

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.

Problem 5:

Absturz des SQL Servers

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.

Analyse

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

Lösung

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

Fazit

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.

Zusammenfassung

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.

SQL 2016 Workshop Reihe – Next Generation

Erfahren Sie, was der SQL Server 2016 kann, was er nicht kann, wann sich eine Migration lohnt und wie die Lizenzierung funktioniert.

Die eintägigen Workshops finden in sechs Orten in Deutschland statt und sind für Sie kostenfrei. Empfohlen für IT-Administratoren und IT-Entscheider.

Ich möchte mich anmelden »

Diesen Artikel teilen

Artikel vom:
25.04.2017

geschrieben von:

TAGS:
Performance, SQL Server

Thema:

Kommentieren sie diesen Artikel...

© COMPAREX AG
Zurück nach oben