ALTER DATABASE (Transact-SQL): Kompatibilitätsgrad

Gilt für:SQL ServerAzure SQL-DatenbankVerwaltete Azure SQL-Instanz

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

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

Syntax

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

Arguments

database_name

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

COMPATIBILITY_LEVEL { 170 | 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. Weitere Informationen zu einer unterstützten Erfahrung beim Aktualisieren der Datenbankkompatibilitätsstufe finden Sie unter Upgradedatenbanken mithilfe des Abfrageoptimierungs-Assistenten.

Remarks

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. Bei Datenbanken, die von einer früheren Version von SQL Server angefügt oder wiederhergestellt wurden, behält die Datenbank ihre vorhandene Kompatibilitätsstufe bei, wenn sie mindestens mindestens für diese Instanz von SQL Server zulässig ist. 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.

Für bereits vorhandene Datenbanken, die auf niedrigeren Kompatibilitätsebenen ausgeführt werden, ist es ein gültiger Ansatz, um die vorherige Datenbankkompatibilitätsstufe beizubehalten, solange die Anwendung keine Verbesserungen verwenden muss, die nur auf einer höheren Datenbankkompatibilitätsebene verfügbar sind. Für neue Entwicklungsvorgänge oder wenn eine vorhandene Anwendung neue Features wie intelligente Abfrageverarbeitung in SQL-Datenbanken und einige neue Transact-SQL erfordert, planen Sie, die Datenbankkompatibilitätsstufe auf die neueste verfügbare Version zu aktualisieren. 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.

Um die aktuelle Kompatibilitätsebene einer Datenbank anzuzeigen, fragen Sie die compatibility_level Spalte in der Sys.databases-Katalogansicht ab.

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, weist eine Kompatibilitätsstufe von 90 auf, die 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 die Datenbankkompatibilitätsebene 120 oder höher insgesamt für eine Datenbank verwenden möchten, sich aber für das Kardinalitätsschätzungsmodell von SQL Server 2012 (11.x) entscheiden, das der Datenbankkompatibilitätsebene 110 zugeordnet ist, lesen Sie ALTER DATABASE SCOPED CONFIGURATION und insbesondere dessen Schlüsselwort LEGACY_CARDINALITY_ESTIMATION = ON.

Hinweise für Azure SQL

Die Standardkompatibilitätsstufe ist 170 für neu erstellte Datenbanken in Azure SQL-Datenbank und SQL-Datenbank in Microsoft Fabric Preview.

Die Standardkompatibilitätsstufe ist 150 für neu erstellte Datenbanken mit der SQL Server 2022-Updaterichtlinie des Azure SQL Managed Instance-Angebots.

Die Standardkompatibilitätsstufe ist 170 für neu erstellte Datenbanken mit dem Always-up-to-Datum oder der SQL Server 2025-Updaterichtlinie des Azure SQL Managed Instance-Angebots.

Microsoft aktualisiert nicht automatisch die Datenbankkompatibilitätsstufe für vorhandene Datenbanken. Es liegt an den Kunden, nach eigenem Ermessen zu tun.

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

Um die aktuelle Kompatibilitätsstufe zu ermitteln, fragen Sie die compatibility_level Spalte von sys.databases ab.

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 die Anwendung keine Verbesserungen verwenden muss, die nur auf einer höheren Datenbankkompatibilitätsebene verfügbar sind, ist es ein gültiger Ansatz, um das SQL Server-Datenbankmodul zu aktualisieren und die vorherige Datenbankkompatibilitätsstufe beizubehalten. Weitere Informationen zur Verwendung der Kompatibilitätsstufe für die 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 es sein, zu einem bestimmten Zeitpunkt auf die neueste Kompatibilitätsstufe zu aktualisieren, um einige der neuen Features wie intelligente Abfrageverarbeitung in SQL-Datenbanken zu erben, aber dies auf kontrollierte Weise zu tun.

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.

• In einer bestimmten SQL Server-Version eingeführte nicht mehr vorhandene Funktionen sind durch Kompatibilitätsstufe 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 nicht mehr verfügbaren Funktionen finden Sie unter "Nicht mehr vorhandene Datenbankmodulfunktionen" 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 sind jedoch nicht durch Kompatibilitätsstufe 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.

  Beispiele für nicht durch Kompatibilitätsstufe geschützte Änderungen sind:

  • 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 (Could not find stored procedure 'sp_dboption').

    Weitere Informationen zum Unterbrechen von Änderungen finden Sie unter:

    • Wichtige Änderungen an Funktionen der Datenbank-Engine in SQL Server 2019
    • Unterbrechen von Änderungen an Datenbankmodulfeatures in SQL Server 2017
    • Wichtige Änderungen an Funktionen der Datenbank-Engine in SQL Server 2016

Unterschiede zwischen Kompatibilitätsgraden

Für alle Installationen von SQL Server ist die Standardkompatibilitätsstufe der Version des Datenbankmoduls zugeordnet, wie in dieser Tabelle dargestellt. 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 Ablaufverfolgungskennzeichnung 4199.
   • auf Datenbankebene mit der QUERY_OPTIMIZER_HOTFIXES-Option in ALTER DATABASE SCOPED CONFIGURATION (Transact-SQL)
   • Auf Abfrageebene mit dem USE HINT 'ENABLE_QUERY_OPTIMIZER_HOTFIXES'Abfragehinweis durch Ändern der Abfrage.
   • Auf Abfrageebene, ohne USE HINT 'ENABLE_QUERY_OPTIMIZER_HOTFIXES' Codeänderungen, verwenden Sie das Feature " Abfragespeicherhinweise ".

   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	TF 4199	Abfrageoptimierer-Änderungen aus früheren Datenbank-Kompatibilitätsgraden	QO-Änderungen für (DE)-Version nach RTM
   13 (SQL Server 2016 (13.x))	100 bis 120 130	Off On Off On	Disabled Enabled Enabled Enabled	Disabled Enabled Disabled Enabled
   14 (SQL Server 2017 (14.x))	100 bis 120 130 140	Off On Off On Off On	Disabled Enabled Enabled Enabled Enabled Enabled	Disabled Enabled Disabled Enabled Disabled Enabled
   15 (SQL Server 2019 (15.x)) und (Azure SQL-Datenbank)	100 bis 120 130 bis 140 150	Off On Off On Off On	Disabled Enabled Enabled Enabled Enabled Enabled	Disabled Enabled Disabled Enabled Disabled Enabled
   16 (SQL Server 2022 (16.x)) und (Azure SQL-Datenbank)	100 bis 120 130 bis 150 160	Off On Off On Off On	Disabled Enabled Enabled Enabled Enabled Enabled	Disabled Enabled Disabled Enabled Disabled Enabled
   17 (SQL Server 2025 (17.x) Vorschau, Azure SQL-Datenbank und SQL-Datenbank in Microsoft Fabric Preview)	100 bis 120 130 bis 160 170	Off On Off On Off On	Disabled Enabled Enabled Enabled Enabled Enabled	Disabled Enabled Disabled Enabled Disabled Enabled

   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, Azure SQL-Datenbank und SQL-Datenbank in Microsoft Fabric Preview veröffentlicht wurde, werden nur in der Standardkompatibilitätsebene einer neuen Datenbankmodulversion, aber nicht auf vorherigen Kompatibilitätsstufen aktiviert.

   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 Enabled
   14 (SQL Server 2017 (14.x))1	< 140 140	Disabled Enabled
   15 (SQL Server 2019 (15.x))1	< 150 150	Disabled Enabled
   16 (SQL Server 2022 (16.x))1	< 160 160	Disabled Enabled
   17 (SQL Server 2025 (17.x) Vorschau)1	< 170 170	Disabled Enabled

   ¹ Gilt auch für Azure SQL-Datenbank und SQL-Datenbank in Microsoft Fabric Preview.

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

Unterschiede zwischen Kompatibilitätsebene 160 und Ebene 170

In diesem Abschnitt werden neue Verhaltensweisen beschrieben, die mit Kompatibilitätsebene 170 eingeführt wurden.

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. Um dies zu umgehen, schließen Sie den Bezeichner zwischen Klammern ([]) oder Anführungszeichen ("") ein; Um beispielsweise eine Anwendung zu aktualisieren, die den Bezeichner EXTERNAL auf Kompatibilitätsebene 90 verwendet, können Sie den Bezeichner [EXTERNAL] entweder in oder "EXTERNAL".

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

Permissions

Erfordert die ALTER-Berechtigung für die Datenbank.

Examples

A. Ändern des Kompatibilitätsgrads

Im folgenden Beispiel wird die Kompatibilitätsebene der AdventureWorks2022Beispieldatenbank 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 AS 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)) AS 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

Wenn die Kompatibilitätsebene niedriger als 110 ist, beträgt die Standardformatvorlage für CAST Und CONVERT Vorgänge für Zeit - und Datetime2-Datentypen 121, außer wenn beide Typen in einem berechneten Spaltenausdruck verwendet werden. Für berechnete Spalten ist das Standardformat 0.

Wenn die Kompatibilitätsebene 110 oder höher ist, ist der Standardstil für CAST und CONVERT Vorgänge für Zeit- und Datetime2-Datentypen immer 121. 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 Einstellung der Datenbankkompatibilitätsebene von 90 ist die Variablezuweisung in einer Anweisung zulässig, die einen Operator auf oberster Ebene UNION enthält, aber unerwartete Ergebnisse zurückgibt. Beispielsweise wird in den folgenden Anweisungen der lokalen Variable @v der Wert der Spalte BusinessEntityID aus der Vereinigung von zwei Tabellen zugewiesen. Wenn die Anweisung mehr als einen Wert zurückgibt, wird die SELECT Variable standardmäßig dem letzten zurückgegebenen Wert zugewiesen. In diesem Fall wird die Variable dem letzten Wert richtig zugewiesen, aber auch der Resultset der SELECT UNION Anweisung wird zurückgegeben.

ALTER DATABASE AdventureWorks2022
    SET COMPATIBILITY_LEVEL = 110;
GO

USE AdventureWorks2022;
GO

DECLARE @v AS INT;

SELECT @v = BusinessEntityID
FROM HumanResources.Employee
UNION ALL
SELECT @v = BusinessEntityID
FROM HumanResources.EmployeeAddress;

SELECT @v;

Unter der Einstellung der Datenbankkompatibilitätsebene von 100 und höher ist die Variablenzuweisung in einer Anweisung, die einen Operator der obersten Ebene UNION 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 AS INT;

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

SELECT @v;

Verwandte Inhalte

• 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
• DATENBANK ERSTELLEN
• Anzeigen oder Ändern des Kompatibilitätsgrads einer Datenbank
• Abfragespeicherhinweise