Was einen SQL Server im Mittelstand stabil hält

In den meisten mittelständischen Umgebungen arbeitet ein Microsoft SQL Server, ohne dass jemand ihn als eigenes System betrachtet. Er wurde bei der Einführung der Warenwirtschaft mitinstalliert, läuft seither unauffällig und gehört gefühlt dem Softwarehersteller. Das geht jahrelang gut und endet an einem von zwei Punkten: Die Datenbank wird langsam, oder sie lässt sich nach einem Zwischenfall nicht auf den Stand von zehn Minuten vor dem Ausfall zurückholen. Beide Fälle sind Folgen von Entscheidungen, die niemand getroffen hat.

Die Edition setzt harte Grenzen

Die Editionen unterscheiden sich nicht nur im Preis, sondern in Obergrenzen, die im Betrieb unmittelbar wirken. Microsoft begrenzt die Standard-Edition auf die jeweils kleinere Größe von 4 Sockeln oder 24 Kernen und den Pufferspeicher auf 128 GB je Instanz; die Enterprise-Edition nutzt jeweils das Maximum des Betriebssystems. Die kostenfreie Express-Edition ist auf 1 Sockel oder 4 Kerne, 1.410 MB Pufferspeicher und 10 GB je Datenbank beschränkt.

Die Grenze von 10 GB ist der häufigste stille Ausfallgrund im Mittelstand. Eine Fachanwendung, die vor Jahren mit der Express-Edition ausgeliefert wurde, arbeitet bis kurz unter dieser Marke einwandfrei und verweigert dann Schreibvorgänge. Ebenso folgenreich: Der Auftragsdienst SQL Server Agent, über den Sicherungen und Wartungsaufgaben zeitgesteuert laufen, ist in der Express-Edition nicht enthalten. Wer dort automatisch sichern will, braucht einen Umweg über Skripte und die Aufgabenplanung des Betriebssystems.

Bei der Hochverfügbarkeit verläuft die Grenze ebenfalls zwischen den Editionen. Always-On-Verfügbarkeitsgruppen führt Microsoft ausschließlich für Enterprise; die Standard-Edition bietet Basis-Verfügbarkeitsgruppen mit zwei Replikaten und einer Datenbank sowie Failover-Clusterinstanzen mit zwei Knoten. Für ein Haus mit einer Warenwirtschaftsdatenbank genügt das oft. Wichtig ist, es vor der Beschaffung zu wissen, denn ein Editionswechsel im laufenden Betrieb ist kein Nachmittagsprojekt.

Ausgaben und Lizenzierung

Lizenziert wird ein SQL Server entweder nach Prozessorkernen oder – bei der Standard-Edition – über eine Serverlizenz mit Zugriffslizenzen für Personen oder Geräte. Welches Modell günstiger ist, hängt an einer einfachen Gegenüberstellung: Zahl der Kerne, die die Datenbank nutzen darf, gegen Zahl der Menschen und Geräte, die sie tatsächlich ansprechen. Für ein Haus mit 40 Arbeitsplätzen und einem kleinen Datenbankserver fällt die Rechnung häufig anders aus als für ein Haus mit 250 Arbeitsplätzen auf derselben Hardware.

Zwei Randbedingungen gehören in dieselbe Betrachtung. Erstens weist Microsoft darauf hin, dass die Enterprise-Edition im Modell mit Serverlizenz und Zugriffslizenzen für neue Vereinbarungen nicht mehr verfügbar und auf höchstens 20 Kerne je Instanz begrenzt ist; im kernbasierten Modell gilt diese Grenze nicht. Zweitens folgt die Lizenzierung der Hardware: Zieht die Datenbank auf einen Wirt mit mehr Kernen um, ändert sich die Zahl der nötigen Lizenzen, ohne dass sich in der Anwendung etwas verändert. Wer aufrüstet, sollte diesen Posten vorher prüfen, nicht nachträglich.

Die Speicherobergrenze gehört gesetzt

Ein SQL Server belegt standardmäßig so viel Arbeitsspeicher, wie er bekommen kann: Der Vorgabewert für die Obergrenze liegt bei 2.147.483.647 MB, was praktisch unbegrenzt bedeutet. Microsoft empfiehlt ausdrücklich, in allen Versionen eine Obergrenze zu setzen, und nennt als Richtwert 75 Prozent des verfügbaren Systemspeichers, der nicht von anderen Prozessen belegt ist. Bleibt dieser Wert unverändert, konkurriert die Datenbank mit dem Betriebssystem – und wer schon einmal einen Server erlebt hat, der beim Anmelden minutenlang nicht reagiert, kennt das Ergebnis.

Für die Berechnung nennt Microsoft ein nachvollziehbares Vorgehen: Vom gesamten Speicher des Betriebssystems werden die Anteile abgezogen, die außerhalb dieser Obergrenze liegen, sowie ein Aufschlag von rund 25 Prozent für weitere Zuteilungen wie Sicherungspuffer und Erweiterungen. Was bleibt, ist die Obergrenze für eine einzelne Instanz. Läuft der Server virtuell, sollte zusätzlich eine Untergrenze gesetzt werden, damit der Wirt der Datenbank nicht unter Druck Speicher entzieht.

Das Wiederherstellungsmodell entscheidet über den möglichen Datenverlust

Jede Datenbank hat eine Eigenschaft, die festlegt, wie Änderungen protokolliert werden und welche Wiederherstellungen möglich sind. Drei Modelle stehen zur Wahl, und die Wahl entscheidet, wie viel Arbeit ein Zwischenfall vernichtet.

Aus dieser Aufstellung ergibt sich der Klassiker unter den Betriebsfehlern: Eine Datenbank steht im vollständigen Modell – bei Standard- und Enterprise-Edition ist es die Voreinstellung –, aber es werden nur Vollsicherungen gefahren. Das Protokoll wächst dann unbegrenzt weiter, bis das Laufwerk voll ist und die Anwendung stehen bleibt. Die Lösung ist nicht, das Protokoll gelegentlich zu verkleinern, sondern entweder regelmäßig zu sichern oder das Modell bewusst auf „einfach“ zu setzen und den möglichen Verlust zu akzeptieren.

Sicherung: drei Bausteine und eine Probe

Eine tragfähige Datenbanksicherung besteht aus einer nächtlichen Vollsicherung, optional einer Differenzsicherung am Mittag und – im vollständigen Modell – Protokollsicherungen in kurzen Abständen. Der Abstand der Protokollsicherungen ist die Zahl, die den maximalen Datenverlust bestimmt: Wird alle 15 Minuten gesichert, sind im schlechtesten Fall 15 Minuten Arbeit betroffen. Diese Zahl gehört nicht in die IT-Abteilung, sondern auf den Tisch der Geschäftsführung, weil sie eine betriebswirtschaftliche Festlegung ist.

Zwei Punkte werden regelmäßig übersehen. Erstens ist das Kopieren der Datenbankdateien im laufenden Betrieb keine Sicherung; benötigt wird eine Sicherung durch das Datenbanksystem selbst oder eine anwendungsbewusste Sicherung der virtuellen Maschine. Zweitens ist eine Sicherung erst dann eine Sicherung, wenn sie einmal zurückgespielt wurde. Ein Rechenbeispiel mit angenommenen Werten zeigt, warum das Üben lohnt: Bei einer 80 GB großen Datenbank, nächtlicher Vollsicherung um 22 Uhr und Protokollsicherung im Viertelstundentakt besteht eine Wiederherstellung am Nachmittag aus der Vollsicherung, gegebenenfalls einer Differenzsicherung und mehreren Dutzend Protokollsicherungen, die in der richtigen Reihenfolge eingespielt werden müssen. Wer diesen Ablauf zum ersten Mal im Ernstfall durchführt, verliert Stunden an Suchen und Nachdenken.

Der Wartungsplan: vier Aufgaben, nicht mehr

Diese vier Aufgaben sind der gesamte Grundbetrieb. Sie lassen sich als Wartungsplan im Datenbanksystem einrichten, sofern der Auftragsdienst zur Verfügung steht, und brauchen danach im Monat wenige Minuten Aufmerksamkeit. Aufwendig wird es nur, wenn sie fehlen – dann wird aus Pflege Ursachenforschung.

Zuständigkeit klären, bevor es klemmt

Die unangenehmste Frage kommt am Ende und lautet: Wer ist eigentlich zuständig? Der Softwarehersteller pflegt in der Regel seine Anwendung und deren Datenbankschema, nicht den Betrieb des Datenbanksystems. Wer Sicherung, Arbeitsspeicher, Wiederherstellungsmodell und Wartungsplan verantwortet, sollte deshalb namentlich benannt und im Wartungsvertrag abgegrenzt sein – zusammen mit der Angabe, welche Wiederherstellungszeit und welcher zulässige Datenverlust vereinbart sind. Ohne diese Abgrenzung stellt sich die Zuständigkeitsfrage erst in dem Moment, in dem niemand Zeit für sie hat.

Verwandte Themen: Wer hier weiterdenkt, liest bei Windows Server, Exchange und Server mieten weiter.