Kompatibilitätslevel erhöhen: Mit Messwerten sicher umstellen

Eine neuere SQL Server Engine zu installieren und den Kompatibilitätslevel einer Datenbank zu erhöhen sind zusammenhängende, aber unterschiedliche Änderungen. Werden gleichzeitig Schema, Indizes und Anwendung geändert, lässt sich eine Regression unnötig schwer erklären. Eine kontrollierte Umstellung schafft Vergleichspunkte, anhand derer das Team verändertes Abfrageverhalten einer konkreten Ursache zuordnen kann.

Zwei getrennte Ausgangszustände erfassen

Dokumentieren Sie zunächst Engine-Build, Kompatibilitätslevel, datenbankbezogene Konfiguration und wichtige Anwendungseinstellungen. Stellen Sie eine repräsentative Kopie auf der Zielengine mit einem dort unterstützten bisherigen Level wieder her. Bewerten Sie diesen Zustand vor der nächsten Änderung. Der beibehaltene Level emuliert nicht die gesamte alte Engine; Infrastruktur, Wartungskorrekturen und anderes Verhalten können abweichen.

Die folgende lesende Bestandsaufnahme läuft in der untersuchten Datenbank. Die Query-Store-Sicht benötigt die zur installierten Version passenden Einsichtsrechte. Speichern Sie das Ergebnis mit Testdatum und Kennung der Arbeitslast.

SELECT SERVERPROPERTY('ProductVersion') AS EngineVersion;
SELECT name, compatibility_level
FROM sys.databases WHERE database_id=DB_ID();
SELECT actual_state_desc, desired_state_desc, readonly_reason,
       current_storage_size_mb, max_storage_size_mb
FROM sys.database_query_store_options;

Ein gewünschter Zustand READ_WRITE beweist keine aktive Aufzeichnung. Prüfen Sie tatsächlichen Zustand, Speichernutzung und bei Schreibschutz dessen Ursache. Erfassung und Aufbewahrung müssen den Ausgangszustand bis zum Vergleich erhalten. Ein volles Repository ohne neue Daten kann ausgerechnet während einer kritischen Umstellung scheinbare Ruhe vortäuschen.

Wählen Sie eine Arbeitslast mit wichtigen Parameterverteilungen und einem vollständigen Geschäftszyklus. Berücksichtigen Sie den größten Mandanten, leere Ergebnisse, Monatsabschluss und Parallelität. Tagesabfragen auf einzelne Schlüssel qualifizieren keinen nächtlichen Berichtslauf. Halten Sie Verteilung, Statistiken, Hardwarezuteilung und gleichzeitige Last vergleichbar oder dokumentieren Sie Unterschiede ausdrücklich.

Den Level separat ändern

Auf einer SQL Server 2022 Testinstanz lässt sich eine Datenbank mit Level 150 anschließend separat unter 160 bewerten. Die auskommentierte Vorlage benennt absichtlich eine Übungsdatenbank. Prüfen Sie zuerst die Unterstützung auf der wirklichen Zielengine. Eine Kompatibilitätszahl installiert keine fehlende Engine-Version.

-- Example only: SQL Server 2022, isolated practice database.
-- ALTER DATABASE [CompatibilityPractice]
-- SET COMPATIBILITY_LEVEL = 160;

Notieren Sie den Änderungszeitpunkt, damit Query-Store-Intervalle davor und danach nicht vermischt werden. Die Umstellung kann Neukompilierung verursachen. Trennen Sie deshalb anfängliche Kompilierung und Aufwärmen vom dauerhaften Verhalten. Leeren Sie nicht routinemäßig den gesamten Instanz-Plancache: Das erzeugt einen zusätzlichen Eingriff in andere Datenbanken.

Vergleichen Sie Ausführungszahlen und Kosten gemeinsam. Ein besserer Durchschnitt kann eine seltene kritische Abfrage mit starker Verschlechterung verdecken. Mehr Gesamt-CPU kann lediglich mehr Aufrufe bedeuten. Prüfen Sie für wichtige Abfragen Dauer, CPU, Lesevorgänge, Pläne und Parallelität. Verwenden Sie Anwendungstelemetrie für nutzerbezogene Latenzverteilungen, statt sämtliche Perzentile aus aggregierten Query-Store-Intervallen abzuleiten.

Bei einer Regression untersuchen Sie geschätzte und tatsächliche Zeilen, Join-Auswahl, Speicherzuteilungen und Parameterempfindlichkeit. Bewahren Sie beide Pläne auf und testen Sie die Vermutung mit denselben Daten. Ein früherer Plan kann gezielt helfen, doch prüfen Sie den Erfolg einer Erzwingung sowie unterschiedliche Parameter. Jede solche Maßnahme braucht einen Verantwortlichen und einen Prüftermin.

Abnahme und echten Rückfall definieren

Schreiben Sie vorher messbare Kriterien auf: Dauer kritischer Transaktionen, Abschlussfrist von Stapelläufen, Fehlerquote und Ressourcenreserve bei erwarteter Last. Benennen Sie Entscheider und Beobachtungszeitraum. Ein monatlicher Auftrag wird durch einen erfolgreichen Vormittag noch nicht geprüft.

Die Rückkehr zu einem älteren unterstützten Level kann bestimmte Änderungen der Abfrageverarbeitung abmildern. Sie setzt jedoch das Dateiformat nicht zurück und macht eine neue Sicherung nicht auf einer älteren Engine restaurierbar. Ein Engine-Rückfall benötigt einen eigenen getesteten Migrations- und Datenabgleichsplan, besonders nach neuen Schreibzugriffen.

Beachten Sie außerdem Anwendungscode, der Funktionen des neuen Levels verwendet. Nur die Einstellung zurückzusetzen kann dann die Anwendung beschädigen. Halten Sie diese Abhängigkeit aus dem ersten Versuch heraus oder planen Sie den gemeinsamen Rückfall. Bewahren Sie nach Abnahme die Vergleichsdaten auf, entfernen Sie Übergangslösungen nur messgestützt und beobachten Sie den nächsten vollständigen Geschäftszyklus.

Technische Referenzen: Microsoft Learn: Upgrade workflow · Microsoft Learn: Compatibility levels · Microsoft Learn: Query Store state.