Die SQL-Server-Updates vom April 2026 zeigen gut, warum Datenbank-Patching nicht als passive Wartungsroutine behandelt werden kann. Am 14. April veröffentlichte Microsoft das GDR-Sicherheitsupdate KB5084814 für SQL Server 2025 gegen Schwachstellen zur Rechteausweitung. Zwei Tage später erschien SQL Server 2025 CU4 mit elf Korrekturen, darunter Verbesserungen für Hochverfügbarkeit und Verwaltungsdienste. Diese Abfolge ist bei Unternehmenssoftware normal, aber genau deshalb benötigen produktive SQL-Bestände ein Betriebsmodell statt einer einfachen Anweisung, den neuesten Build zu installieren.
Bedeutung für den Betrieb
Das betriebliche Problem ist nicht, ob Teams patchen sollten. Das sollten sie. Das Problem besteht darin, dass SQL-Server-Patches häufig verschiedene Risikoarten in einer Entscheidung vereinen: Sicherheitsrisiko, Engine-Verhalten, HA-Topologie, Kompatibilität der Arbeitslast und Unterstützbarkeit. CU4 wird inzwischen als neuestes kumulatives Update für SQL Server 2025 geführt, während der GDR-Pfad vom April für Bestände existiert, die die Sicherheitskorrektur benötigen, ohne auf den CU-Zweig zu wechseln. Dieser Unterschied ist wichtig, weil ein gemischter Bestand eigenständige Instanzen, Verfügbarkeitsgruppen, Linux-Bereitstellungen, Reporting-Arbeitslasten und ältere Wartungsgrundlagen enthalten kann, die nicht alle mit demselben einzeiligen Ablaufplan behandelt werden sollten.
CU4 enthält außerdem ein bekanntes Problem, bei dem Teams an der richtigen Stelle langsamer werden sollten. Microsoft dokumentiert fehlerhaftes Verhalten bei Abfragen, die SESSION_CONTEXT in parallelen Ausführungsplänen verwenden. Dazu zählen mögliche falsche Ergebnisse oder Speicherauszüge durch Zugriffsverletzungen, wenn Sitzungen zur Wiederverwendung zurückgesetzt werden. Das macht das Update nicht unbrauchbar. Es stellt spezifischere Anforderungen an die Testabdeckung. Nutzt eine Anwendung den Sitzungskontext für Mandanten-, Sicherheits-, Audit- oder Anwendungszustände, sollte die Vorproduktionsprüfung repräsentative parallele Arbeitslasten einschließen und sich nicht auf einen Smoke-Test beschränken, der nur den Start des Dienstes belegt.
Dieselben Releaseinformationen zeigen, warum Patchen auch dann erforderlich bleibt, wenn Tests Aufwand verursachen. CU4 enthält Korrekturen für eigenständige Verfügbarkeitsgruppen, msdb-Berechtigungen während des Upgrades, SQLPAL-Verhalten unter Linux, Fehler der Volltextsuche und nicht reagierende Scheduler bei starker E/A des Lazy Writers. Das sind keine kosmetischen Änderungen. Sie betreffen genau die Systeme, die bereits sorgfältige Wartungsfenster benötigen: HA-Plattformen, replizierte Umgebungen, Linux-basierte Instanzen und Bestände, in denen Leistungsstörungen im Nachhinein teuer zu diagnostizieren sind.
Hier wird Patch-Governance zur Produktionsdisziplin. Ein belastbarer SQL-Patchprozess sollte wissen, welchem Zweig jede Instanz folgt, welche Arbeitslasten empfindliche Engine-Funktionen verwenden, welche Replikate zuerst aktualisiert werden können, wie der Failover- und Rollbackpfad aussieht und welche Überwachungssignale anschließend einen gesunden Bestand belegen. Die besten Teams verwechseln Geschwindigkeit nicht mit Nachlässigkeit. Sie handeln schnell, weil Inventar, Testdaten, HA-Reihenfolge, Backup-Stand und Geschäftskommunikation bereits vorbereitet sind.
Praktische Konsequenz
Die praktische Schlussfolgerung aus dem April 2026 ist einfach: SQL-Server-Patching gehört in dieselbe betriebliche Kategorie wie Identitäts-Patching, Backup-Validierung und Lebenszyklusarbeit am Hypervisor. Es schützt das Geschäft nur, wenn es bewusst genug erfolgt, um reale Arbeitslasten zu überstehen. Einen Build zu installieren ist der einfache Teil. Zu wissen, wohin er gehört, wie er sich verhält und wie die Wiederherstellung bei einem Fehlverhalten gelingt, ist die Arbeit, die routinemäßige Wartung von Production Engineering unterscheidet.
