Ändern des Datenbank-Kompatibilitätsgrads und Verwenden des Abfragedatenspeichers

  • Artikel

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. Obwohl eine „positive“ Änderung am System für die meisten Workloads sehr gut sein kann, könnte sie an anderer Stelle für eine wichtige Abfrage eine unzulässige Regression verursachen. Durch die Trennung dieser Logik vom Upgradevorgang können Features, wie z. B. der Abfragespeicher, Planauswahlregressionen auf Produktionsservern schnell abschwächen oder sogar komplett vermeiden.

Die folgenden Verhaltensweisen werden für SQL Server 2017 (14.x) erwartet, wenn eine Datenbank angefügt oder wiederhergestellt wird, und werden nach einem direkten Upgrade erwartet:

  • 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.
  • Der Kompatibilitätsgrad der Datenbanken tempdb, model, msdb und der Ressourcendatenbank wird nach dem Upgrade auf den aktuellen Kompatibilitätsgrad 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).

Der empfohlene Workflow für eine Aktualisierung des Abfrageprozessors auf die neueste Version des Codes ist in den „Verwendungsszenarien für den Abfragespeicher“ unter Aufrechterhalten einer stabilen Leistung während des Upgrades auf das neuere SQL Server dokumentiert (siehe weiter unten).

Diagramm: Empfohlener Workflow für die Aktualisierung des Abfrageprozessors auf die neueste Version des Codes

Ab SQL Server Management Studio v18 können Benutzer im Abfrageoptimierungs-Assistenten durch den empfohlenen Workflow geführt werden. Weitere Informationen finden Sie unter Upgraden von Datenbanken mit dem Abfrageoptimierungs-Assistenten.

Siehe auch