3 Ausführliche Performanceanalyse

Wenn das dringende Performanceproblem beseitigt oder zumindest eine schnelle Lösung gefunden wurde, damit Server und Datenbanken kurzfristig wieder nutzbar sind, ist es an der Zeit, sich einer ausführlichen Analyse zuzuwenden. Das Hauptziel dabei liegt darin, die eigentlichen Ursachen der Performanceprobleme zu erkennen (und idealerweise auch zu beheben).

3.1 Vorgehensweise

Um bei der medizinischen Analogie zu bleiben, befindet sich der Patient (der SQL Server) jetzt nicht mehr im kritischen Zustand, sodass man sich die Zeit für eine gründliche und ausführliche Analyse nehmen kann. Dadurch erhält man auch die Möglichkeit, nicht nur die akuten Symptome eines Problems zu behandeln, sondern auch den Problemursachen auf den Grund zu gehen, um diese im Idealfall zu beseitigen.

Dabei müssen Sie sich nicht an die Reihenfolge der in diesem Kapitel beschriebenen Analysemaßnahmen halten. Im besten Fall hat die schnelle Erstanalyse des akuten Problems bereits einige mögliche Problembereiche aufgedeckt, die Sie nun genauer unter die Lupe nehmen können. Aber auch wenn dies nicht der Fall ist, können Sie die im Folgenden beschriebenen Abschnitte des Kapitels in beliebiger Folge abarbeiten.

3.2 Prüfung von Server und Betriebssystem

Damit eine Serveranwendung wie der SQL Server performant laufen kann, muss die richtige Hardware nicht nur vorhanden, sondern auch entsprechend konfiguriert sein. Dasselbe gilt für das Betriebssystem, das quasi als Schnittstelle zwischen Hardware und SQL Server fungiert und letzterem die benötigten Ressourcen zur Verfügung stellt.

Prozessor

Seit einigen Jahren steigen die Taktraten von neueren Prozessorgenerationen nicht mehr gravierend, sondern haben sich bei Werten zwischen 2 und 3 GHz eingependelt. Stattdessen setzt man mittlerweile neben besserem Caching-Verhalten (durch einen größeren prozessorinternen Cache) auf mehr Parallelität durch die Verwendung von mehr CPUs, aber auch mehr Kernen pro CPU.

Dies muss jedoch von dem verwendeten Betriebssystem sowie der genutzten Edition von SQL Server auch unterstützt werden. Windows 2008 R2 Standard unterstützt beispielsweise maximal vier CPUs, während die Enterprise Edition acht CPUs nutzen kann – jeweils unabhängig von der Anzahl der Cores pro CPU. Bei SQL Server kann die Express Edition nur eine CPU nutzen, die Standard Edition schon vier und erst die Enterprise Edition hat hier keine eigene Obergrenze, sondern wird nur durch das darunterliegende Betriebssystem begrenzt. Wenn Sie also eine zu kleine Edition von Windows oder SQL Server nutzen, laufen Sie Gefahr, in teure CPUs investiert zu haben, die nicht alle verwendet werden.

Hauptspeicher

Dies ist der Bereich, in dem sich durch Hardwareaufrüstung am ehesten etwas erreichen lässt. Dies setzt allerdings voraus, dass sowohl vom Betriebssystem als auch von SQL Server eine Edition verwendet wird, die diesen auch nutzen kann.

Generell sollte man heutzutage im Serverumfeld ausschließlich die 64-Bit-Varianten nutzen, da die 32-Bit-Varianten lediglich 4 GB adressieren können.

Auch die Editionen von SQL Server haben definierte Obergrenzen für den nutzbaren Hauptspeicher. So kann die Express Edition maximal 1 GB verwenden, die Standard Edition mindestens 64 GB (bei SQL Server 2008 unbegrenzt), und spätestens die Enterprise Edition kann den gesamten vom Betriebssystem bereitgestellten Speicher nutzen.

Stellen Sie daher sicher, dass die verwendete Version und Edition des Betriebssystems den gesamten vorhandenen Speicher auch verwenden kann.

Festplatten

Zugriffe auf physikalische Datenträger wie Festplatten sind vergleichsweise langsam. Daher versucht SQL Server, diese nach Möglichkeit durch intelligentes Caching zu minimieren. Muss aber dennoch auf den Datenträger selbst zugegriffen werden, gibt es ein paar hilfreiche Tricks, mit denen die Zugriffe möglichst performant ausgeführt werden können.

Prüfen Sie, ob die folgenden Dateien auf verschiedene Platten(-systeme) verteilt sind, um einen parallelen Zugriff zu ermöglichen:

• System (Betriebssystem und SQL Server)
• Windows-Auslagerungsdatei
• Datenbankdateien
• Protokolldateien
• TempDB (Datenbank und Protokoll)
• Filestream-Freigabe (sofern verwendet)
• Back-up-Dateien

Wenn weniger Platten zur Verfügung stehen, sollten zumindest die Dateien, die häufig gleichzeitig verwendet werden, auf diesen verteilt werden: System, Datenbank, Protokoll und TempDB.

Mit frei erhältlichen Tools wie beispielsweise SQLIO lassen sich die Zugriffszeiten der verschiedenen Plattensysteme testen. Prüfen Sie alle verfügbaren Systeme, um die Dateien dann so zu verteilen, dass insbesondere Protokoll und TempDB auf möglichst schnellen Datenträgern liegen, während für Back-ups die langsamsten Datenträger genutzt werden können.

Alle Datenträger nutzen eine fest definierte Blockgröße, die bei Dateisystemen wie NTFS beim Formatieren festgelegt werden kann. Da SQL Server Daten in 64-KB-Blöcken liest und schreibt, stellt dies auch die optimale Blockgröße für die Datenträger dar, auf denen Datenbank- und Protokolldateien liegen.

Netzwerk

Prüfen Sie, ob die im Server verwendeten Netzwerkkarten mit der maximal möglichen Geschwindigkeit und im Vollduplex-Modus laufen. Hierzu finden Sie im Betriebssystem unter den Eigenschaften derNetzwerkverbindung einen Punkt zur Konfiguration der Netzwerkkarte. Bei den meisten Netzwerkkartentreibern finden Sie hier unter den erweiterten Eigenschaften eine Einstellung fürVerbindungsgeschwindigkeit undDuplex-Modus. Sollte hier ein zu niedriger Wert oder auch Halbduplex-Modus eingestellt s