en
de

SQL Server Performance Optimierung – Teil 1

15 Juni 2013
| |
Lesezeit: 4 Minutes

Wer kennt das Problem nicht? Auf dem Testsystem funktionierte die Applikation einwandfrei und schnell, nun ist sie ausgerollt und die Benutzerinnen und Benutzer sind mit der Performance nicht zufrieden. In kleineren Projekten gibt es keinen Datenbankadministrator der sich diesem Problem annehmen kann, so dass sich der Entwickler oder die Entwicklerin selbst darum kümmern muss.

Dieser mehrteilige Blog soll einen Weg für den Softwareentwickler, die Softwareentwicklerin aufzeigen, wie der Datenzugriff einer Applikation performanter gemacht werden kann.

Der Optimierungsprozess

Bevor wir uns auf die Suche nach der verlorenen Performance machen, noch ein Wort zur Methodik. Wir können nicht auf gut Glück an unserer SQL Server Instanz oder an unserer Applikation etwas ändern und hoffen, dass die Applikation danach schneller ist. Abbildung 1 zeigt den Optimierungsprozess, den wir verfolgen sollten:

Optimierungsprozess

Optimierungsprozess

  1. Als erstes muss die Performance gemessen werden. Dazu gehören zum Beispiel die Antwortszeiten oder die Anzahl der Lesezugriffe für einzelne Datenbankabfragen.
  2. Im zweiten Schritt muss dann ein Flaschenhals identifiziert werden. Dabei ist darauf zu achten, dass derjenige Flaschenhals beseitigt wird, der dem Benutzer am meisten bringt. Es nützt ihm wenig, wenn der monatliche Report doppelt so schnell erstellt ist, er aber in der täglichen Arbeit immer noch gebremst wird.
  3. Nun kann genau dieser Flaschenhals behoben werden.
  4. Der wichtigste Schritt im ganzen Prozess ist das Verifizieren der Optimierung. Es können nun die gleichen Messungen nochmals gemacht und mit den Resultaten von Schritt 1 verglichen werden. Wichtig ist hier, dass man sich nicht nur auf den optimierten Punkt beschränkt, sondern die ganze Applikation betrachtet. Das Ziel wäre verfehlt, wenn nur ein Teil schneller läuft, der Rest aber noch langsamer geworden ist.

Wo geht die Performance verloren?

Nun stellt sich die Frage, wo die Performance verloren geht. Es gibt vier Schichten, die wir einzelnen betrachten und untersuchen können:

  • Zuunterst haben wir die Hardware. In diesen Bereich gehören vor allem die Disks, auf denen unsere Daten schlussendlich gespeichert sind. Aber auch die Maschine, auf der unsere SQL Server Instanz läuft, hat einen Einfluss auf die Performance.
  • Zur physikalischen Datenbankstruktur gehören die Tabellen und die Stored Procedures, wie sie in der Datenbank vorhanden sind.
  • Die logische Datenbankstruktur beschäftigt sich mit den Entitäten, wie sie in der Applikation vorkommen.
  • Auf der obersten Schicht haben wir die Applikation und dessen Datenbankzugriff.

Die Hardware

Als erstes betrachten wir den untersten Layer; die Hardware und der Server. Diese Untersuchung ist natürlich nur möglich, wenn wir Zugriff auf den Server haben. Nutzen wir zum Beispiel Microsoft Azure SQL Databases, so haben wir keinen Zugriff auf den physikalischen Server.

Im Optimierungsprozess haben wir gesehen, dass wir als erstes die Performance messen müssen. Dazu haben wir verschiedene Tools zur Auswahl, die uns das Betriebssystem oder der SQL Server zur Verfügung stellt:

  • Mit Hilfe des Windows Task Managers oder des Sysinternals Process Explorers lässt sich die Auslastung des Servers anzeigen. Interessant ist hier vor allem die Speicher- und die CPU Auslastung. Aber auch wie viele andere Prozesse auf dem Server am Laufen sind.
  • Ein weiteres Tool das uns zur Verfügung steht ist der Activity Monitor. Es ist im SQL Server Management Studio zu finden. Es zeigt uns, wie viele und welche Applikationen auf unsere Datenbankinstanz zugreifen. So zeigt uns Abbildung 2 schön, dass auch der Reporting Service auf der gleichen Datenbank Instanz läuft, wie unsere Applikation.
Activity Monitor

Activity Monitor

  • Auch die integrierten Performance Counters von Windows können uns Hinweis auf einen Flaschenhals geben. Besonders interessant sind die beiden Counters Avg. Disk Queue Length und SQL Server: Wait Statistics. Diese zeigen auf, wie fest die Harddisks (insbesondere jene Disks mit den Datenfiles) ausgelastet sind und auf was der SQL Server warten muss.

Mit den gemessenen Werten können wir uns auf die Suche nach der Ursache machen. Die einfachste Erklärung die es gibt, ist eine zu langsame Hardware. Auch wenn es sich nach einer einfachen Ausrede anhört, es kann vorkommen, dass die Hardware den Datenmengen nicht mehr gewachsen ist. Eine weitere Ursache ist, dass sich der SQL Server mit anderen Serverapplikationen um die Ressourcen streiten muss. Virenscanner, Web- und Applikationsserver, die neben dem Datenbankserver auf der gleichen Hardware betrieben werden, entziehen dem Datenbankserver wertvolle Ressourcen. Dasselbe gilt auch für die Datenbanken anderer Applikationen, die alle auf der gleichen SQL Server Instanz laufen. All diese Datenbanken buhlen um die Ressourcen des Servers. Die Harddisk kann ein weiterer Flaschenhals sein. Auch wenn dieser Punkt mit dem Aufkommen von SSDs im Serverbereich nicht mehr so von Bedeutung ist. Befinden sich alle Datenfiles, Logfiles die TempDB und die SystemDB auf der gleichen Disk, so ist diese nur noch am Positionieren des Lesekopfes. Dieser Umstand wird noch verschlimmert, wenn die Dateien stark fragmentiert auf der Disk abgelegt sind.

Wir haben nun verschiedene Ursachen gesehen. Der nächste Schritt ist diese zu beheben:

  • Ideal ist natürlich, wenn unsere Applikationsdatenbank einen eigenen dedizierten Server für sich alleine erhält. Alle Services, die nicht benötigt werden, sind abgeschaltet und dem SQL Server stehen die ganzen Ressourcen zu.
  • Sind mehrere Disks vorhanden, so macht es Sinn, die Daten- und Logfiles auf verschiedene Disks zu platzieren. Dies gilt auch für die System- und TempDB. Diese sollten auf einer anderen Disk abgelegt werden, als die Applikationsdaten. Zudem sollte darauf geachtet werden, dass die Dateien nicht fragmentiert sind.
  • Eine weitere Möglichkeit um die Hardware zu entlasten, ist das Ablegen der Daten in komprimierter Form. Der SQL Server unterstützt das komprimierte Speichern von Tabellen und Indizes. So müssen weniger Daten gelesen werden, jedoch erhöht sich die CPU Auslastung.
    Bei grossen Tabellen macht es eventuell auch Sinn diese zu partitionieren und auf mehreren Disks abzulegen. So können die Daten parallel geladen werden. Diese beiden Features sind jedoch nur in der Enterprise Edition des SQL Servers verfügbar.

Nachdem ein Flaschenhals beseitigt wurde, darf natürlich der letzte Schritt im Optimierungsprozess nicht vergessen werden, nämlich das Validieren der hoffentlich besseren Performance.

Kommentare (0)

×

Updates

Schreiben Sie sich jetzt ein für unsere zwei-wöchentlichen Updates per E-Mail.

This field is required
This field is required
This field is required

Mich interessiert

Select at least one category
You were signed up successfully.

Erhalten Sie regelmäßige Updates zu neuen Blogartikeln

Jetzt anmelden

Oder möchten Sie eine Projektanfrage mit uns besprechen? Kontakt aufnehmen »