Freigeben über

ALTER DATABASE (Transact-SQL): Kompatibilitätsgrad

  • Artikel

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):

Produkt Version der Datenbank-Engine Bestimmung des Kompatibilitätsgrads mit Standards Unterstützte Kompatibilitätsgradwerte
Azure SQL-Datenbank 16 160 160, 150, 140, 130, 120, 110, 100
Verwaltete Azure SQL-Datenbank-Instanz 16 150 160, 150, 140, 130, 120, 110, 100
SQL Server 2022 (16.x) 16 160 160, 150, 140, 130, 120, 110, 100
SQL Server 2019 (15.x) 15 150 150, 140, 130, 120, 110, 100
SQL Server 2017 (14.x) 14 140 140, 130, 120, 110, 100
SQL Server 2016 (13.x) 13 130 130, 120, 110, 100
SQL Server 2014 (12.x) 12 120 120, 110, 100
SQL Server 2012 (11.x) 11 110 110, 100, 90
SQL Server 2008 R2 (10.50.x) 10,5 100 100, 90, 80
SQL Server 2008 (10.0.x) 10 100 100, 90, 80
SQL Server 2005 (9.x) 9 90 90, 80
SQL Server 2000 (8.x) 8 80 80

Wichtig

Die Versionsnummern der Datenbank-Engine für SQL Server und Azure SQL-Datenbank sind nicht miteinander vergleichbar, sondern sind interne Buildnummern für diese separaten Produkte. Die Datenbank-Engine für Azure SQL-Datenbank basiert auf der gleichen Codebasis wie die SQL Server-Datenbank-Engine. Entscheidend ist dabei, dass die Datenbank-Engine in Azure SQL-Datenbank immer über die neuesten SQL-Datenbank-Engine-Bits verfügt. Version 12 von Azure SQL-Datenbank ist neuer als Version 15 von SQL Server.

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.

Hinweis

Wenn keine Benutzerobjekte und Abhängigkeiten vorhanden sind, ist ein Upgrade auf den Standardkompatibilitätsgrad in aller Regel sicher. Weitere Informationen finden Sie unter Empfehlungen - Masterdatenbank.

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:

    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

    1 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.

Kompatibilitätsgradeinstellung 150 oder niedriger Kompatibilitätsgradeinstellung 160
Parameterisierte Abfragen verfügen über einen einzelnen Abfrageplan basierend auf den Parametern, die für die erste Ausführung verwendet werden. Nur ein Abfrageplan wird zwischengespeichert und für alle Parameterwerte verwendet. Dies kann dazu führen, dass ein Abfrageplan für einige Werte des Parameters ineffizient sein kann, auch als Parameter-empfindlicher Plan bezeichnet. Parameterisierte Abfragen können mehrere zwischengespeicherte Abfragepläne für verschiedene Auswahlkategorien eines Parameters haben. Die Optimierung Parameter-empfindlicher Pläne ist standardmäßig in Kompatibilitätsebene 160 aktiviert. Weitere Informationen finden Sie unter PSP-Optimierung.
Die Kardinalitätsschätzung verwendet nur einen Standardsatz von Modellannahmen über die zugrunde liegenden Datenverteilungs- und Nutzungsmuster für alle Datenbanken und Abfragen. Die einzige Möglichkeit, eine dieser Annahmen zu ändern oder anzupassen, besteht darin, dass der Benutzer einen manuellen Prozess durchführt, um mithilfe von Abfragehinweisen explizit anzugeben, welche Modellannahmen verwendet werden sollten. Es kann keine interne Anpassung an dieses Standardmodell vorgenommen werden, nachdem ein Abfrageplan generiert wurde. Die Kardinalitätsschätzung beginnt mit der Standardmenge von Modellannahmen über die zugrunde liegenden Datenverteilungs- und Nutzungsmuster, aber nach einigen Ausführungen für eine bestimmte Abfrage lernt die Microsoft SQL Server-Datenbank-Engine, welche unterschiedlichen Mengen von Modellannahmen möglicherweise genauere Schätzungen liefern und passt daher die verwendeten Annahmen an, damit sie besser zu dem abgefragten Datensatz passen. CE-Feedback ist standardmäßig in Kompatibilitätsstufe 160 aktiviert. Weitere Informationen finden Sie unter CE-Feedback.
Es wird keine automatische Bestimmung des optimalen Grads an Parallelismus durch die Microsoft SQL Server-Datenbank-Engine versucht. Informationen zum manuellen Steuern des maximalen Parallelitätsgrads (MAXDOP) auf Instanz-, Datenbank-, Abfrage- oder Workloadebene finden Sie unter Serverkonfiguration: max. Parallelitätsgrad Das Grad an Parallelismus-(DOP-)Feedback verbessert die Abfrageleistung, indem Parallelismus-Ineffizienzen basierend auf verstrichener Zeit und Wartezeiten für wiederholte Abfragen identifiziert werden. Wenn die Parallelitätsnutzung als ineffizient erachtet wird, verringert das DOP-Feedback die DOP für die nächste Ausführung der Abfrage ausgehend von der konfigurierten DOP, und überprüft, ob dies hilfreich war. DOP-Feedback ist standardmäßig nicht aktiviert. Um DOP-Feedback zu aktivieren, aktivieren Sie die DOP_FEEDBACK Datenbankweit gültige Konfiguration in einer Datenbank. Weitere Informationen finden Sie unter DOP-Feedback.

Unterschiede zwischen Kompatibilitätsgrad 140 und Kompatibilitätsgrad 150

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

Kompatibilitätsgradeinstellung 140 oder niedriger Kompatibilitätsgradeinstellung 150
Relationale Data Warehouse- und Analyseworkloads können möglicherweise aufgrund von OLTP-Overhead, fehlender Anbieterunterstützung oder anderen Einschränkungen möglicherweise keine Columnstore-Indizes verwenden. Ohne Columnstore-Indizes können diese Workloads nicht vom Batchausführungsmodus profitieren. Der Batchausführungsmodus ist nun für Analyseworkloads verfügbar, ohne dass Columnstore-Indizes erforderlich sind. Weitere Informationen finden Sie unter Batchmodus bei Rowstore.
Zeilenmodusabfragen, die unzureichende Speichererteilungsgrößen anfordern, die zu Überlappungen auf dem Datenträger führen, können weiterhin Probleme mit aufeinanderfolgenden Ausführungen haben. Zeilenmodusabfragen, die unzureichende Speichererteilungsgrößen anfordern, die zu Überlappungen auf dem Datenträger führen, haben möglicherweise die Leistung bei aufeinander folgenden Ausführungen verbessert. Weitere Informationen finden Sie unter Feedback zur Speicherzuweisung im Zeilenmodus.
Zeilenmodusabfragen, die eine übermäßige Größe der Speichererteilung anfordern, die zu Parallelitätsproblemen führt, können weiterhin Probleme mit aufeinander folgenden Ausführungen aufweisen. Zeilenmodusabfragen, die eine übermäßige Größe der Speichererteilung anfordern, die zu Parallelitätsproblemen führt, haben möglicherweise die Parallelität bei aufeinander folgenden Ausführungen verbessert. Weitere Informationen finden Sie unter Feedback zur Speicherzuweisung im Zeilenmodus.
Abfragen, die auf TSQL_SCALAR_UDFs verweisen, verwenden einen iterativen Aufruf, verursachen keine Kosten und erzwingen die serielle Ausführung. Benutzerdefinierte T-SQL-Skalarfunktionen werden in äquivalente relationale Ausdrücke umgewandelt, die inline in die aufrufende Abfrage eingefügt werden, was meist zu erheblichen Leistungsverbesserungen führt. Weitere Informationen finden Sie unter TSQL_SCALAR_UDF_INLINING.
Tabellenvariablen nutzen für die Kardinalitätsschätzung eine festgelegte Schätzung. Wenn die tatsächliche Anzahl der Zeilen sehr viel höher als der geschätzter Wert ist, kann die Leistung nachgelagerter Vorgänge beeinträchtigt werden. Neue Pläne verwenden anstelle einer festgelegten Schätzung die tatsächliche Kardinalität der Tabellenvariablen, die bei der ersten Kompilierung vorgefunden wird. Weitere Informationen finden Sie unter Verzögerte Kompilierung von Tabellenvariablen.

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.

Kompatibilitätsgradeinstellung 130 oder niedriger Kompatibilitätsgradeinstellung 140
Bei Kardinalitätsschätzungen für Anweisungen, die auf Tabellenwertfunktionen mit mehreren Anweisungen verweisen, wird eine feste Zeilenvorhersage verwendet. Bei Kardinalitätsschätzungen für zulässige Anweisungen, die auf Tabellenwertfunktionen mit mehreren Anweisungen verweisen, wird die tatsächliche Kardinalität der Funktionsausgabe verwendet. Dies wird über die geschachtelte Ausführung für Tabellenwertfunktionen mit mehreren Anweisungen aktiviert.
Batchmodusabfragen, die unzureichende Speichererteilungsgrößen anfordern, die zu Überlappungen auf dem Datenträger führen, können weiterhin Probleme mit aufeinander folgenden Ausführungen haben. Batchmodusabfragen, die unzureichende Speicherzuteilungsgrößen anfordern, die zu Überlappungen auf dem Datenträger führen, haben möglicherweise die Leistung bei aufeinander folgenden Ausführungen verbessert. Dies wird über das Feedback zur Speicherzuweisung im Batchmodus ermöglicht, das die Arbeitsspeicherzuweisung eines zwischengespeicherten Plans aktualisiert, wenn es bei Operatoren im Batchmodus zu Überläufen kommt.
Batchmodusabfragen, die eine übermäßige Größe der Speicherzuteilung anfordern, die zu Parallelitätsproblemen führt, können weiterhin Probleme bei aufeinander folgenden Ausführungen aufweisen. Batchmodusabfragen, die eine übermäßige Größe der Speicherzuteilung anfordern, die zu Parallelitätsproblemen führt, haben möglicherweise die Parallelität bei aufeinander folgenden Ausführungen verbessert. Dies wird über das Feedback zur Speicherzuweisung im Batchmodus ermöglicht, das die Arbeitsspeicherzuweisung eines zwischengespeicherten Plans aktualisiert, wenn ursprünglich eine übermäßige Speicherkapazität angefordert wurde.
Abfragen im Batchmodus, die Verknüpfungsoperatorrn enthalten, sind für drei physische LOIN-Algorithmen geeignet, zu denen geschachtelte Schleifen, Hashjoins und Mergejoins zählen. Wenn Kardinalitätsschätzungen für Verknüpfungseingaben falsch sind, kann ein unangemessener Verknüpfungsalgorithmus ausgewählt werden. Dies hat negative Auswirkungen auf die Leistung. Zudem wird der ungeeignete JOIN-Algorithmus so lange weiter verwendet, bis der zwischengespeicherte Plan erneut kompiliert wurde. Es gibt einen weiteren Verknüpfungsoperator mit dem Namen adaptiver Join. Wenn Kardinalitätsschätzungen für die Eingabe der äußeren Build-Verknüpfung falsch sind, wird möglicherweise ein unangemessener Verknüpfungsalgorithmus ausgewählt. Wenn dieser Fall eintritt und die Anweisung für einen adaptiven Join geeignet ist, wird auf dynamische Weise für kleinere Join-Eingaben eine geschachtelte Schleife und für umfangreichere Join-Eingaben ein Hashjoin verwendet, ohne dass eine Rekompilierung erforderlich ist.
Triviale Pläne, die auf Columnstore-Indizes verweisen, sind für eine Ausführung im Batchmodus nicht geeignet. Ein trivialer Plan, der auf Columnstore-Indizes verweist, wird zugunsten eines Plans gelöscht, der für eine Ausführung im Batchmodus geeignet ist.
Der sp_execute_external_script-UDX-Operator kann nur im Zeilenmodus ausgeführt werden. Der sp_execute_external_script-UDX-Operator ist für eine Ausführung im Batchmodus geeignet.
Tabellenwertfunktionen (Table-Valued Functions, TVFs) mit mehreren Anweisungen haben keine verschachtelte Ausführung. Verschachtelte Ausführung für Tabellenwertfunktionen mit mehreren Anweisungen zur Verbesserung der Planqualität.

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.

Kompatibilitätsgradeinstellung 120 oder niedriger Kompatibilitätsgradeinstellung 130
Die INSERT-Anweisung in einer INSERT-SELECT-Anweisung erhält einen einzelnen Thread. Die INSERT-Anweisung in einer INSERT-SELECT-Anweisung erhält mehrere Threads oder kann einen parallelen Plan aufweisen.
Abfragen für eine speicheroptimierte Tabelle werden in einem einzelnen Thread ausgeführt. Abfragen für eine speicheroptimierte Tabelle können jetzt parallele Pläne aufweisen.
Einführung der SQL 2014-Kardinalitätsschätzung CardinalityEstimationModelVersion="120" Weitere Verbesserungen der Kardinalitätsschätzung im Kardinalitätsschätzungsmodell 130, das in einem Abfrageplan angezeigt werden kann. CardinalityEstimationModelVersion="130"
Änderungen des Batchmodus im Vergleich zu Änderungen des Zeilenmodus mit Columnstore-Indizes:
  • Sortierungen in einer Tabelle mit Columnstore-Index weisen einen Zeilenmodus auf
  • Fensterfunktionsaggregate werden in einem Zeilenmodus wie LAG oder LEAD ausgeführt
  • Abfragen in Columnstore-Tabellen mit mehreren unterschiedlichen, im Zeilenmodus ausgeführten Klauseln
  • Abfragen, die unter MAXDOP 1 oder mit einem seriellen Plan im Zeilenmodus ausgeführt werden
 Änderungen des Batchmodus im Vergleich zu Änderungen des Zeilenmodus mit Columnstore-Indizes:
  • Sortierungen in einer Tabelle mit einem Columnstore-Index weisen jetzt einen Batchmodus auf
  • Fensteraggregate werden jetzt in einem Batchmodus wie LAG oder LEAD ausgeführt
  • Abfragen für Columnstore-Tabellen mit mehreren unterschiedlichen, im Batchmodus ausgeführten Klauseln
  • Abfragen unter MAXDOP 1 oder mit einem seriellen Plan werden im Batchmodus ausgeführt
Statistiken können automatisch aktualisiert werden. Die Logik, die Statistiken automatisch aktualisiert, ist bei umfangreichen Tabellen aggressiver. In der Praxis soll dies Fälle reduzieren, in denen Kunden bei Abfragen Leistungsprobleme feststellen, bei denen häufig neu eingefügte Zeilen abgefragt werden, bei denen die Statistiken jedoch nicht entsprechend aktualisiert wurden und diese Werte noch nicht enthalten sind.
Die Ablaufverfolgung 2371 ist in SQL Server 2014 (12.x) standardmäßig auf OFF festgelegt. Die Ablaufverfolgung 2371 ist in SQL Server 2016 (13.x) standardmäßig auf ON festgelegt. Das Ablaufverfolgungsflag 2371 weist den automatischen Statistikupdater an, in einer Tabelle mit vielen Zeilen Stichproben von einer kleineren, aber sinnvolleren Teilmenge von Zeilen durchzuführen.

Eine Verbesserung besteht darin, in der Stichprobe mehr Zeilen einzubeziehen, die kürzlich eingefügt wurden.

Eine weitere Verbesserung besteht darin, Abfragen während des Prozesses der Statistikaktualisierung nicht zu blockieren, sondern weiter auszuführen.
Für den Kompatibilitätsgrad 120 werden in einem Singlethreadprozess Stichproben aus Statistiken entnommen. Für den Kompatibilitätsgrad 130 werden in einem Multithreadprozess Stichproben aus Statistiken entnommen.
Der Grenzwert liegt bei 253 eingehenden Fremdschlüsseln. Bis zu 10.000 eingehende Fremdschlüssel oder vergleichbare Referenzen können auf eine bestimmte Tabelle verweisen. Einschränkungen finden Sie unter Create Foreign Key Relationships.
Die als veraltet markierten Hashalgorithmen MD2, MD4, MD5, SHA und SHA1 sind zulässig. Nur die Hashalgorithmen SHA2_256 und SHA2_512 sind zulässig.
SQL Server 2016 (13.x) schließt Verbesserungen bei einigen Datentypkonvertierungen und einigen Vorgängen (eher selten) ein. Weitere Einzelheiten finden Sie unter SQL Server 2016 improvements in handling some data types and uncommon operations (Verbesserungen der Verarbeitung einiger Datentypen und seltener Vorgänge in SQL Server 2016).
Die Funktion STRING_SPLIT ist nicht verfügbar. Die Funktion STRING_SPLIT steht für den Kompatibilitätsgrad 130 oder höher zur Verfügung. Wenn der Kompatibilitätsgrad Ihrer Datenbank niedriger als 130 ist, kann SQL Server die STRING_SPLIT-Funktion nicht suchen und ausführen.

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.

Kompatibilitätsgradeinstellung 110 oder niedriger Kompatibilitätsgradeinstellung 120
Der ältere Abfrageoptimierer wird verwendet. SQL Server 2014 (12.x) schließt deutliche Verbesserungen der Komponente zum Erstellen und Optimieren von Abfrageplänen ein. Diese neue Funktion des Abfrageoptimierers ist nur bei Verwendung des Datenbank-Kompatibilitätsgrads 120 verfügbar. Damit diese Verbesserungen optimal genutzt werden können, sollten neue Datenbankanwendungen mit dem Datenbank-Kompatibilitätsgrad 120 entwickelt werden. Von früheren SQL Server-Versionen migrierte Anwendungen sollten sorgfältig daraufhin überprüft werden, ob die bisherige gute Leistung aufrechterhalten bzw. verbessert wird. Wird die Leistung beeinträchtigt, können Sie den Kompatibilitätsgrad der Datenbank auf 110 oder einen niedrigeren Wert festlegen, um die ältere Methodologie des Abfrageoptimierers zu nutzen.

Der Datenbank-Kompatibilitätsgrad 120 verwendet eine neue Kardinalitätsschätzung, die für moderne Data Warehousing- und OLTP-Arbeitsauslastungen optimiert ist. Bevor Sie den Datenbank-Kompatibilitätsgrad aufgrund von Leistungsproblemen auf 110 festlegen, sollten Sie die Empfehlungen im Abschnitt Abfragepläne des Artikels Neues in der Datenbank-Engine zu SQL Server 2014 (12.x) lesen.
Bei Kompatibilitätsgraden unter 120 wird die Spracheinstellung beim Konvertieren eines date-Werts in einen Zeichenfolgenwert ignoriert. Dieses Verhalten ist nur für den date-Typ spezifisch. Siehe Beispiel B im Abschnitt "Beispiele ". Die Spracheinstellung wird nicht ignoriert, wenn ein date-Wert in eine Zeichenfolge konvertiert wird.
Rekursive Verweise auf der rechten Seite einer EXCEPT-Klausel erzeugen eine Endlosschleife. Beispiel C im Abschnitt "Beispiele " veranschaulicht dieses Verhalten. Rekursive Verweise in einer EXCEPT Klausel generieren einen Fehler in Übereinstimmung mit dem ANSI SQL-Standard.
Der rekursive allgemeine Tabellenausdruck (Common Table Expression, CTE) lässt doppelte Spaltennamen zu. Der rekursive CTE lässt keine doppelten Spaltennamen zu.
Deaktivierte Trigger werden aktiviert, wenn die Trigger geändert werden. Das Ändern eines Triggers ändert nicht den Status (deaktiviert oder aktiviert) des Triggers.
Die OUTPUT INTO-Tabellenklausel ingoiert die IDENTITY_INSERT SETTING = OFF und lässt zu, dass explizite Werte eingefügt werden. Sie können keine expliziten Werte für eine Identitätsspalte in einer Tabelle einfügen, wenn IDENTITY_INSERT auf OFF festgelegt ist.
Wenn die Datenbankkapselung auf PARTIAL festgelegt ist, kann die Überprüfung des $action-Felds in der OUTPUT-Klausel einer MERGE-Anweisung einen Sortierungsfehler zurückgeben. Die von der $action-Klausel einer MERGE-Anweisung zurückgegebene Sortierung der Werte entspricht der Datenbanksortierung anstelle der Serversortierung. Es wird kein Sortierungskonfliktfehler zurückgegeben.
Durch eine SELECT INTO-Anweisung wird immer ein Singlethread-Einfügevorgang erstellt. Durch eine SELECT INTO-Anweisung kann ein paralleler Einfügevorgang erstellt werden. Beim Einfügen einer großer Anzahl von Zeilen kann die Leistung durch den parallelen Vorgang verbessert werden.

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.

Kompatibilitätsgradeinstellung 100 oder niedriger Kompatibilitätsgradeinstellung 110 oder höher
Common Language Runtime (CLR)-Datenbankobjekte werden mit Version 4 der CLR ausgeführt. Einige in Version 4 der CLR eingeführte Verhaltensänderungen werden jedoch vermieden. Weitere Informationen finden Sie unter Neues in der CLR-Integration. CLR-Datenbankobjekte werden mit Version 4 der CLR ausgeführt.
Die XQuery-Funktionen string-length und substring betrachten jedes Ersatzzeichen als zwei Zeichen. Die XQuery-Funktionen string-length und substring betrachten jedes Ersatzzeichen als ein Zeichen.
PIVOT ist in einer Abfrage für einen rekursiven allgemeinen Tabellenausdruck (Common Table Expression, CTE) zulässig. Die Abfrage gibt jedoch falsche Ergebnisse zurück, wenn mehrere Zeilen pro Gruppierung vorhanden sind. PIVOT ist in einer Abfrage für einen rekursiven allgemeinen Tabellenausdruck (Common Table Expression, CTE) nicht zulässig. Es wird ein Fehler zurückgegeben.
Der RC4-Algorithmus wird nur aus Gründen der Abwärtskompatibilität unterstützt. Neues Material kann nur mit RC4 oder RC4_128 verschlüsselt werden, wenn die Datenbank den Kompatibilitätsgrad 90 oder 100 besitzt. (Nicht empfohlen.) In SQL Server 2012 (11.x) kann mit RC4 oder RC4_128 verschlüsseltes Material in jedem Kompatibilitätsgrad entschlüsselt werden. Neues Material kann nicht mit RC4 oder RC4_128 verschlüsselt werden. Verwenden Sie stattdessen einen neueren Algorithmus, z. B. einen der AES-Algorithmen. In SQL Server 2012 (11.x) kann mit RC4 oder RC4_128 verschlüsseltes Material in jedem Kompatibilitätsgrad entschlüsselt werden.
Das Standardformat für CAST- und CONVERT-Vorgänge bei den Datentypen time und datetime2 ist 121, es sei denn, einer der Typen wird in einem berechneten Spaltenausdruck verwendet. Für berechnete Spalten ist das Standardformat 0. Dieses Verhalten wirkt sich auf berechnete Spalten aus, wenn sie erstellt werden und in Abfragen mit automatischer Parametrisierung oder in Einschränkungsdefinitionen verwendet werden.

Beispiel D im Abschnitt "Beispiele " zeigt den Unterschied zwischen den Formatvorlagen 0 und 121. Das oben beschriebene Verhalten wird nicht veranschaulicht. Weitere Informationen zu Datums - und Uhrzeitformatvorlagen finden Sie unter CAST und CONVERT.		 Unter dem Kompatibilitätsgrad 110 ist das Standardformat für CAST- und CONVERT-Vorgänge im Fall der Datentypen time und datetime2 immer 121. Basiert die Abfrage auf dem alten Verhalten, verwenden Sie einen Kompatibilitätsgrad unter 110, oder geben Sie in der betroffenen Abfrage explizit das Format 0 an.

Ein Update der Datenbank auf Kompatibilitätsgrad 110 ändert keine Benutzerdaten, die auf dem Datenträger gespeichert wurden. Sie müssen diese Daten entsprechend manuell korrigieren. Haben Sie beispielsweise SELECT INTO zum Erstellen einer Tabelle von einer Quelle verwendet, die einen Ausdruck für eine berechnete Spalte (oben beschrieben) beinhaltete, werden die Daten mit dem Format 0 anstelle der Definition der berechneten Spalte an sich gespeichert. Sie müssen diese Daten manuell aktualisieren, um sie an das Format 121 anzupassen.
Der Operator +(Addition) kann auf einen Operanden vom Typ "Datum", "Uhrzeit", "datetime2" oder "datetime" angewendet werden, wenn der andere Operand den Typ "datetime" oder "smalldatetime" aufweist. Der Versuch, den Additionsoperator auf einen Operanden vom Typ date, time, datetime2 oder datetimeoffset und einen Operanden vom Typ datetime oder smalldatetime anzuwenden, verursacht den Fehler 402.
Alle Spalten in Remotetabellen des Typs smalldatetime, auf die in einer partitionierten Ansicht verwiesen wird, werden als datetime zugeordnet. Entsprechende Spalten in lokalen Tabellen (in derselben Ordnungsposition in der Auswahlliste) müssen den Typ datetime aufweisen. Alle Spalten in Remotetabellen des Typs smalldatetime, auf die in einer partitionierten Ansicht verwiesen wird, werden als smalldatetime zugeordnet. Entsprechende Spalten in lokalen Tabellen (in derselben Ordnungsposition in der Auswahlliste) müssen den Typ smalldatetime aufweisen.

Nach dem Upgrade auf 110 schlägt die verteilte partitionierte Sicht wegen des Datentypkonflikts fehl. Sie können dieses Problem beheben, indem Sie den Datentyp in der Remotetabelle in datetime ändern oder den Kompatibilitätsgrad der lokalen Datenbank auf höchstens 100 festlegen.
Die SOUNDEX-Funktion implementiert die folgenden Regeln:

1) H oder W in Großbuchstaben werden beim Trennen von zwei Konsonanten ignoriert, welche die gleiche Zahl im SOUNDEX-Code aufweisen.

2) Wenn die ersten beiden Zeichen von character_expression die gleiche Zahl im SOUNDEX-Code aufweisen, werden beide Zeichen eingeschlossen. Wenn ein Satz nebeneinander liegender Konsonanten die gleiche Zahl im SOUNDEX-Code aufweist, werden andernfalls alle Zeichen außer dem ersten Zeichen ausgeschlossen.		 Die SOUNDEX-Funktion implementiert die folgenden Regeln:

1) Wenn H oder W in Großbuchstaben zwei Konsonanten trennt, welche die gleiche Zahl im SOUNDEX-Code aufweisen, wird der rechts stehende Konsonant ignoriert.

2) Wenn ein Satz nebeneinander liegender Konsonanten die gleiche Zahl im SOUNDEX-Code aufweist, werden andernfalls alle Zeichen außer dem ersten Zeichen ausgeschlossen.

Die zusätzlichen Regeln können dazu führen, dass die von der SOUNDEX Funktion berechneten Werte von den unter früheren Kompatibilitätsstufen berechneten Werten abweichen. Nach dem Upgrade auf Kompatibilitätsebene 110 müssen Sie möglicherweise die Indizes, Heaps oder CHECK-Einschränkungen neu erstellen, die die SOUNDEX Funktion verwenden. Weitere Informationen finden Sie unter SOUNDEX.
STRING_AGG ist ohne <order_clause> verfügbar. STRING_AGG ist mit einer optionalen <order_clause> verfügbar. Weitere Informationen finden Sie unter STRING_AGG (Transact-SQL).

Unterschiede zwischen Kompatibilitätsgrad 90 und Kompatibilitätsgrad 100

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

Kompatibilitätsgradeinstellung 90 Kompatibilitätsgradeinstellung 100 Mögliche Auswirkung
Die Einstellung QUOTED_IDENTIFIER wird immer auf "EIN" für mehrwertige Funktionen festgelegt, wenn sie unabhängig von der Einstellung auf Sitzungsebene erstellt werden. Die QUOTED IDENTIFIER-Sitzungseinstellung wird berücksichtigt, wenn Tabellenwertfunktionen mit mehreren Anweisungen erstellt werden. Medium
Wenn Sie eine Partitionsfunktion erstellen oder ändern, werden die Literale datetime und smalldatetime in der Funktion ausgewertet, wobei von US_Englisch als Spracheinstellung ausgegangen wird. Die aktuelle Spracheinstellung wird verwendet, um die Literale datetime und smalldatetime in der Partitionsfunktion auszuwerten. Medium
Die FOR BROWSE-Klausel ist in INSERT- und SELECT INTO-Anweisungen zulässig (und wird ignoriert). Die FOR BROWSE-Klausel ist in INSERT- und SELECT INTO-Anweisungen nicht zulässig. Medium
Volltextprädikate sind in der OUTPUT-Klausel zulässig. Volltextprädikate sind in der OUTPUT-Klausel nicht zulässig. Niedrig
CREATE FULLTEXT STOPLIST, ALTER FULLTEXT STOPLIST und DROP FULLTEXT STOPLIST werden nicht unterstützt. Die Systemstoppliste wird automatisch neuen Volltextindizes zugeordnet. CREATE FULLTEXT STOPLIST, ALTER FULLTEXT STOPLIST und DROP FULLTEXT STOPLIST werden unterstützt. Niedrig
MERGE wird nicht als reserviertes Schlüsselwort erzwungen. MERGE ist ein vollständig reserviertes Schlüsselwort. Die MERGE-Anweisung wird bei den Kompatibilitätsgraden 100 und 90 unterstützt. Niedrig
Die Verwendung des <dml_table_source>-Arguments der INSERT-Anweisung löst einen Syntaxfehler aus. Sie können die Ergebnisse einer OUTPUT-Klausel in einer geschachtelten INSERT-, UPDATE-, DELETE- oder MERGE-Anweisung aufzeichnen und diese Ergebnisse in eine Zieltabelle oder -sicht einfügen. Dies erfolgt über das <dml_table_source>-Argument der INSERT-Anweisung. Niedrig
Sofern NOINDEX nicht angegeben ist, führt DBCC CHECKDB oder DBCC CHECKTABLE sowohl physische als auch logische Konsistenzprüfungen für eine einzelne Tabelle oder indizierte Ansicht und alle zugehörigen, nicht gruppierten Indizes und XML-Indizes aus. Räumliche Indizes werden nicht unterstützt. Sofern NOINDEX nicht angegeben ist, führt DBCC CHECKDB oder DBCC CHECKTABLE sowohl physische als auch logische Konsistenzprüfungen für eine einzelne Tabelle und alle zugehörigen, nicht gruppierten Indizes aus. Allerdings werden für XML-Indizes, räumliche Indizes und indizierte Sichten standardmäßig nur physische Konsistenzprüfungen ausgeführt.

Bei Angabe von WITH EXTENDED_LOGICAL_CHECKS werden logische Konsistenzprüfungen an indizierten Ansichten, XML-Indizes und räumlichen Indizes (sofern vorhanden) ausgeführt. Standardmäßig werden physische Konsistenzprüfungen vor den logischen Konsistenzprüfungen ausgeführt. Wenn NOINDEX ebenfalls angegeben ist, werden nur die logischen Prüfungen ausgeführt.		 Niedrig
Wenn eine OUTPUT-Klausel mit einer DML-Anweisung (Data Manipulation Language, Datenbearbeitungssprache) verwendet wird und während der Ausführung der Anweisung ein Laufzeitfehler auftritt, wird die gesamte Transaktion beendet, und es wird ein Rollback für sie ausgeführt. Wenn eine OUTPUT-Klausel mit einer DML-Anweisung (DML = Data Manipulation Language, Datenbearbeitungssprache) verwendet wird und während der Ausführung der Anweisung ein Laufzeitfehler auftritt, hängt das Verhalten von der SET XACT_ABORT-Einstellung ab. Wenn SET XACT_ABORT auf OFF festgelegt ist, führt ein Anweisungsabbruchfehler, der von der DML-Anweisung bei Verwendung der OUTPUT-Klausel generiert wird, zum Abbruch der Anweisung. Die Ausführung des Batches wird jedoch fortgesetzt, und es wird kein Rollback für die Transaktion ausgeführt. Wenn SET XACT_ABORT auf ON festgelegt ist, bewirken alle Laufzeitfehler, die von der DML-Anweisung bei Verwendung der OUTPUT-Klausel generiert werden, dass der Batch abgebrochen und für die Transaktion ein Rollback ausgeführt wird. Niedrig
CUBE und ROLLUP werden nicht als reservierte Schlüsselwörter erzwungen. CUBE und ROLLUP sind reservierte Schlüsselwörter innerhalb der GROUP BY-Klausel. Niedrig
Für Elemente des anyType-XML-Datentyps wird die strict-Überprüfung angewendet. Für Elemente des anyType-Datentyps wird die Lax-Überprüfung angewendet. Weitere Informationen finden Sie unter Platzhalterkomponenten und Inhaltsüberprüfung. Niedrig
Die speziellen Attribute xsi:nil und xsi:type können durch DML-Anweisungen nicht abgefragt oder geändert werden.

Dies hat zur Folge, dass /e/@xsi:nil fehlschlägt, während /e/@* die Attribute xsi:nil und xsi:type ignoriert. /e gibt jedoch die Attribute xsi:nil und xsi:type aus Gründen der Konsistenz mit SELECT xmlCol zurück, sogar wenn xsi:nil = "false".		 Die speziellen Attribute xsi:nil und xsi:type werden als reguläre Attribute gespeichert und können abgefragt und geändert werden.

Beispielsweise werden bei der Ausführung der Abfrage SELECT x.query('a/b/@*') alle Attribute einschließlich xsi:nil und xsi:type zurückgegeben. Zum Ausschließen dieser Typen in der Abfrage müssen Sie @* durch @*[namespace-uri(.) != "insert xsi namespace uri" und nicht (local-name(.) = "type" oder local-name(.) ="nil". ersetzen.		 Niedrig
Eine benutzerdefinierte Funktion, die einen XML-Konstantenzeichenfolgenwert in einen SQL Server-Datetime-Typ konvertiert, wird als deterministisch markiert. Eine benutzerdefinierte Funktion, die einen XML-Konstantenzeichenfolgenwert in einen SQL Server-Datetime-Typ konvertiert, ist als nicht deterministisch gekennzeichnet. Niedrig
Die XML-Datentypen „union“ und „list“ werden nicht vollständig unterstützt. Die XML-Datentypen "union" und "list" werden vollständig unterstützt, einschließlich der folgenden Funktionalität:

"union" von "list"

"union" von "union"

Liste der atomaren Typen

"list" von "union"		 Niedrig
Die für eine xQuery-Methode erforderlichen SET-Optionen werden nicht überprüft, wenn die Methode in einer Sicht oder Inline-Tabellenwertfunktion enthalten ist. Die für eine xQuery-Methode erforderlichen SET-Optionen werden überprüft, wenn die Methode in einer Sicht oder Inline-Tabellenwertfunktion enthalten ist. Wenn die SET-Optionen der Methode nicht ordnungsgemäß festgelegt sind, wird ein Fehler ausgegeben. Niedrig
XML-Attributwerte, die Zeilenendezeichen enthalten (Wagenrücklauf und Zeilenvorschub) werden gemäß dem XML-Standard nicht normalisiert. Somit werden anstelle eines einzelnen Zeilenvorschubzeichens beide Zeichen zurückgegeben. XML-Attributwerte, die Zeilenendezeichen enthalten (Wagenrücklauf und Zeilenvorschub) werden gemäß dem XML-Standard normalisiert. Somit werden alle Zeilenumbrüche in extern analysierten Entitäten (einschließlich der Dokumententität) bei Eingabe normalisiert, indem sowohl die aus zwei Zeichen bestehende Folge #xD #xA als auch alle Vorkommnisse von #xD, auf die nicht #xA folgt, in das einzelne Zeichen #xA übersetzt werden.

Anwendungen, die mithilfe von Attributen Zeichenfolgenwerte transportieren, die Zeilenendezeichen enthalten, erhalten diese Zeichen nicht wie gesendet zurück. Um die Normalisierung zu verhindern, müssen für die Codierung aller Zeilenendezeichen numerische XML-Zeichenentitäten verwendet werden.		 Niedrig
Die Spalteneigenschaften ROWGUIDCOL und IDENTITY können als Einschränkung falsch benannt werden. Beispielsweise wird die Anweisung CREATE TABLE T (C1 int CONSTRAINT MyConstraint IDENTITY) ausgeführt, doch wird der Einschränkungsname nicht beibehalten und ist für den Benutzer nicht verfügbar. Die Spalteneigenschaften ROWGUIDCOL und IDENTITY können nicht als Einschränkung benannt werden. Der Fehler 156 wird zurückgegeben. Niedrig
Die Aktualisierung von Spalten mithilfe einer bidirektionalen Zuweisung, wie z.B. UPDATE T1 SET @v = column_name = <expression>, kann zu unerwarteten Ergebnissen führen, weil während der Ausführung der Anweisung anstelle des Anfangswerts der aktuelle Wert der Variablen in anderen Klauseln verwendet werden kann, wie z.B. in der WHERE- und ON-Klausel. Dies kann dazu führen, dass sich die Bedeutungen der Prädikate für jede Zeile einzeln unvorhersehbar ändern.

Dieses Verhalten gilt nur, wenn der Kompatibilitätsgrad auf 90 festgelegt ist.		 Die Aktualisierung von Spalten mithilfe einer zweiseitigen Zuweisung liefert die erwarteten Ergebnisse, weil während der Ausführung der Anweisung nur auf den Anweisungsanfangswert der Spalte zugegriffen wird. Niedrig
Variable Zuordnung ist in einer Anweisung zulässig, die einen Operator auf oberster Ebene UNION enthält, aber unerwartete Ergebnisse zurückgibt. Weitere Informationen finden Sie in Beispiel E. Die Variablenzuweisung ist in einer Anweisung mit einem UNION-Operator auf der obersten Ebene nicht zulässig. Der Fehler 10734 wird zurückgegeben. Suchen Sie in Beispiel E nach einem vorgeschlagenen erneuten Schreibvorgang. Niedrig
Die ODBC-Funktion <legacyBold>{fn CONVERT ()}</legacyBold> verwendet das Standarddatumsformat der Sprache. Bei einigen Sprachen lautet das Standardformat YDM. Dies kann zu Konvertierungsfehlern führen, wenn CONVERT() mit anderen Funktionen kombiniert wird, die ein YMD-Format erwarten, wie z.B. {fn CURDATE()}. Die ODBC-Funktion {fn CONVERT()} verwendet für die Konvertierung in die ODBC-Datentypen SQL_TIMESTAMP, SQL_DATE, SQL_TIME, SQLDATE, SQL_TYPE_TIME und SQL_TYPE_TIMESTAMP das sprachenunabhängige XMD-Format im Format 121. Niedrig
Systeminterne Datetime-Werte, z DATEPART . B. keine Zeichenfolgeneingabewerte, müssen gültige Datetime-Literale sein. SELECT DATEPART (year, '2007/05-30') wird beispielsweise erfolgreich kompiliert. Für systeminterne datetime-Funktionen wie z.B. DATEPART ist es erforderlich, dass Zeichenfolgeneingabewerte gültige datetime-Literale sind. Fehler 241 wird zurückgegeben, wenn ein ungültiges datetime-Literal verwendet wird. Niedrig
Nachfolgende Leerzeichen, die im ersten Eingabeparameter der REPLACE-Funktion angegeben sind, werden gekürzt, wenn der Parameter vom Typ Char ist. In der Anweisung SELECT '<' + REPLACE(CONVERT(char(6), 'ABC '), ' ', 'L') + '>'wird der Wert 'ABC ' beispielsweise fälschlicherweise als 'ABC'. Nachstehende Leerzeichen werden immer beibehalten. Verwenden Sie bei Anwendungen, die auf dem vorherigen Verhalten der Funktion basieren, die RTRIM Funktion, wenn Sie den ersten Eingabeparameter für die Funktion angeben. Die folgende Syntax reproduzieren beispielsweise das SQL Server 2005-Verhalten: SELECT '<' + REPLACE(RTRIM(CONVERT(char(6), 'ABC ')), ' ', 'L') + '>'. Niedrig

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.

Kompatibilitätsgradeinstellung Reservierte Schlüsselwörter
130 Bestimmung erforderlich.
120 Keine.
110 WITHIN GROUP, , TRY_CONVERTSEMANTICKEYPHRASETABLE, , SEMANTICSIMILARITYDETAILSTABLESEMANTICSIMILARITYTABLE
100 CUBE, MERGEROLLUP
90 EXTERNAL, , PIVOTUNPIVOT, , REVERTTABLESAMPLE

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:

TimeStyle0 TimeStyle121 Datetime2Style0 Datetime2Style121
3:15PM 15:15:35.8100000 7. Juni 2011, 15:15 Uhr 2011-06-07 15:15:35.8130000

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