ALTER DATABASE (Transact-SQL): Kompatibilitätsgrad

Gilt für: SQL Server (alle unterstützten Versionen) 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 }

Hinweis

Informationen zum Anzeigen der Transact-SQL-Syntax für SQL Server 2014 oder früher finden Sie unter Dokumentation zu früheren Versionen.

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
SQL Server 2022 (16.x) Preview 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
Azure SQL-Datenbank 12 150 160, 150, 140, 130, 120, 110, 100
Verwaltete Azure SQL-Datenbank-Instanz 12 150 160, 150, 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,5 100 100, 90, 80
SQL Server 2008 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 werden nach einem direkten Upgrade erwartet:

  • War der Kompatibilitätsgrad einer Benutzerdatenbank vor dem Upgrade 100 oder höher, wird er nach dem Upgrade beibehalten.
  • War der Kompatibilitätsgrad einer Benutzerdatenbank vor dem Upgrade 90, wird er auf 100 gesetzt, was dem niedrigsten unterstützten Kompatibilitätsgrad in SQL Server 2017 (14.x) entspricht.
  • Der Kompatibilitätsgrad der Datenbanken „tempdb“, „model“, „msdb“ und „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.

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;

Hinweise für Azure SQL-Datenbank

Seit November 2019 ist der Standardkompatibilitätsgrad für neu erstellte Datenbanken in Azure SQL-Datenbank gleich „150“. Microsoft passt bei vorhandenen Datenbanken den Datenbank-Kompatibilitätsgrad nicht an. Kunden können diesen nach Ihren eigenen Bedürfnissen anpassen. Microsoft empfiehlt Kunden dringend, ein Upgrade auf den aktuellen Kompatibilitätsgrad durchzuführen, um von den neuesten Verbesserungen bei der Abfrageoptimierung profitieren zu können.

Weitere Einzelheiten zur Bewertung der Leistungsunterschiede bei Ihren wichtigsten Abfragen zwischen zwei Kompatibilitätsgraden in Azure SQL-Datenbank finden Sie unter Verbesserte Abfrageleistung bei Kompatibilitätsgrad 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.

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

SELECT SERVERPROPERTY('ProductVersion');

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

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. Für eine ältere Version von SQL Server (z. B. SQL Server 2008) kann daher ein Upgrade auf SQL Server oder Azure SQL-Datenbank (einschließlich Azure SQL Managed Instance) durchgeführt 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 Kompatibilitätsgrad der Datenbank 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.

  • Breaking Changes, die in einer bestimmten SQL Server-Version eingeführt wurden, werden möglicherweise nicht durch den Kompatibilitätsgrad 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 wichtige Änderung, die durch den Kompatibilitätsgrad geschützt wird, ist eine implizite Konvertierung vom Datentyp „DateTime“ in den Datentyp „DateTime2“. 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 vom Kompatibilitätsgrad erzeugt die Anweisung EXEC sp_dboption 'AdventureWorks2016', 'autoshrink', 'FALSE'; den Fehler 2812 (gespeicherte Prozedur „sp_dboption“ konnte nicht gefunden werden).

    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. Anwendungsbereich: SQL Server (ab SQL Server 2016 (13.x)) und 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

    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) Vorschau)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 einer bestimmten Anzahl von 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 Grads an Parallelismus (MAXDOP) auf Instanz-, Datenbank-, Abfrage- oder Workloadebenen finden Sie unter Konfigurieren des maximalen Grads an Parallelismus Serverkonfigurationsoption 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 Columnstore-Indizes möglicherweise aufgrund des Mehraufwands für OLTP, fehlender Unterstützung durch den Hersteller oder anderer Einschränkungen nicht unten. 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.
Abfragen im Zeilenmodus, die nicht genügend Speicherzuweisungen anfordern, was zu einem Überlauf auf Datenträger führt, haben möglicherweise weiterhin Probleme mit aufeinanderfolgenden Ausführungen. Abfragen im Zeilenmodus, die nicht genügend Arbeitsspeicherzuweisungen anfordern, was zu einem Überlauf auf Datenträger führt, weisen bei aufeinanderfolgenden Ausführungen möglicherweise eine Leistungssteigerung auf. Weitere Informationen finden Sie unter Feedback zur Speicherzuweisung im Zeilenmodus.
Abfragen im Zeilenmodus, die eine übermäßige Speicherzuweisung anfordern, was zu Parallelitätsproblemen führt, haben möglicherweise weiterhin Probleme mit aufeinanderfolgenden Ausführungen. Abfragen im Batchmodus, die eine übermäßige Speicherzuweisung anfordern, was zu Parallelitätsproblemen führt, weisen bei aufeinanderfolgenden Ausführungen möglicherweise eine verbesserte Parallelität auf. 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.
Abfragen im Batchmodus, die nicht genügend Arbeitsspeicherzuweisungen anfordern, was zu einem Überlauf der Datenträger führt, haben möglicherweise weiterhin Probleme mit aufeinanderfolgenden Ausführungen. Abfragen im Batchmodus, die nicht genügend Arbeitsspeicherzuweisungen anfordern, was zu einem Überlauf der Datenträger führt, weisen bei aufeinanderfolgenden Ausführungen möglicherweise eine Leistungssteigerung auf. 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.
Abfragen im Batchmodus, die eine übermäßige Arbeitsspeicherzuweisung anfordern, die zu Parallelitätsproblemen führt, haben möglicherweise weiterhin Probleme mit aufeinanderfolgenden Ausführungen. Abfragen im Batchmodus, die eine übermäßige Arbeitsspeicherzuweisung anfordern, die zu Parallelitätsproblemen führt, weisen bei aufeinanderfolgenden Ausführungen möglicherweise eine verbesserte Parallelität auf. 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 Join-Eingaben falsch sind, wird möglicherweise ein ungeeigneter JOIN-Algorithmus ausgewählt. 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 äußere erstellte Join-Eingaben falsch sind, wird möglicherweise ein ungeeigneter Join-Algorithmus 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 mit mehreren Anweisungen verfügen nicht über eine 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. Beachten Sie, dass dieses Verhalten nur für den date-Typ spezifisch ist. Siehe Beispiel B im Abschnitt „Beispiele“ weiter unten. 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. In Beispiel C im nachfolgenden Abschnitt „Beispiele“ wird dieses Verhalten veranschaulicht. Rekursive Verweise in einer EXCEPT-Klausel generieren gemäß dem ANSI SQL-Standard einen Fehler.
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.

In Beispiel D im nachfolgenden Abschnitt „Beispiele“ wird der Unterschied zwischen den Formaten 0 und 121 veranschaulicht. Das oben beschriebene Verhalten wird nicht veranschaulicht. Weitere Informationen zu Datums- und Zeitformaten 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 date, time, datetime2 oder datetimeoffset 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 führen möglicherweise dazu, dass die von der SOUNDEX-Funktion berechneten Werte sich von den unter früheren Kompatibilitätsgraden berechneten Werten unterscheiden. Möglicherweise sind die Indizes, Heaps oder CHECK-Einschränkungen, welche die SOUNDEX-Funktion verwenden, nach dem Upgrade auf Kompatibilitätsgrad 110 erneut zu erstellen. 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_IDENTIFER ist für Tabellenwertfunktionen mit mehreren Anweisungen immer auf ON festgelegt, wenn diese erstellt werden, unabhängig von der Einstellung auf Sitzungsebene. 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 eine XML-Zeichenfolgenkonstante in einen SQL Server-datetime-Typ konvertiert, wird als deterministisch gekennzeichnet. Eine benutzerdefinierte Funktion, die eine XML-Zeichenfolgenkonstante in einen SQL Server-datetime-Typ konvertiert, wird 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, die nicht von #xA gefolgt werden, 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
Die Variablenzuweisung ist in einer Anweisung mit einem UNION-Operator auf der obersten Ebene zulässig, kann jedoch unerwartete Ergebnisse zurückgeben. 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
Für systeminterne datetime-Funktionen, wie z. B. DATEPART, ist es nicht erforderlich, dass Zeichenfolgeneingabewerte gültige datetime-Literale sind. 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
Nachstehende Leerzeichen, die im erstem Eingabeparameter der REPLACE-Funktion angegeben werden, werden gekürzt, wenn der Parameter den Typ „Char“ aufweist. In der folgenden Anweisung wird der Wert 'ABC ' beispielsweise fälschlicherweise als 'ABC' ausgewertet: SELECT '<' + REPLACE(CONVERT(char(6), 'ABC '), ' ', 'L') + '>'. Nachstehende Leerzeichen werden immer beibehalten. Für Anwendungen, die sich auf das frühere Verhalten der Funktion stützen, verwenden Sie die RTRIM-Funktion bei der Angabe der ersten Eingabeparameter der Funktion. Die folgende Syntax reproduziert das Verhalten von SQL Server 2005: 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_CONVERT, SEMANTICKEYPHRASETABLE, SEMANTICSIMILARITYDETAILSTABLE, SEMANTICSIMILARITYTABLE
100 CUBE, MERGE, ROLLUP
90 EXTERNAL, PIVOT, UNPIVOT, REVERT, TABLESAMPLE

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 der Kompatibilitätsgrad der BeispieldatenbankAdventureWorks2019 auf 150 festgelegt (Standard für SQL Server 2019 (15.x)).

ALTER DATABASE AdventureWorks2019
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 AdventureWorks2012
SET compatibility_level = 110;
GO
USE AdventureWorks2012;
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;

Nächste Schritte

Weitere Informationen zu Datenbank-Kompatibilitätsgraden und verwandten Konzepten finden Sie in den folgenden Artikeln: