Vorwort
Es war ein Dienstag.
Nicht dass der Wochentag eine Rolle gespielt hätte — aber es fühlt sich richtig an, dass es ein Dienstag war. Montage haben ihren eigenen dramatischen Charme, Freitage sind für Katastrophen zu offensichtlich. Ein Dienstag hingegen: unauffällig, bürokratisch, vollkommen unverdächtig. Genau der richtige Tag für einen SQL Server, der beschlossen hatte, das Projekt „reibungsloser Betrieb“ stillschweigend zu beenden.
Der Anruf kam um 11:23 Uhr.
„Der Server ist irgendwie langsam.“
Fünf Wörter. Fünf unscheinbare Wörter, die in der IT-Branche ungefähr denselben Stellenwert haben wie „es riecht irgendwie komisch“ in einer Chemiefabrik. Technisch korrekt. Vollkommen nichtssagend. Und der Beginn von etwas, das den Rest des Tages in Anspruch nehmen würde.
Ich fuhr hin.
Was ich vorfand, werde ich nicht vollständig beschreiben — teils aus Rücksicht auf die Betroffenen, teils weil es Konfigurationszustände gibt, die das menschliche Gehirn als Schutzmechanismus aktiv zu vergessen versucht. Ich kann nur so viel sagen: Priority Boost war aktiviert. Das ist eine Einstellung, die Microsoft seit SQL Server 2008 als „never use this“ dokumentiert hat — wobei „never“ hier offenbar als Empfehlung und nicht als Verbot verstanden wurde. Das Transaktionslog hatte seit achtzehn Monaten kein Backup gesehen und war in dieser Zeit auf eine Größe angewachsen, die ich hier nicht nenne, weil ich nicht will, dass jemand seinen Kaffee über die Tastatur spuckt.
Und max server memory war exakt auf den Wert des physisch vorhandenen RAMs gesetzt. Als großzügige Geste, vermute ich. SQL Server hat sie nicht als solche empfunden.
Der zuständige Administrator, ein freundlicher Mensch mit dem ratlosen Blick eines Mannes, der ahnt, dass gleich etwas Unangenehmes gesagt wird, erklärte mir, der Server laufe „eigentlich ganz gut, nur manchmal halt komisch“. In drei Jahrzehnten als Consultant habe ich gelernt, auf solche Aussagen professionell zu nicken. Das Nicken bedeutet: Ich höre dir zu. Es bedeutet nicht: Ich glaube dir.
Das war, wie gesagt, kein Einzelfall.
In drei Jahrzehnten habe ich mehr SQL Server analysiert als mir lieb ist — und ich sage das als jemand, dem SQL Server wirklich lieb ist, was meine Familie gelegentlich in Frage stellt. Ich habe Server gesehen, auf denen TempDB, Datendateien, Transaktionslog, Backups und das Betriebssystem auf einer einzigen Spindelfestplatte koexistierten — eine Art erzwungene WG-Situation, die für alle Beteiligten unglücklich endete, vor allem für die IO-Latenzen. Ich habe Transaktionslogs gesehen, die größer waren als die Datenbank selbst, was in etwa so viel Sinn ergibt wie ein Notizbuch das schwerer ist als das Geschriebene.
Ich habe eine gespeicherte Prozedur analysiert, die eine Scalar-Funktion 360.000 Mal pro Ausführung aufrief. Nicht aus Bosheit. Nicht aus Nachlässigkeit. Sondern weil niemand — wirklich niemand — dem Entwickler je erklärt hatte, was Scalar-Funktionen im Ausführungsplan anrichten. Er hatte sie gebaut, wie man einen Schweizer Taschenmesser baut: vielseitig, praktisch, und vollkommen ungeeignet für den vorliegenden Zweck.
Ich habe Indexfragmentierungen von 97% gesehen. 97. Prozent. Das ist keine Fragmentierung mehr, das ist künstlerische Freiheit.
Und ich habe — das ist vielleicht das Philosophischste an diesem Beruf — immer wieder festgestellt, dass all diese Systeme liefen. Nicht gut. Nicht schnell. Nicht ohne tägliche Gebete an die Verfügbarkeitsgötter. Aber sie liefen. SQL Server ist in dieser Hinsicht bewundernswert: Er gibt nicht auf. Er drosselt, er keucht, er wartet auf IO, der nie schneller wird — aber er läuft. Mit der stillen Würde eines Marathonläufers, der schon bei Kilometer drei gemerkt hat, dass er die falsche Strecke genommen hat, aber trotzdem weitermacht, weil Aufhören keine Option ist.
Jetzt fragst du dich vielleicht, warum ich das alles aufschreibe.
Die ehrliche Antwort: Weil es mich seit drei Jahrzehnten beschäftigt. Nicht die Fehler — Fehler passieren, das ist menschlich, und wer noch nie aus Versehen Priority Boost aktiviert hat, werfe den ersten Stein. Was mich beschäftigt, ist die Erkenntnis, dass die meisten dieser Probleme lösbar gewesen wären. Nicht mit einem Enterprise-Budget. Nicht mit einem Beraterstab. Sondern mit dem Wissen, das in diesem Buch steht.
SQL Server ist kein Gegner. Er ist kein launisches System, das willkürlich Probleme erfindet, um uns zu ärgern. Er tut exakt das, was man ihm sagt — und das ist manchmal das eigentliche Problem. Er aktiviert Priority Boost, weil man es ihm gesagt hat. Er wächst das Transaktionslog auf astronomische Ausmaße, weil niemand ihm gesagt hat, dass er nicht soll. Er ruft die Scalar-Funktion 360.000 Mal auf, weil die Abfrage es so verlangt.
Er macht seinen Job. Mit bemerkenswerter Treue. Mit erschreckender Konsequenz.
Dieses Buch ist die Einladung, ihm dabei zuzuhören. Nicht mit Panik, nicht mit Selbstkritik — sondern mit offenem Blick und dem gesunden Misstrauen gegenüber allem, das „schon immer so war“.
Drei fiktive Unternehmen begleiten dich durch alle Kapitel. Musterwerk GmbH — der solide Durchschnittsfall mit alltäglichen Problemen und lösbaren Aufgaben. Sparfuchs & Partner — bei dem ich betonen möchte, dass er fiktiv ist, obwohl mir beim Schreiben mehrfach unwohl wurde und ich kurz erwogen habe, eine Kerze anzuzünden. Und Trendforge Digital — der Beweis, dass exzellente Hardware und katastrophaler Applikationscode sich nicht gegenseitig aufheben, sondern auf eine Art zusammenwirken, die man in der Physik als „destruktive Interferenz“ und in der Praxis als „aber warum ist das denn so langsam, wir haben doch tolle Server“ bezeichnet.
Noch ein Wort zur Form dieses Buchs.
Ich habe versucht, es so zu schreiben, wie ich es meinen Kunden erkläre: direkt, konkret, ohne akademisches Drumherum. Fachbücher müssen keine Schlaftabletten sein. SQL Server ist ein faszinierendes System — komplex, durchdacht, voller eleganter Mechanismen, die man nur verstehen muss, um sie zu schätzen. Ich hoffe, dass dieses Buch einen Teil dieser Faszination transportiert.
Und wenn nicht — wenn du es hauptsächlich aufschlägst, weil nachts der Pager geht und der Server wieder „irgendwie komisch“ ist — dann ist es dafür auch gut.
Pass auf deine Transaktionslogs auf. Wirklich.
Ulrich B. Boddenberg
Dortmund, 2026
Kapitel 1