Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Gilt für:
SQL Server - nur Windows
In SQL Server 2016 (13.x) und höher werden einige Änderungen erst wirksam, nachdem der Datenbank-Kompatibilitätsgrad geändert wurde. Dies hat verschiedene Gründe:
Da ein Upgrade einen unidirektionalen Vorgang darstellt (ein Downgrade des Dateiformats ist nicht möglich), ist es sinnvoll, das Aktivieren neuer Funktionen als separaten Datenbankvorgang durchzuführen. Es ist möglich, eine Einstellung auf einen früheren Datenbank-Kompatibilitätsgrad zurückzusetzen. Das neue Modell reduziert die Anzahl von Vorgängen, die während einer Ausfallzeit durchgeführt werden müssen.
Änderungen am Abfrageprozessor können komplexe Auswirkungen haben. Auch wenn eine "gute" Änderung am System für die meisten Workloads großartig sein könnte, könnte dies zu einer inakzeptablen Regression bei einer wichtigen Abfrage für andere führen. Durch das Trennen dieser Logik vom Upgradeprozess können Funktionen wie der Abfragespeicher schnell Plan-Regressionsprobleme mindern oder sogar vollständig vermeiden, bevor sie auf Produktionsservern auftauchen.
Die folgenden Verhaltensweisen werden für SQL Server 2017 (14.x) erwartet, wenn eine Datenbank angefügt oder wiederhergestellt wird, und nach einem direkten Upgrade:
- War der Kompatibilitätsgrad einer Benutzerdatenbank vor dem Upgrade 100 oder höher, wird er nach dem Upgrade beibehalten.
- War der Kompatibilitätsgrad einer Benutzerdatenbank vor dem Upgrade 90, wird er auf 100 gesetzt, was dem niedrigsten unterstützten Kompatibilitätsgrad in SQL Server 2017 (14.x) entspricht.
- Die Kompatibilitätsebenen der
tempdb,model, undmsdbResourceDatenbanken werden nach dem Upgrade auf die aktuelle Kompatibilitätsstufe festgelegt. - Die
master-Systemdatenbank behält den Kompatibilitätsgrad von vor dem Upgrade bei.
Der Upgradevorgang zum Aktivieren neuer Abfrageprozessorfunktionen steht im Zusammenhang mit dem Wartungsmodell des Produkts nach der Einführung. Einige dieser Fixes werden unter dem Ablaufverfolgungsflag 4199 zur Verfügung gestellt. Kundschaft, die Fixes benötigt, kann diese abonnieren, ohne unerwartete Regressionen für andere Kund*innen zu verursachen. Das Wartungsmodell für Abfrageprozessor-Hotfixes nach der Einführung ist hierdokumentiert. Ab SQL Server 2016 (13.x) bedeutet das Verschieben in einen neuen Kompatibilitätsgrad, dass das Ablaufverfolgungsflag 4199 nicht mehr benötigt wird, da diese Fixes nun standardmäßig im aktuellsten Kompatibilitätsgrad aktiviert sind. Im Rahmen des Upgradevorgangs ist es daher wichtig, sich zu vergewissern, dass 4199 nicht aktiviert ist, nachdem der Upgradevorgang abgeschlossen ist.
Hinweis
Das Ablaufverfolgungsflag 4199 ist weiterhin erforderlich, um alle neuen Abfrageprozessor-Problembehebungen zu aktivieren, die nach RTM freigegeben wurden (sofern zutreffend).
Informationen zum empfohlenen Workflow zum Upgrade des Abfrageprozessors auf die neueste Version des Codes finden Sie im Abschnitt "Beibehalten der Leistungsstabilität" während des Upgrades auf neuere SQL Server-Abschnitt der Abfragespeicherverwendungsszenarien.
Ab SQL Server Management Studio 18 können Benutzer mithilfe des Abfrageoptimierungs-Assistenten durch den empfohlenen Workflow geführt werden. Weitere Informationen finden Sie unter Upgrade von Datenbanken mithilfe des Query-Tuning-Assistenten.