Tipps zur SQL-Server-Wartung – Teil 1

Wie bereits im Blogpost „Optimale Einrichtung der SQL-Datenbank“ angekündigt, liefern wir euch diesmal einige handliche Tipps zur Wartung des SQL-Servers. Denn auch bei sachgemäßem Betrieb treten mit der Zeit einige Probleme auf, die für erneute Geschwindigkeitseinbußen sorgen. Daher solltet ihr auch bei eurem SQL-Server immer mal die Schrauben nachziehen – ihr lasst ja euer Auto auch nicht über die Jahre vor sich hin rosten.

Datenbanken – das Was und Wieso

JTL-Wawi nutzt Microsoft SQL-Datenbanken als zentralen Speicherort für jegliche Daten. Dort hinterlegt unsere Software Artikel- und Kundeninformationen für den jeweiligen Mandanten der Software, aber auch jegliche Daten zu Bestellungen, eBay oder Amazon. Da alle Wawi-Installationen innerhalb eines Unternehmens auf die gleiche Datenbank zugreifen müssen, erklärt dies ihren entscheidenden Einfluss auf die Gesamtgeschwindigkeit. Denn je höher die Zahl der Nutzer auf einem womöglich langsamen und unsauber aufgesetzten SQL-Server, desto länger braucht das System, um die gewünschten Datenanfragen abzuarbeiten.

Die Hardware-Grundlage

Die Wahl der richtigen Hardware ist ein entscheidender Faktor für schnelle Datenzugriffe auf einen SQL-Server. Ein möglichst leistungsstarker Prozessor erlaubt dem System, sämtliche Anfragen in kürzester Zeit abzuarbeiten. Außerdem raten wir zum Einsatz von insgesamt vier Festplatten. Da eine SQL-Abfrage mehrere Schreib-Aktionen beinhaltet, kann durch die Verwendung mehrerer Festplatten ein deutlich schnellerer Datendurchsatz erzielt werden. Im Idealfall richten User die Datenzugriffe also wie folgt ein:

• Der SQL-Server ist, abgesehen vom Betriebssystem, das einzig installierte Programm auf dem Rechner
• Installiert den SQL-Server auf derselben Festplatte, auf der auch das Betriebssystem liegt. (Festplatte 1)
• Speichert sowohl das .mdf-File als auch das .log-File auf getrennten Datenträgern (Festplatten 2 und 3)
• Die Dateien der TempDB legt ihr ebenfalls auf einer eigenen, bestmöglich der schnellsten Platte ab (Festplatte 4)

Während Nutzer der Express-Edition damit bereits die empfohlenen Hardware-Anforderungen erfüllen, gibt es für Besitzer der Standard-, Enterprise- oder Web-Edition einige Unterschiede. Da diese mehr als eine CPU pro Abfrage und mehr Arbeitsspeicher nutzen können, empfehlen wir neben den oben genannten Punkten noch die folgenden:

• Möglichst viele CPUs, um die allgemeine Rechenleistung für die großen Datenbanken zu verbessern
• Mindestens 8 Gigabyte Arbeitsspeicher, um möglichst viele Daten aus dem schnellen Zwischenspeicher nutzen zu können.

Habt ihr diese Hardware-Anforderungen erfüllt, ist der erste wichtige Schritt getan. Die Infrastruktur für rasante Datenbankabfragen ist geschaffen.

Software-Feintuning

Ein dicker Motor macht noch lange kein schnelles Auto – das Feintuning ist das Entscheidende. Gleiches gilt auch für Software. Nur weil eure Hardware vorbildlich ist, läuft nicht automatisch alles optimal. Die richtigen Einstellungen sind entscheidend.

Euer SQL-Server kann für maximale Kompatibilität auf verschiedene Versionen gesetzt werden. Die Wawi unterstützt ab Version 1.0 alle Varianten zwischen SQL 2008R2 und 2014. Die Kompatibilitätsgrade staffeln sich wie folgt:

SQL 2008R2: 100

SQL 2012: 110

SQL 2014: 120

Für die bestmögliche Performance setzt ihr euren Server auf den tatsächlichen Grad der Version. Verwendet ihr also beispielsweise SQL 2014, sollte der Wert 120 lauten. Über das SQL Managementstudio wählt ihr dazu im Objekt-Explorer die Datenbank aus, öffnet mit einem Rechtsklick das Kontextmenü und geht auf Einstellungen. Dort findet ihr unter dem Tab Optionen den Kompatibilitätsgrad.

Ein wichtiger Faktor für bessere Server-Leistung ist die Deaktivierung von Autoshrink und Autoclose in der Datenbank. Autoshrink ist permanent bemüht, die .mdf-Datei zu verkleinern. Das Resultat: Der Server ist kontinuierlich mit sich selbst beschäftigt und fragmentiert zusätzlich die Festplatte. Autoclose leert wiederum jedes Mal euren Arbeitsspeicher, wenn alle Verbindungen zum Server geschlossen werden. Das klingt zwar im ersten Moment gut, ist es aber leider nicht. Denn viele wichtige Dateien müssen beim Aufbau der nächsten Verbindung wieder in das RAM geladen werden – erneut sinkt die Performanz des Servers.

Wer nun noch einige Dateigrößen vordefiniert, erspart dem System, diese künftig selbst abzuändern. Gleichzeitig erschafft ihr dadurch auf der Festplatte eine durchgängige Datei, die automatische Erweiterung durch das System hingegen eine fragmentierte Version. Auch dies beeinflusst die Geschwindigkeit der Datenbank im negativen Maß.

• Vergrößert das .mdf-File der Datenbank auf mindestens 1 Gigabyte, im besten Falle legt ihr direkt eine Größe von 10 Gigabyte fest.

• Auch die .log-Datei benötigt eine Anpassung. Die Idealgröße hierfür beträgt 100 Megabyte.
• Die .mdf- und .log-Dateien der Temp-DB solltet ihr ebenfalls auf 100 Megabyte einstellen.

Besonderheiten der SQL-Server-Editionen

Sowohl die Express-Edition als auch die Standard-, Enterprise- und Web-Versionen haben einige wenige Eigenheiten bei der Einstellung der Software.

Nutzer der Express-Version sollten nach den oben genannten Schritten noch die folgende Einstellung treffen:

• Begrenzt den Arbeitsspeicher auf 1 Gigabyte, um die Auslagerung von größeren Dateien auf die Festplatte einzuschränken.

Nutzer der Standard-, Enterprise- und Web-Versionen treffen nach den oben genannten Schritten folgende Einstellungen:

• Für jeden vorhandenen CPU-Kern solltet ihr ein weiteres .mdf-File in der Temp-DB mit einer Größe von 100 Megabyte und einer Vergrößerung von 100 Megabyte anlegen. Da die CPUs parallel arbeiten können, haben sie somit Zugriff auf jeweils eigene Temp-DB-Dateien. Sie müssen nicht alle auf die gleiche zugreifen, ein Flaschenhals wird vermieden. Dies könnt ihr auch während des aktiven Wawi-Betriebs ändern.

• Begrenzt den Arbeitsspeicher auf 80 Prozent des tatsächlich vorhandenen Arbeitsspeichers. So bleiben dem Betriebssystem genug Ressourcen, so dass hierdurch keine Performance-Einbußen entstehen. Laufen weitere Anwendungen auf dem Rechner, ist eine stärkere Einschränkung auf 60 bis 70 Prozent angebracht.
• Begrenzt die maximale Anzahl an parallel arbeitenden CPUs. Nutzt ihr mehr als 4, raten wir zu der Variante „Hälfte der Menge an CPUs -1“. Wer also 8 CPUs im Einsatz hat, sollte maximal 3 parallel nutzen. Für 4 und weniger CPUs ist der parallele Einsatz von 2 Kernen ideal. Keine Sorge, der Rest eurer Prozessoren bleibt derweil nicht untätig. Ihr legt mit dieser Definition lediglich die Menge der CPU-Kerne fest, die gleichzeitig an derselben Abfrage arbeiten. So bleibt euren Prozessoren genug Leistung, um neben großen Datenbankabfragen für mehr als einen Prozessor auch weiterhin andere Aufgaben und Abfragen mit der restlichen Kapazität zu bearbeiten.

Fazit

Habt ihr alle Einstellungen dementsprechend vorgenommen, sollte eure Datenbank bedeutend flüssiger mit jeglicher Art von Abfragen umgehen können. Um diesen Status auch längerfristig beizubehalten, geben wir euch in einem zukünftigen Blog-Beitrag nützliche Infos zur Wartung der Datenbank an die Hand.