Cumulative Updates und Service Packs einspielen

Patchen ist Pflicht — aber mit Bedacht. Der Pre-Patch-Post-Workflow, die Always-On-Rolling-Strategie und die eine Regel: nie am Freitag.

Patchen ist wie der Zahnarztbesuch der Datenbankwelt: Jeder weiß, dass er wichtig ist, viele schieben ihn trotzdem ewig auf, und wer ihn zu lange ignoriert, zahlt am Ende drauf. Beim SQL Server gibt es dabei zwei entgegengesetzte Sünden. Die einen patchen nie — sie lassen jahrelang bekannte Sicherheitslücken und längst behobene Bugs offen, weil „läuft doch“ und „never touch a running system“. Die anderen patchen kopflos — sie spielen den brandneuen Cumulative Update am Erscheinungstag blind auf die Produktion, am Freitagnachmittag, ohne Backup, und wundern sich übers Wochenende. Beide Extreme sind falsch. Der richtige Weg liegt dazwischen: regelmäßig, aber mit Bedacht.

Dieser Beitrag aus dem SQL-Server-Notarztwagen (die Triage-Übersicht liegt unter /sql-server-notarztwagen/) zeigt dir, wie du SQL Server sauber auf Stand hältst: was Cumulative Updates und Service Packs überhaupt sind, der Pre-Patch-Post-Workflow, der aus dem Einspielen einen kontrollierten Vorgang macht, die Rolling-Update-Strategie für Always-On-Cluster — und die eine eherne Regel, die jeder erfahrene DBA verinnerlicht hat: niemals am Freitag. Als Beitrag der GRÜN-Stufe geht es um die ruhige, geplante Pflege, die Notfälle verhindert, statt sie auszulösen.

CU, Service Pack, Build-Nummer — die Begriffe

Microsoft verteilt Korrekturen für SQL Server in Sammelpaketen. Historisch gab es zwei Sorten: Service Packs waren die großen, gründlich getesteten Bündel, die in größeren Abständen erschienen und oft auch neue Funktionen brachten. Cumulative Updates (CUs) waren die kleineren, häufigeren Pakete dazwischen, gefüllt mit Bugfixes und Sicherheitskorrekturen. Die wichtigste Neuigkeit für die Praxis: Seit SQL Server 2017 gibt es keine Service Packs mehr — Microsoft liefert nur noch Cumulative Updates, typischerweise etwa alle zwei Monate. Wer ein modernes SQL Server betreut, hat es also praktisch ausschließlich mit CUs zu tun; der Begriff Service Pack begegnet einem nur noch auf älteren Versionen.

Das entscheidende Merkmal beider ist, dass sie kumulativ sind: Jeder CU enthält alle Korrekturen seiner Vorgänger. CU 15 schließt also auch alles ein, was CU 1 bis CU 14 behoben haben. Daraus folgt eine praktische Regel — beim Patchen geht man gleich auf den neuesten Stand, statt mehrere ältere CUs nacheinander einzuspielen, weil der neueste ohnehin alles enthält. Die Versionierung selbst läuft über die Build-Nummer, eine Kennung wie 16.0.4115.5, die genau verrät, welche Version und welcher Patch-Stand installiert ist. Diese Nummer gegen die offiziellen Build-Listen abzugleichen, ist der Weg, den eigenen Stand einzuordnen. Die Nummer selbst hat eine Logik: Die erste Stelle (etwa 16) steht für die Hauptversion — 16 ist SQL Server 2022, 15 ist 2019, 14 ist 2017 —, die zweite (0) ist ein historischer Platzhalter, und die dritte und vierte Stelle kodieren den genauen Patch-Stand. Steigt die dritte Stelle, wurde ein CU eingespielt; an ihr erkennt der geübte Blick auf einen Schlag, ob ein Server frisch oder hoffnungslos veraltet ist. Wer die Systematik einmal verinnerlicht hat, liest aus einer Build-Nummer das halbe Patch-Schicksal eines Servers ab.

Warum das alles überhaupt wichtig ist, lässt sich in einem Satz sagen: CUs schließen Sicherheitslücken und beheben Bugs. Eine ungepatchte Datenbank trägt bekannte, dokumentierte Schwachstellen mit sich herum, die Angreifer kennen und für die Microsoft längst eine Korrektur bereitgestellt hat — sie wurde nur nie eingespielt. Genauso laufen ungepatchte Server in längst behobene Fehler, von Abstürzen bis zu falschen Ergebnissen. Patchen ist deshalb keine Kür, sondern Teil der Sorgfaltspflicht. Die eigentliche Kunst liegt nicht in der Frage ob, sondern in der Frage wie — und genau dafür gibt es den Workflow.

Der Patching-Workflow

Das Einspielen eines CU dauert meist nur Minuten — die Sorgfalt davor und danach macht den Unterschied zwischen Routine und Albtraum. Die folgende Skizze zeigt den Drei-Phasen-Workflow, die Rolling-Strategie für Always-On und die wichtigsten Regeln:

Die Skripte: prüfen, dokumentieren, verifizieren

Schritt 1 — Vor dem Patch: Version notieren

Bevor du irgendetwas einspielst, halte die Ausgangsversion fest — sie ist die Grundlage für Dokumentation und einen eventuellen Rollback:

Die BuildNummer (etwa 16.0.4115.5) ist der Schlüssel: Sie gegen die offiziellen Build-Listen abzugleichen verrät, welcher CU installiert ist und welcher der neueste verfügbare wäre. ProductUpdateLevel zeigt den CU-Stand direkt an. Diese Werte gehören dokumentiert, bevor das Setup startet.

Schritt 2 — Nach dem Patch: Version verifizieren und ERRORLOG prüfen

Der Blick ins ERRORLOG ist nicht optional: Beim ersten Start nach einem Patch führt der SQL Server Upgrade-Schritte für die Systemdatenbanken aus, und falls dabei etwas schiefgeht, steht es hier — nicht in der Setup-Ausgabe. Ein Patch gilt erst als erfolgreich, wenn das ERRORLOG sauber ist, nicht schon, wenn das Setup-Fenster „Erfolgreich“ meldet.

Schritt 3 — Dienste und Jobs kontrollieren

Patchen mit Bedacht — die Strategie

Das richtige Timing — nicht der Erste, nicht der Letzte

Die Kunst des Patchens liegt im Timing. Das eine Extrem ist der ewige Aufschieber, der jahrelang nicht patcht und bekannte Sicherheitslücken offen lässt — ein vermeidbares Risiko, das mit jedem Monat wächst. Das andere Extrem ist der Tag-Eins-Aufspieler, der jeden brandneuen CU sofort blind auf die Produktion fährt und damit zum Versuchskaninchen für etwaige neue Probleme wird. Der richtige Weg liegt dazwischen: einen neuen CU erst eine kurze Bewährungszeit auf Test- und Vorabsystemen laufen lassen, dort Funktion und Performance prüfen, und ihn dann auf die Produktion bringen. So profitierst du von den Korrekturen, ohne der Erste zu sein, bei dem ein seltener neuer Fehler auffällt. Sicherheitskritische Updates können dieses Vorgehen überstimmen, wenn die Lücke gravierend genug ist.

Always-On Rolling Update — online bleiben beim Patchen

Wer Verfügbarkeitsgruppen betreibt, kann patchen, ohne die Anwendung nennenswert offline zu nehmen — per Rolling Update. Die Reihenfolge ist entscheidend: Zuerst werden die Secondary-Replicas gepatcht, eines nach dem anderen, während der Primary den Betrieb aufrechterhält. Dann ein geplanter, manueller Failover auf einen bereits gepatchten Secondary, der damit zum neuen Primary wird. Zuletzt wird der alte Primary — jetzt ein Secondary — gepatcht. Die einzige Ausfallzeit ist der kurze, kontrollierte Failover-Moment von wenigen Sekunden. Wichtig ist, den Synchronisierungszustand während des Vorgangs im Auge zu behalten, damit der Failover auf einen wirklich synchronen Replica erfolgt; die Mechanik dahinter steht im Always-On-Beitrag. Nie alle Knoten gleichzeitig patchen — das wäre der Verlust der ganzen Hochverfügbarkeit auf einen Schlag. Ein praktischer Zusatzpunkt: Behalte während des Rolling Updates auch das Cluster-Quorum im Blick. Wenn ein Knoten zum Patchen offline geht, sinkt die Zahl der stimmberechtigten Knoten — und bei einem kleinen Cluster kann ein zusätzlicher, ungeplanter Ausfall eines weiteren Knotens in diesem Moment das Quorum kippen und die ganze Gruppe offline nehmen. Deshalb patcht man Knoten einzeln und wartet, bis jeder wieder vollständig synchron und im Cluster aktiv ist, bevor der nächste an die Reihe kommt. Geduld ist hier kein Luxus, sondern Teil der Sicherheit.

Die Freitag-Regel — und warum sie heilig ist

Es gibt eine Regel, die jeder erfahrene Administrator verinnerlicht hat: Kein Patch am Freitag. Niemals. Der Grund ist nüchterne Risikorechnung. Ein Patch kann unerwartete Folgen haben, die sich erst Stunden später unter realer Last zeigen — ein Job, der nachts nicht durchläuft, eine Abfrage, die plötzlich langsam ist, ein subtiles Verhaltensproblem. Spielst du am Dienstag ein, hast du die ganze Woche Zeit, solche Spätfolgen in Ruhe zu beheben, mit ausgeruhtem Team und im Tagdienst. Spielst du am Freitag ein, lauern die Spätfolgen übers Wochenende — und du verbringst es entweder am Telefon im Notdienst oder lebst mit dem Risiko, dass montags die Hütte brennt. Dasselbe gilt sinngemäß für den letzten Arbeitstag vor jedem längeren Feiertag. Patch früh in der Woche, nie zum Wochenende hin.

Was du auf keinen Fall tun solltest

Patch-Management als Routine

Patchen wird vom Stressfaktor zur Routine, wenn es einen festen Rahmen hat. Drei Punkte schaffen ihn: Erstens, einen Patch-Rhythmus festlegen — etwa quartalsweise prüfen, welcher CU-Stand verfügbar ist, und nach kurzer Bewährungszeit einspielen, mit Vorrang für Sicherheitsupdates. Zweitens, den Patch-Stand in den Health Check aufnehmen, damit nie unbemerkt ein Server jahrelang ungepatcht bleibt — die Build-Nummer gegen den aktuellen Stand zu prüfen gehört zum Konfigurations-Bereich des Selbsttests. Drittens, eine Patch-Dokumentation führen: welcher Server wann auf welchen Stand kam, mit Vorher-/Nachher-Build-Nummer — das macht Rollback-Entscheidungen und Fehlersuche im Ernstfall leichter. Wie der Patch-Stand in das große Bild der proaktiven Wartung passt, zeigt der Health-Check-Beitrag der GRÜN-Stufe.

Vertiefung in der Buchreihe

Patch-Management, Versions-Pflege und die Sicherheitsseite des Patchens füllen in der Buchreihe „SQL Server in der Praxis“ eigene Kapitel — alle Bände in der Übersicht auf der SQL-Pillar-Seite unter /sql-server/.

Verwandte Beiträge im Notarztwagen

Das Patchen berührt mehrere Themen — diese Beiträge aus dem Cluster lohnen den Blick:

Drei Wege zum sicheren Patch-Management

Selbst-Diagnose-Kit

Patchen selbst zur Routine zu machen ist gut investierte Zeit — und genau dafür gibt es das Diagnose-Kit. Es bündelt die Skripte aus diesem Beitrag — Versions- und Build-Abfrage, ERRORLOG-Prüfung, Dienste- und Job-Kontrolle — plus die Pre-Patch-Post-Checkliste zum Ausdrucken, einen Rolling-Update-Ablaufplan für Always-On und eine Patch-Dokumentations-Vorlage. Damit verwandelst du das Patchen von einer nervösen Ausnahmeaktion in einen abgehakten, wiederholbaren Prozess.

Festpreis-Analyse

Du willst wissen, ob deine Server auf einem sicheren Patch-Stand sind und wie ein verlässlicher Patch-Prozess für deine Umgebung aussieht — gerade bei Always-On oder mehreren Instanzen? Die Festpreis-Analyse liefert das: Ich erfasse die Build-Stände aller Instanzen, gleiche sie gegen den aktuellen Stand und bekannte Sicherheitsupdates ab, entwerfe einen Patch-Fahrplan inklusive Rolling-Update-Strategie und liefere einen Bericht mit priorisierten Maßnahmen. Zum vereinbarten Festpreis, ohne Stundenzähler.

Akut-Hotline

Wenn ein Patch gerade jetzt schiefgegangen ist — der Server startet nicht sauber, ein Dienst klemmt, das ERRORLOG zeigt Upgrade-Fehler: anrufen. Halte die Vorher- und Nachher-Build-Nummer bereit und die Information, ob ein frisches Backup existiert. In diesem Moment zählt die richtige Reihenfolge, und der erste Blick gilt fast immer dem ERRORLOG, bevor irgendjemand voreilig zurückrollt.

Häufige Fragen (FAQ)

Diese Sektion ist auf häufige Suchanfragen abgestimmt. Sie hilft dir, schnell den Punkt zu finden, der dir gerade akut weiterhilft — und sie ist gleichzeitig die Eingabe für das FAQPage-Schema auf der Seite.

Was ist der Unterschied zwischen CU und Service Pack?

Beides sind Sammel-Updates, aber aus verschiedenen Epochen. Service Packs waren früher die großen, gründlich getesteten Update-Bündel, die in größeren Abständen erschienen; Cumulative Updates (CUs) sind die kleineren, häufigeren Sammelpakete mit Bugfixes und Sicherheitskorrekturen, die zwischen den Service Packs kamen. Entscheidend für heute: Seit SQL Server 2017 gibt es keine Service Packs mehr — Microsoft liefert ausschließlich Cumulative Updates, in der Regel etwa alle zwei Monate. Beide sind kumulativ aufgebaut, das heißt der neueste enthält immer alle vorherigen. Wer ein aktuelles SQL Server patcht, hat es also praktisch nur noch mit CUs zu tun.

Wie oft sollte ich SQL Server patchen?

Regelmäßig, aber nicht hektisch. Ein vernünftiger Rhythmus ist, den jeweils aktuellen Patch-Stand nicht zu weit hinterherhinken zu lassen — etwa indem man Updates nach einer kurzen Bewährungszeit einspielt, statt jeden CU am Erscheinungstag blind aufzuspielen oder umgekehrt jahrelang gar nicht zu patchen. Sicherheitsrelevante Updates haben dabei Vorrang und gehören zeitnah eingespielt. Der goldene Mittelweg lautet: nicht der Erste sein, der einen brandneuen CU auf Produktion fährt (lieber erst auf Test-/Vorabsystemen prüfen), aber auch nicht der Letzte, der monatelang bekannte Lücken offen lässt. Patchen ist Pflicht — die Frage ist nur das Wie und Wann, nicht das Ob.

Muss ich vor einem Update ein Backup machen?

Unbedingt, und zwar ein frisches, getestetes Voll-Backup unmittelbar vor dem Patch. Das ist die wichtigste einzelne Vorbereitung überhaupt, denn das Backup ist dein Rückweg, falls das Update Probleme macht. Wichtig: Es genügt nicht, dass irgendein Backup existiert — es muss aktuell sein und idealerweise vorher mit einem Restore-Test als wiederherstellbar bewiesen worden sein. Ein Patch, der ohne verlässliches Backup gefahren wird, ist ein Sprung ohne Netz: Wenn etwas Unerwartetes passiert, fehlt der Weg zurück. Zur Backup-Seite gibt es einen eigenen Beitrag über die Backup-Strategie, der erklärt, was ein verlässliches Backup ausmacht.

Wie prüfe ich die SQL-Server-Buildnummer?

Über SELECT SERVERPROPERTY('ProductVersion') oder die Abfrage SELECT @@VERSION. Die ProductVersion liefert die genaue Build-Nummer (etwa 16.0.4115.5), die du gegen die offiziellen Build-Listen abgleichen kannst, um zu sehen, welcher CU installiert ist und welcher der neueste verfügbare wäre. Diese Prüfung gehört an zwei Stellen des Patch-Vorgangs: vorher, um die Ausgangsversion zu notieren (wichtig für einen eventuellen Rollback und die Dokumentation), und nachher, um zu verifizieren, dass das Update tatsächlich erfolgreich durchgelaufen ist und die erwartete neue Build-Nummer anliegt. Die genauen Abfragen stehen im Skript-Abschnitt dieses Beitrags.

Wie patche ich einen Always-On-Verfügbarkeitsgruppen-Cluster?

Mit einem Rolling Update, bei dem nie alle Knoten gleichzeitig offline sind. Der Ablauf: Zuerst patcht du die Secondary-Replicas, eines nach dem anderen, während der Primary den Betrieb aufrechterhält. Dann machst du einen geplanten manuellen Failover auf einen bereits gepatchten Secondary — der wird damit zum neuen Primary. Zuletzt patchst du den alten Primary, der jetzt ein Secondary ist. So bleibt die Verfügbarkeitsgruppe durchgehend online, und die einzige Ausfallzeit ist der kurze, kontrollierte Failover-Moment. Wichtig ist, die Replicas auf denselben Patch-Stand zu bringen und während des Vorgangs den Synchronisierungszustand im Auge zu behalten — Details dazu im Always-On-Beitrag.

Was prüfe ich nach einem SQL-Server-Update?

Fünf Dinge in fester Reihenfolge: Erstens die Version verifizieren (ist die erwartete neue Build-Nummer da?). Zweitens das SQL Server ERRORLOG durchsehen — beim ersten Start nach dem Patch laufen Upgrade-Schritte für die Systemdatenbanken, und Fehler dabei stehen hier. Drittens prüfen, ob alle Dienste und SQL-Agent-Jobs wieder laufen. Viertens ein Smoke-Test: Verbindet sich die Anwendung, laufen die wichtigsten Funktionen? Fünftens die Performance beobachten — ein CU kann in seltenen Fällen das Verhalten ändern, hier hilft der Query Store als Vergleichsbasis. Erst wenn diese fünf Punkte sauber sind, gilt der Patch als erfolgreich abgeschlossen, nicht schon, wenn das Setup ohne Fehler endete.

Soll ich immer den neuesten CU installieren?

Den neuesten, aber nicht den allerneuesten am Erscheinungstag. Weil CUs kumulativ sind, ist es sinnvoll, beim Patchen gleich auf den aktuellsten Stand zu gehen statt mehrere ältere CUs nacheinander einzuspielen — der neueste enthält ohnehin alle Vorgänger. Die Einschränkung betrifft das Timing: Ein brandneuer CU sollte nicht am ersten Tag blind auf die Produktion, sondern erst eine kurze Bewährungszeit auf Test- und Vorabsystemen durchlaufen, damit etwaige neue Probleme nicht zuerst im Produktivbetrieb auffallen. Sicherheitskritische Updates können diese Regel überstimmen, wenn die Lücke gravierend ist. Die Faustregel bleibt: aktuell sein, aber nicht der Versuchskaninchen-Erste.