Ich will mit diesem Artikel keinen allgemeinen und vollständigen Leitfaden zur Lösung von Performanceproblemen geben, aber aufzeigen an welchen Stellen man prüfen muss.
Bei meinen Ausführungen beziehe ich mich On Premise Installationen. In der Cloud ist zwar nicht alles ganz anders, aber der Einfluss auf die Installation ist anders.
Bedenken Sie immer, Performance erreicht man nur durch das Zusammenspiel einer guten Infrastruktur mit einem guten DB-Design und einer guten Programmierung.
Diese drei Teile müssen zusammen passen.
Installation und Hardware
Aktuelle Hardware, insbesondere Serverhardware ist extrem leistungsfähig. Gerade die Leistungsfähigkeit der CPUs und das Angebot an RAM ist selten das Problem.
Die Erfahrung zeigt, dass es sehr häufig zu Problemen in Bereich IO kommt.
Neben lokalen Festplatten ist die Verwendung von SANs das häufigste Szenario.
Worauf muss man achten, dass hier alles rund läuft?
Wie kann man erkennen wo es klemmt?
Beginnen wir mit der zweiten Frage. Der SQL-Server speichert eine Reihe von Informationen zu den Datenzugriffen ab. Mit einer Überwachung dieser Daten kann man relativ einfach problematische Laufwerke, Datenbanken und Datenbankfiles finden. Das Stichwort ist Latenz.
Wenn man jetzt diese Daten mit den langsamen und problematischen Prozessen über die Zeit korreliert, hat man Ansatzpunkte für die Lösung.
Ein IO-Kanal (inkl. Datenzugriff) hat nur eine bestimmte Kapazität, je näher man der Grenze kommt oder sie gar überschreitet, desto langsamer fliesen die Daten.
Wichtig: Für die Performance sind nur die Hardware IO-Kanäle wichtig, die logische Zuordnung spielt keine Rolle!
Was bedeutet das aber für eine Installation?
- Viele, schnelle IO-Kanäle
Bei internen Festplatten gibt es mindestens zwei wichtige Komponenten: den Controller und die Festplatte. Das SSDs schneller als HDDs sind, ist keine Neuigkeit. Beachten Sie aber, wenn SSDs mehr als 60% befüllt sind, kann man ein Sinken der Performance feststellen. Planen Sie durchaus mit dem doppelten Speicherplatz. Der Controller hat einen gewissen Durchsatz und dieser sollte in der Größenordnung der Summe der angeschlossenen Festplatten sein, eher größer. Das Anlegen von mehreren Partitionen auf einer Festplatte bringt keine Vorteile! - Das richtige SAN
Spätestens wenn ein Cluster betrieben werden soll, wird ein SAN als Speicherort eingesetzt.
Der Einsatz von SANs ist nicht problemlos! Ein SAN, das als Fileshare dient ist nicht die beste Wahl! Achten Sie auf die richtige Konfiguration des SAN. Auch zeigen SANs oft den Effekt, dass sie ab einem Füllstand von 60% – 70% langsamer werden.
Es gibt spezielle SANs für Datenbanken. In Tests wurden die Datenbankanwendungen damit um den Faktor 10 schneller. Es ist auch kontraproduktiv zu viele Server an ein großes SAN zu hängen. - Spezialbehandlung für die TempDB
Die TempDB ist für die Performance des SQL-Servers sehr entscheidend.
Meine Empfehlung ist, die TempDB auf schnelle lokale Platten zu legen. Diese Lösung ist auch im Clusterbetrieb möglich. Ein SAN sollte man nur einsetzen, wenn es wirklich richtig schnell ist. - RAID bei lokalen Platten?
- Ein RAID 1 macht Sinn um gegen Datenverlust geschützt zu sein. Für die TempDB ist der Nutzen fragwürdig. Hier ist zu entscheiden, ob ein kurzer Ausfall zum Wechseln der Platte und ein Restart vertretbar ist oder nicht.
- Die Frage bei RAID 10 ist, ist ein RAID 10 oder 2 mal RAID 1 besser? Die Antwort ist nicht eindeutig.
- Von RAID 5 rate ich ab.
- Zuordnung der Datenbankfilse zu den Laufwerken
Ziel bei der Zuordnung ist, eine möglichst gleiche Lastverteilung zu jedem Zeitpunkt zu erreichen. Hierzu ist Wissen über die Arbeitsweise der Datenbankaplikationen und der Prozesse notwendig! Es gibt aber auch Grundregeln mit denen man anfangen kann. Das TransactionLog sollte getrennt von den Datebankfiles liegen. Datenbanken, die gleichzeitig benutzt werden sollte man trennen.
DB Design
- DB auf DB-Files verteilen
Nach dem vorangehenden Abschnitt wird sofort klar, beim Design der DB müssen die entsprechenden Voraussetzungen geschaffen werden.
Wichtig: Der Anspruch auf Perfomance und Größe der DB bestimmen den Aufwand den man treiben sollte. DBs unter 100 GB sind sicherlich noch nicht die großen DBs.
Es ist zu klären, wie viele DB-Files verwendet werden sollen und wie die Verteilung der Tabellen und Indizes auf die Files erfolgen soll. Ziel ist wieder die möglichst gleichmäßige Verteilung der IO-Last zu jedem Zeitpunkt. Diese Verteilung ist von den imlementierten Algorithmen und Abfragen abhängig. Die Verteilung kann sich daher über die Zeit ändern!
- Das Transaction Log
sollte man immer im Auge haben. Ins Auge springt dann sofort der Unterschied zwischen DELETE und TRUNCATE. Gerade das Löschen alter Daten in Log-Tabellen kann ein Problem sein, wenn zu viele Datensätze auf einmal glöscht werden.
- Indizes
sind für eine perfomante DB das A und O. Es gibt sicherlich Grundregeln für das Minimum der zu erstellenden Indizes. Die große Frage ist aber, wer legt die notwendigen Indizes fest? Der Entwickler hat Erfahrungen und kann auf der Entwicklungsumgebung testen. Das ist sicherlich ein Anfang. Die Wahrheit ist aber die Produktionsumgebung, da kann es erhebliche Unterschiede zur Entwicklungsumgebung geben! Die Produktionsumgebung ist aber das Reich der Admins. In der Regel haben auch nur Sie zugriff auf die Analysedaten des SQL-Servers.
- Partitionierung
von Tabellen ist bei Beladeprozessen und an vielen anderen Stellen ein sehr interessantes Feature. Genauer werde ich in einem späteren Artikel eingehen.
Abschlußbemerkung
Über gute Programmierung will ich keine Ausführungen machen, da kann man Bücher schreiben.
Wie zu erwarten war, gibt es nicht das „RICHTIGE“. Es is aber sicher, dass man ein performates System nur dann erreicht, wenn alle Beteiligten konstruktiv zusammenarbeiten.
Meine Erfahrung sagt, das ist eine Herausforderung!
