ALTER DATABASE (Transact-SQL): Kompatibilitätsgrad

Gilt für: SQL Server Azure SQL-Datenbank Azure SQL Managed Instance

Legt für Transact-SQL und Verhalten bei der Abfrageverarbeitung fest, dass sie mit der angegebenen Version der SQL-Engine kompatibel sein müssen. Informationen zu anderen ALTER DATABASE-Optionen finden Sie unter ALTER DATABASE.

Weitere Informationen zu Syntaxkonventionen finden Sie unter Transact-SQL-Syntaxkonventionen.

Syntax

ALTER DATABASE database_name
SET COMPATIBILITY_LEVEL = { 160 | 150 | 140 | 130 | 120 | 110 | 100 | 90 }

Argumente

database_name

Der Name der Datenbank, die geändert werden soll.

KOMPATIBILITÄTSGRAD { 160 | 150 | 140 | 130 | 120 | 110 | 100 | 90 | 80 }

Die SQL Server-Version, mit der die Datenbank kompatibel sein soll. Die folgenden Kompatibilitätsgradwerte können konfiguriert werden (nicht alle Versionen unterstützen alle oben genannten Kompatibilitätsgrade):

Bewährte Methoden zum Aktualisieren des Datenbank-Kompatibilitätsgrads

Den empfohlenen Workflow zum Upgraden des Kompatibilitätsgrads finden Sie unter Beibehalten der Leistungsstabilität während des Upgrades auf neuere SQL Server. Unterstützung beim Upgrade des Datenbank-Kompatibilitätsgrads finden Sie außerdem unter Aktualisieren von Datenbanken mit dem Abfrageoptimierung-Assistenten.

Bemerkungen

Bei allen Installationen von SQL Server wird der Standardkompatibilitätsgrad von der Version von Datenbank-Engine abgeleitet. Neue Datenbanken sind auf diesen Grad festgelegt, sofern der Kompatibilitätsgrad der model-Datenbank nicht niedriger ist. Wenn Datenbanken aus einer früheren Version von SQL Server angefügt oder wiederhergestellt werden, behält die Datenbank ihren vorhandenen Kompatibilitätsgrad, wenn es sich dabei um den zulässigen Mindestwert für die SQL Server-Instanz oder um einen höheren Wert handelt. Beim Verschieben einer Datenbank, deren Kompatibilitätsgrad unterhalb des von der Datenbank-Engine festgelegten zulässigen Grads liegt, wird die Datenbank automatisch auf den niedrigsten zulässigen Kompatibilitätsgrad festgelegt. Dies gilt sowohl für die System- als auch für die Benutzerdatenbanken.

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.
• Der Kompatibilitätsgrad der Datenbanken tempdb, model, msdb und „Resource“ wird auf den Standardkompatibilitätsgrad für eine bestimmte Datenbank-Engine-Version festgelegt.
• Die master-Systemdatenbank behält den Kompatibilitätsgrad von vor dem Upgrade bei. Dies wirkt sich nicht auf das Verhalten der Benutzerdatenbank aus.

Bei vorhandenen Datenbanken mit niedrigeren Kompatibilitätsgraden gilt Folgendes: Solange eine Anwendung keine Verbesserungen nutzen muss, die nur bei einem höheren Kompatibilitätsgrad verfügbar sind, ist es sinnvoll, den vorherigen Kompatibilitätsgrad beizubehalten. Bei Neuentwicklungen oder falls eine vorhandene Anwendung neue Features wie die intelligente Abfrageverarbeitung sowie neue Transact-SQL-Abfragen nutzen muss, sollten Sie ein Upgrade auf den neuesten verfügbaren Datenbank-Kompatibilitätsgrad planen. Weitere Informationen finden Sie unter Kompatibilitätsgrade und Upgrades der Datenbank-Engine.

Verwenden Sie ALTER DATABASE, um den Kompatibilitätsgrad der Datenbank zu ändern. Die neue Kompatibilitätsgradeinstellung für eine Datenbank wird wirksam, wenn ein USE <database>-Befehl ausgegeben oder eine neue Anmeldung mit dieser Datenbank als Standarddatenbankkontext verarbeitet wird.

Fragen Sie die Spalte compatibility_level in der Katalogsicht sys.databases ab, um den aktuellen Kompatibilitätsgrad einer Datenbank anzuzeigen.

Eine Verteilungsdatenbank, die in einer früheren Version von SQL Server erstellt wurde und auf SQL Server 2016 (13.x) RTM oder Service Pack 1 aktualisiert wurde, verfügt über einen Kompatibilitätsgrad von „90“, was für andere Datenbanken nicht unterstützt wird. Dies wirkt sich nicht auf die Funktionstüchtigkeit der Replikation aus. Ein Upgrade auf ein späteres Service Pack oder eine spätere Version von SQL Server führt dazu, dass der Kompatibilitätsgrad der Verteilungsdatenbank auf denjenigen der masterdatenbank erhöht wird.

Wenn Sie den Datenbank-Kompatibilitätsgrad 120 oder höher für Ihre gesamte Datenbank nutzen möchten, aber das Kardinalitätsschätzungsmodell von SQL Server 2012 (11.x) bevorzugen, sodass eine Zuordnung zum Datenbank-Kompatibilitätsgrad 110 erfolgt, sollten Sie die Dokumentation zur Anweisung ALTER DATABASE SCOPED CONFIGURATION und insbesondere den Abschnitt zu deren Schlüsselwort LEGACY_CARDINALITY_ESTIMATION = ON lesen.

Hinweise für Azure SQL

Die Standardkompatibilitätsstufe ist SQL Server 2022 (160) für neu erstellte Datenbanken in Azure SQL-Datenbank.

Die Standardkompatibilitätsstufe ist SQL Server 2019 (150) für neu erstellte Datenbanken in Azure SQL verwaltete Instanz.

Microsoft aktualisiert nicht automatisch die Datenbankkompatibilitätsstufe für vorhandene Datenbanken. Kunden können diesen nach Ihren eigenen Bedürfnissen anpassen.

Microsoft empfiehlt Kunden dringend, zum aktuellen Kompatibilitätsgrad zu wechseln, um die neuesten Verbesserungen bei der Abfrageoptimierung zu nutzen. Tipps zum Bewerten der Leistungsunterschiede Ihrer wichtigsten Abfragen zwischen zwei verschiedenen Kompatibilitätsstufen auf Azure SQL-Datenbank finden Sie unter "Verbesserte Abfrageleistung mit Kompatibilitätsebene 130" in Azure SQL-Datenbank. Dieser Artikel bezieht sich auf den Kompatibilitätsgrad 130 und SQL Server. Es gelten jedoch die gleichen Vorgehensweisen für Upgrades auf den Kompatibilitätsgrad 140 oder höher in SQL Server und Azure SQL-Datenbank.

Azure SQL-Datenbank unterstützt nicht alle Features, die nach Kompatibilitätsgrad variieren.

Aktuelle Kompatibilitätsstufe suchen

Führen Sie eine Abfrage für die Spalte compatibility_level von sys.databases aus, um die aktuellen Kompatibilitätsgrad zu ermitteln.

SELECT name, compatibility_level FROM sys.databases;

Führen Sie die folgende Abfrage aus, um die Datenbank-Engine-Version zu bestimmen, mit der Sie verbunden sind.

SELECT SERVERPROPERTY('ProductVersion');

Kompatibilitätsgrade und Upgrades der Datenbank-Engine

Der Datenbank-Kompatibilitätsgrad ist ein wichtiges Tool zur Unterstützung der Datenbankmodernisierung, denn damit können Upgrades für die SQL Server-Datenbank-Engine durchgeführt werden, während der funktionale Status für anbindende Anwendungen erhalten bleibt, indem der vor einem Upgrade wirksame Kompatibilitätsgrad beibehalten wird. Eine ältere Version von SQL Server (z. B. SQL Server 2008 (10.0.x)) kann daher auf SQL Server oder Azure SQL-Datenbank (einschließlich Azure SQL Managed Instance) upgegradet werden, ohne dass Änderungen an Anwendungen (mit Ausnahme von Datenbankverbindungen) erforderlich sind. Weitere Informationen finden Sie unter Kompatibilitätszertifizierung.

Solange für die jeweilige Anwendung keine Verbesserungen genutzt werden müssen, die nur in einem höheren Datenbank-Kompatibilitätsgrad verfügbar sind, ist dieser Ansatz zum Durchführen eines Upgrades für die SQL Server-Datenbank-Engine und zum Beibehalten des vorherigen Datenbank-Kompatibilitätsgrads geeignet. Weitere Informationen zum Verwenden eines Kompatibilitätsgrads für Abwärtskompatibilität finden Sie unter Kompatibilitätszertifizierung.

Kompatibilitätsgrade und gespeicherte Prozeduren

Wenn eine gespeicherte Prozedur ausgeführt wird, verwendet sie den aktuellen Kompatibilitätsgrad der Datenbank, in der sie definiert ist. Wenn die Kompatibilitätseinstellung einer Datenbank geändert wird, werden alle zugehörigen gespeicherten Prozeduren automatisch entsprechend neu kompiliert.

Verwenden des Kompatibilitätsgrads für Abwärtskompatibilität

Die Einstellung Datenbank-Kompatibilitätsgrad bietet Abwärtskompatibilität mit früheren Versionen von SQL Server in Bezug auf das Verhalten von Transact-SQL und der Abfrageoptimierung. Dies gilt allerdings ausschließlich für die angegebene Datenbank und nicht für den gesamten Server.

Beginnend mit dem Kompatibilitätsmodus 130 wurden alle neuen Fixes und Features, die Auswirkungen auf einen Abfrageplan haben, ausdrücklich nur zum neuen Kompatibilitätsmodus hinzugefügt. Dadurch sollte das Risiko während der Upgrades minimiert werden, die durch Leistungseinbußen aufgrund von Abfrageplanänderungen entstanden sind, die möglicherweise auf neue Verhaltensweisen der Abfrageoptimierung zurückgeführt werden können.

Verwenden Sie für Anwendungen den niedrigeren Kompatibilitätsgrad als sichereren Migrationspfad, um versionsbedingte Unterschiede in den Verhalten zu umgehen, die über die jeweilige Einstellung für den Kompatibilitätsgrad gesteuert werden. Das Ziel sollte weiterhin darin bestehen, zu einem späteren Zeitpunkt ein Upgrade auf den neuesten Kompatibilitätsgrad durchzuführen, damit einige der neuen Features wie die intelligente Abfrageverarbeitung auf kontrollierte Weise übernommen werden können.

Ausführlichere Informationen einschließlich des empfohlenen Workflows für ein Upgrade des Datenbank-Kompatibilitätsgrads finden Sie unter Bewährte Methoden zum Aktualisieren des Datenbank-Kompatibilitätsgrads.

• Nicht mehr unterstützte Funktionen, die in einer bestimmten SQL Server-Version eingeführt wurden, werden durch den Kompatibilitätsgrad nicht geschützt. Dies bezieht sich auf Funktionalität, die aus der SQL Server-Datenbank-Engine entfernt wurde. Der FASTFIRSTROW-Hinweis wurde beispielweise in SQL Server 2012 (11.x) nicht mehr unterstützt und durch den OPTION (FAST n )-Hinweis ersetzt. Wenn der Datenbank-Kompatibilitätsgrad auf 110 festgelegt wird, wird der nicht mehr unterstützte Hinweis nicht wiederhergestellt. Weitere Informationen zu veralteten Funktionen finden Sie unter Nicht mehr unterstützte Datenbank-Engine-Funktionalität in SQL Server.

• Unterbrechungen , die in einer bestimmten SQL Server-Version eingeführt wurden, sind möglicherweise nicht durch Kompatibilitätsstufe geschützt. Dies bezieht sich auf Verhaltensänderungen zwischen Versionen der SQL Server-Datenbank-Engine. Das Verhalten von Transact-SQL wird normalerweise durch den Kompatibilitätsgrad geschützt. Geänderte oder entfernte Systemobjekte werden jedoch nicht durch den Kompatibilitätsgrad geschützt.

  Ein Beispiel für eine bahnbrechende Änderung , die durch Kompatibilitätsebene geschützt ist, ist eine implizite Konvertierung von datetime in datetime2-Datentypen . Unter dem Datenbankkompatibilitätsgrad 130 ergibt daraus eine verbesserte Genauigkeit, indem die Bruchteile von Millisekunden berücksichtigt werden, wodurch sich unterschiedliche konvertierte Werte ergeben. Legen Sie zum Wiederherstellen des vorherigen Konvertierungsverhaltens den Kompatibilitätsgrad der Datenbank auf 120 oder niedriger fest.

  Zu Beispielen für wichtige Änderungen, die nicht durch den Kompatibilitätsgrad geschützt sind, zählen die folgenden:

  • Geänderte Spaltennamen in Systemobjekten. In SQL Server 2012 (11.x) wurde die Spalte single_pages_kb von sys.dm_os_sys_info in pages_kb umbenannt. Unabhängig vom Kompatibilitätsgrad erzeugt die Abfrage SELECT single_pages_kb FROM sys.dm_os_sys_info den Fehler 207 (ungültiger Spaltenname).
  • Entfernte Systemobjekte. In SQL Server 2012 (11.x) wurde sp_dboption entfernt. Unabhängig von der Kompatibilitätsstufe erzeugt die Anweisung EXEC sp_dboption 'AdventureWorks2022', 'autoshrink', 'FALSE'; Fehler 2812 (Couldn't find stored procedure 'sp_dboption').

  Weitere Informationen zu wichtigen Änderungen finden Sie unter Wichtige Änderungen für Datenbank-Engine-Features in SQL Server 2019, Wichtige Änderungen für Datenbank-Engine-Features in SQL Server 2017, Wichtige Änderungen für Datenbank-Engine-Features in SQL Server 2016 und Wichtige Änderungen für Datenbank-Engine-Features in SQL Server 2014.

Unterschiede zwischen Kompatibilitätsgraden

Bei allen Installationen von SQL Server wird der Standardkompatibilitätsgrad von der Version von Datenbank-Engine abgeleitet. Dies wird in dieser Tabelle veranschaulicht. Planen Sie für neue Entwicklungsprojekte immer die Zertifizierung der Anwendungen auf den aktuellsten Datenbank-Kompatibilitätsgrad.

Die Transact-SQL-Syntax wird nicht durch den Datenbank-Kompatibilitätsgrad abgegrenzt, solange sie keine bestehenden Anwendungen beschädigen kann, weil sie zu einem Konflikt mit Transact-SQL-Benutzercode führt. Diese Ausnahmen werden in den nächsten Abschnitten dieses Artikels dokumentiert. In diesen werden die Unterschiede zwischen bestimmten Kompatibilitätsgraden erläutert.

Der Datenbank-Kompatibilitätsgrad bietet zudem Abwärtskompatibilität mit früheren Versionen von SQL Server, da angefügte oder aus älteren Versionen von SQL Server wiederhergestellte Datenbanken ihren vorhandenen Kompatibilitätsgrad beibehalten, sofern dieser dem mindestens zulässigen Kompatibilitätsgrad oder höher entspricht. Diese Vorgehensweise wurde im Abschnitt Verwenden des Kompatibilitätsgrads für Abwärtskompatibilität bereits erläutert.

Ab Datenbank-Kompatibilitätsgrad 130 werden alle neuen Fixes und Features, die sich auf Abfragepläne auswirken, nur zum aktuellsten Kompatibilitätsgrad hinzugefügt. Dieser wird auch als „Standardkompatibilitätsgrad“ bezeichnet. Dadurch sollte das Risiko während der Upgrades minimiert werden, die durch Leistungseinbußen aufgrund von Abfrageplanänderungen entstanden sind und möglicherweise auf neue Verhaltensweisen der Abfrageoptimierung zurückgeführt werden können.

Diese grundlegenden Änderungen, die sich auf den Plan auswirken, werden nur zum Standardkompatibilitätsgrad einer neuen Version von Datenbank-Engine hinzugefügt:

1. Fixes für den Abfrageoptimierer, die für vorherige Versionen von SQL Server unter dem Ablaufverfolgungsflag 4199 veröffentlicht wurden, werden im Standardkompatibilitätsgrad einer neueren Version von SQL Server automatisch aktiviert.

   Gilt für: SQL Server (ab Version SQL Server 2016 (13.x)), Azure SQL-Datenbank.

   Als SQL Server 2016 (13.x) veröffentlicht wurde, wurden beispielsweise alle Fixes für den Abfrageoptimierer, die für vorherige Versionen von SQL Server (und die Kompatibilitätsgrade 100 bis 120) veröffentlicht wurden, automatisch für Datenbanken aktiviert, die den Standardkompatibilitätsgrad von SQL Server 2016 (13.x) (130) verwenden. Nur Fixes für den Abfrageoptimierer, die für Versionen nach RTM gelten, müssen explizit aktiviert werden.

   Sie können folgende Methoden verwenden, um Fixes für den Abfrageoptimierer zu aktivieren:

   • auf Serverebene mit dem Ablaufverfolgungsflag 4199
   • auf Datenbankebene mit der QUERY_OPTIMIZER_HOTFIXES-Option in ALTER DATABASE SCOPED CONFIGURATION (Transact-SQL)
   • Auf Abfrageebene mithilfe des Abfragehinweises USE HINT 'ENABLE_QUERY_OPTIMIZER_HOTFIXES', indem Sie die Abfrage ändern
   • Auf Abfrageebene mit USE HINT 'ENABLE_QUERY_OPTIMIZER_HOTFIXES' ohne Codeänderungen mithilfe des Features Abfragespeicherhinweis (Vorschau)

   Als SQL Server 2017 (14.x) dann veröffentlicht wurde, wurden alle Fixes für den Abfrageoptimierer, die nach SQL Server 2016 (13.x) RTM veröffentlicht wurden, automatisch für Datenbanken aktiviert, die den Standardkompatibilitätsgrad von SQL Server 2017 (14.x) (140) verwenden. Dabei handelt es sich um kumulatives Verhalten, das auch alle früheren Versionen der Fixes enthält. Auch hier müssen nur Fixes für den Abfrageoptimierer, die für Post-RTM gelten, explizit aktiviert werden.

   In der folgenden Tabelle wird dieses Verhalten zusammengefasst:

   Version der Datenbank-Engine	Datenbank-Kompatibilitätsgrad	Ablaufverfolgungsflag 4199	Abfrageoptimierer-Änderungen aus früheren Datenbank-Kompatibilitätsgraden	Abfrageoptimierer-Änderungen für Versionen der Datenbank-Engine nach RTM
   13 (SQL Server 2016 (13.x))	100 bis 120 130	Aus Andererseits Aus Andererseits	Disabled Aktiviert Aktiviert Aktiviert	Disabled Aktiviert Disabled Aktiviert
   14 (SQL Server 2017 (14.x))	100 bis 120 130 140	Aus Andererseits Aus Andererseits Aus Andererseits	Disabled Aktiviert Aktiviert Aktiviert Aktiviert Aktiviert	Disabled Aktiviert Disabled Aktiviert Disabled Aktiviert
   15 (SQL Server 2019 (15.x)) und 12 (Azure SQL-Datenbank)	100 bis 120 130 bis 140 150	Aus Andererseits Aus Andererseits Aus Andererseits	Disabled Aktiviert Aktiviert Aktiviert Aktiviert Aktiviert	Disabled Aktiviert Disabled Aktiviert Disabled Aktiviert
   16 (SQL Server 2022 (16.x)) und 12 (Azure SQL-Datenbank)	100 bis 120 130 bis 150 160	Aus Andererseits Aus Andererseits Aus Andererseits	Disabled Aktiviert Aktiviert Aktiviert Aktiviert Aktiviert	Disabled Aktiviert Disabled Aktiviert Disabled Aktiviert

   Fixes für den Abfrageoptimierer, die falsche Ergebnisse oder Fehler durch Zugriffsverletzungen beheben, werden nicht durch das Ablaufverfolgungsflag 4199 geschützt. Diese Fixes sind nicht optional.

2. Änderungen an der Kardinalitätsschätzung, die in SQL Server und Azure SQL-Datenbank veröffentlicht wurden, werden nur im Standardkompatibilitätsgrad einer neuen Version von Datenbank-Engine , nicht jedoch in früheren Kompatibilitätsgraden veröffentlicht.

   Als SQL Server 2016 (13.x) veröffentlicht wurde, waren Änderungen an der Kardinalitätsschätzung beispielsweise nur für Datenbanken verfügbar, die den Standardkompatibilitätsgrad von SQL Server 2016 (13.x) (130) verwendet haben. Für frühere Kompatibilitätsgrade wurde das Verhalten der Kardinalitätsschätzung beibehalten, das vor SQL Server 2016 (13.x) verfügbar war.

   Als SQL Server 2017 (14.x) später veröffentlicht wurde, waren neuere Änderungen an der Kardinalitätsschätzung beispielsweise nur für Datenbanken verfügbar, die den Standardkompatibilitätsgrad von SQL Server 2017 (14.x) (140) verwendet haben. Für den Datenbank-Kompatibilitätsgrad 130 wurde das Verhalten der Kardinalitätsschätzung von SQL Server 2016 (13.x) beibehalten.

   In der folgenden Tabelle wird dieses Verhalten zusammengefasst:

   Version der Datenbank-Engine	Datenbank-Kompatibilitätsgrad	Änderungen an neueren Versionen der Kardinalitätsschätzung
   13 (SQL Server 2016 (13.x))	< 130 130	Disabled Aktiviert
   14 (SQL Server 2017 (14.x))1	< 140 140	Disabled Aktiviert
   15 (SQL Server 2019 (15.x))1	< 150 150	Disabled Aktiviert
   16 (SQL Server 2022 (16.x))1	< 160 160	Disabled Aktiviert

   ¹ Gilt auch für Azure SQL-Datenbank

Weitere Unterschiede zwischen den einzelnen Kompatibilitätsgraden werden in den nächsten Abschnitten dieses Artikels behandelt.

Unterschiede zwischen Kompatibilitätsgrad 150 und Kompatibilitätsgrad 160

In diesem Abschnitt werden neue mit Kompatibilitätsgrad 160 eingeführte Verhaltensweisen beschrieben.

Unterschiede zwischen Kompatibilitätsgrad 140 und Kompatibilitätsgrad 150

In diesem Abschnitt werden neue mit Kompatibilitätsgrad 150 eingeführte Verhaltensweisen beschrieben.

Weitere Informationen zu Abfrageverarbeitungsfeatures, die im Datenbank-Kompatibilitätsgrad 150 aktiviert sind, finden Sie unter Neuigkeiten zu SQL Server 2019 und Intelligente Abfrageverarbeitung in SQL-Datenbanken.

Unterschiede zwischen Kompatibilitätsgrad 130 und Kompatibilitätsgrad 140

In diesem Abschnitt werden neue mit Kompatibilitätsgrad 140 eingeführte Verhaltensweisen beschrieben.

Fixes unter dem Ablaufverfolgungsflag 4199 in früheren Versionen von SQL Server vor SQL Server 2017 sind jetzt standardmäßig aktiviert. Mit Kompatibilitätsmodus 140. Das Ablaufverfolgungsflag 4199 gilt weiterhin für Fixes für den neuen Abfrageoptimierer, die nach SQL Server 2017 veröffentlicht werden. Informationen zum Ablaufverfolgungsflag 4199 finden Sie unter Ablaufverfolgungsflag 4199.

Unterschiede zwischen Kompatibilitätsgrad 120 und Kompatibilitätsgrad 130

In diesem Abschnitt werden neue mit Kompatibilitätsgrad 130 eingeführte Verhaltensweisen beschrieben.

Fixes unter dem Ablaufverfolgungsflag 4199 in früheren Versionen von SQL Server vor SQL Server 2016 (13.x) sind jetzt standardmäßig aktiviert. Mit Kompatibilitätsmodus 130. Das Ablaufverfolgungsflag 4199 gilt weiterhin für Fixes für den neuen Abfrageoptimierer, die nach SQL Server 2016 (13.x) veröffentlicht werden. Für die Verwendung des älteren Abfrageoptimierers in SQL-Datenbank müssen Sie den Kompatibilitätsgrad 110 auswählen. Informationen zum Ablaufverfolgungsflag 4199 finden Sie unter Ablaufverfolgungsflag 4199.

Unterschiede zwischen niedrigeren Kompatibilitätsgraden und Kompatibilitätsgrad 120

In diesem Abschnitt werden neue mit Kompatibilitätsgrad 120 eingeführte Verhaltensweisen beschrieben.

Unterschiede zwischen niedrigeren Kompatibilitätsgraden und den Kompatibilitätsgraden 100 und 110

In diesem Abschnitt werden neue mit Kompatibilitätsgrad 110 eingeführte Verhaltensweisen beschrieben. Dieser Abschnitt bezieht sich auch auf höhere Kompatibilitätsgrade als 110.

Unterschiede zwischen Kompatibilitätsgrad 90 und Kompatibilitätsgrad 100

In diesem Abschnitt werden neue mit Kompatibilitätsgrad 100 eingeführte Verhaltensweisen beschrieben.

Reservierte Schlüsselwörter

Die Kompatibilitätseinstellung bestimmt außerdem die für das Datenbank-Engine reservierten Schlüsselwörter. In der folgenden Tabelle sind die reservierten Schlüsselwörter aufgeführt, die mit den einzelnen Kompatibilitätsgraden eingeführt werden.

Bei einem bestimmten Kompatibilitätsgrad schließen die reservierten Schlüsselwörter alle Schlüsselwörter ein, die mit diesem oder einem niedrigeren Grad eingeführt wurden. So stellen z. B. bei Anwendungen mit dem Kompatibilitätsgrad 110 alle in der vorherigen Tabelle aufgeführten Schlüsselwörter reservierte Schlüsselwörter dar. Bei den niedrigeren Kompatibilitätsgraden stellen die Schlüsselwörter von Grad 100 weiterhin gültige Objektnamen dar; die Sprachfunktionen von Grad 110, die diesen Schlüsselwörtern entsprechen, sind jedoch nicht verfügbar.

Nach der Einführung bleibt ein Schlüsselwort reserviert. So stellt z. B. das reservierte Schlüsselwort PIVOT, das mit dem Kompatibilitätsgrad 90 eingeführt wurde, auch bei Grad 100, 110 und 120 ein reserviertes Schlüsselwort dar.

Wenn eine Anwendung einen Bezeichner verwendet, der für den Kompatibilitätsgrad der Anwendung als Schlüsselwort reserviert ist, erzeugt die Anwendung einen Fehler. Sie können dies umgehen, indem Sie den Bezeichner in eckige Klammern ( [] ) oder Anführungszeichen( "" ) einschließen. Wenn Sie z. B. eine Anwendung, die den Bezeichner EXTERNAL verwendet, auf den Kompatibilitätsgrad 90 aktualisieren möchten, könnten Sie den Bezeichner ändern, sodass er anschließend entweder [EXTERNAL] oder "EXTERNAL" lautet.

Weitere Informationen finden Sie unter Reservierte Schlüsselwörter.

Berechtigungen

Erfordert die ALTER-Berechtigung für die Datenbank.

Beispiele

A. Ändern des Kompatibilitätsgrads

Im folgenden Beispiel wird die Kompatibilitätsebene der AdventureWorks2022 Beispieldatenbank auf 150 geändert, die Standardeinstellung für SQL Server 2019 (15.x).

ALTER DATABASE AdventureWorks2022
SET COMPATIBILITY_LEVEL = 150;
GO

Im folgenden Beispiel wird der Kompatibilitätsgrad der aktuellen Datenbank zurückgegeben.

SELECT name, compatibility_level
FROM sys.databases
WHERE name = db_name();
GO

B. Ignorieren der SET LANGUAGE-Anweisung außer bei einem Kompatibilitätsgrad von mindestens 120

Die folgende Abfrage ignoriert die SET LANGUAGE-Anweisung außer bei einem Kompatibilitätsgrad von mindestens 120.

SET DATEFORMAT dmy;
DECLARE @t2 date = '12/5/2011' ;
SET LANGUAGE dutch;
SELECT CONVERT(varchar(11), @t2, 106);
GO

Ergebnisse, wenn der Kompatibilitätsgrad kleiner als 120 ist: 12 May 2011

Ergebnisse, wenn der Kompatibilitätsgrad auf 120 oder höher festgelegt ist: 12 mei 2011

C. Rekursive Verweise auf der rechten Seite einer EXCEPT-Klausel erzeugen bei der Kompatibilitätsgradeinstellung von 110 oder niedriger eine Endlosschleife.

WITH cte AS
    (SELECT * FROM (VALUES (1),(2),(3)) v (a)),
r AS
    (SELECT a FROM cte
    UNION ALL
    (SELECT a FROM cte EXCEPT SELECT a FROM r)
)
SELECT a
FROM r;
GO

D: Der Unterschied zwischen den Formaten 0 und 121

Bei einem Kompatibilitätsgrad unter 110 ist 121 das Standardformat für CAST- und CONVERT-Vorgänge bei den Datentypen time und datetime2, es sei denn, einer der Typen wird in einem berechneten Spaltenausdruck verwendet. Für berechnete Spalten ist das Standardformat 0.

Bei einem Kompatibilitätsgrad ab 110 ist 121 immer das Standardformat für CAST- und CONVERT-Vorgänge im Fall der Datentypen time und datetime2. Weitere Informationen finden Sie unter Unterschiede zwischen niedrigeren Kompatibilitätsgraden und den Kompatibilitätsgraden 100 und 110.

Weitere Informationen zu Datums- und Zeitformaten finden Sie unter CAST und CONVERT.

DROP TABLE IF EXISTS t1;
GO

CREATE TABLE t1 (c1 time(7), c2 datetime2);
GO

INSERT t1 (c1,c2) VALUES (GETDATE(), GETDATE());
GO

SELECT CONVERT(nvarchar(16),c1,0) AS TimeStyle0
       ,CONVERT(nvarchar(16),c1,121)AS TimeStyle121
       ,CONVERT(nvarchar(32),c2,0) AS Datetime2Style0
       ,CONVERT(nvarchar(32),c2,121)AS Datetime2Style121
FROM t1;
GO

Dadurch werden Ergebnisse wie die folgenden zurückgegeben:

E. Variablenzuweisung – UNION-Operator auf der obersten Ebene

Unter der Datenbank-Kompatibilitätsgradeinstellung 90 ist die Variablenzuweisung in einer Anweisung zulässig, die einen UNION-Operator der obersten Ebene enthält, gibt jedoch unerwartete Ergebnisse zurück. Beispielsweise wird in den folgenden Anweisungen der lokalen Variable @v der Wert der Spalte BusinessEntityID aus der Vereinigung von zwei Tabellen zugewiesen. Wenn die SELECT-Anweisung mehr als einen Wert zurückgibt, wird der Variablen definitionsgemäß der zuletzt zurückgegebene Wert zugewiesen. In diesem Fall wird der Variablen der letzte Wert richtig zugewiesen, es wird jedoch auch das Resultset der SELECT UNION-Anweisung zurückgegeben.

ALTER DATABASE AdventureWorks2022
SET compatibility_level = 110;
GO
USE AdventureWorks2022;
GO
DECLARE @v int;
SELECT @v = BusinessEntityID FROM HumanResources.Employee
UNION ALL
SELECT @v = BusinessEntityID FROM HumanResources.EmployeeAddress;
SELECT @v;

Unter der Datenbank-Kompatibilitätsgradeinstellung von mindestens 100 ist die Variablenzuweisung in einer Anweisung, die einen UNION-Operator der obersten Ebene enthält, nicht zulässig. Der Fehler 10734 wird zurückgegeben.

Um den Fehler zu beheben, müssen Sie die Abfrage umschreiben, wie im folgenden Beispiel gezeigt.

DECLARE @v int;
SELECT @v = BusinessEntityID FROM
    (SELECT BusinessEntityID FROM HumanResources.Employee
     UNION ALL
     SELECT BusinessEntityID FROM HumanResources.EmployeeAddress) AS Test;
SELECT @v;

Zugehöriger Inhalt

• Aufrechterhalten einer stabilen Leistung während des Upgrades auf neuere SQL Server-Versionen
• Ändern des Datenbank-Kompatibilitätsgrads und Verwenden des Abfragespeichers
• Kompatibilitätszertifizierung
• ALTER DATABASE (Transact-SQL)
• Aktualisieren von Datenbanken mithilfe des Abfrageoptimierungs-Assistenten
• CREATE DATABASE
• Anzeigen oder Ändern des Kompatibilitätsgrads einer Datenbank
• Abfragespeicherhinweise