Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Gilt für:SQL Server
Azure SQL Database
Azure SQL Managed Instance
Die Kompatibilitätszertifizierung ermöglicht es Unternehmen, für eine lokale, cloudbasierte oder edgebasierte SQL Server-Datenbank ein Upgrade vorzunehmen und diese zu erneuern, um Risiken im Zusammenhang mit der Anwendungskompatibilität zu vermeiden.
SQL Server und Azure SQL-Datenbank (sowie Azure SQL Managed Instance) basieren auf derselben Datenbank-Engine. Mithilfe dieser gemeinsam verwendeten Datenbank-Engine kann eine Benutzerdatenbank problemlos von einer lokalen SQL Server-Instanz zu Azure SQL-Datenbank migriert werden. Der Anwendungscode wird dabei in der Datenbank als Transact-SQL ausgeführt und funktioniert weiterhin so wie auf dem Quellsystem.
Bei einem neuen Release von SQL Server wird der Standardkompatibilitätsgrad auf die Version der Datenbank-Engine festgelegt. Der Kompatibilitätsgrad vorheriger Versionen wird jedoch beibehalten, um die Kompatibilität mit vorhandenen Anwendungen sicherzustellen. Diese Kompatibilitätsmatrix finden Sie unter Argumente. Eine Anwendung, die für eine bestimmte SQL Server-Version zertifiziert wurde, wurde daher für den Standardkompatibilitätsgrad dieser Version zertifiziert.
In SQL Server 2016 (13.x) wurde beispielsweise für den Datenbank-Kompatibilitätsgrad der Standardwert 130 verwendet. Da Kompatibilitätsgrade bestimmte Transact-SQL-Verhalten in Bezug auf Funktionen und auf die Abfrageoptimierung erzwingen, war eine Datenbank, die für SQL Server 2016 (13.x) zertifiziert war, implizit auch für den Datenbank-Kompatibilitätsgrad 130 zertifiziert. Eine solche Datenbank kann unverändert in einer neueren Version von SQL Server (z. B. SQL Server 2019 (15.x)) und Azure SQL-Datenbank verwendet werden, solange der Datenbank-Kompatibilitätsgrad 130 beibehalten wird.
Dies ist ein grundlegendes Prinzip des Betriebsmodells Continuous Integration in Microsoft Azure SQL-Datenbank. Die Datenbank-Engine wird in Azure kontinuierlich verbessert und um Upgrades ergänzt. Da allerdings vorhandene Datenbanken ihren aktuellen Kompatibilitätsgrad beibehalten, funktionieren sie auch nach dem Upgrade der zugrunde liegenden Datenbank-Engine wie vorgesehen.
So erfolgt auch die Zertifizierung von SharePoint Server 2016 und SharePoint Server 2019 für SQL Server und Azure SQL Managed Instance. Sie können jedes SQL Server-Datenbankmodul bereitstellen, das die unterstützten Datenbankkompatibilitätsstufen für diese SharePoint Server-Versionen verwendet. Weitere Informationen finden Sie unter Hardware- und Softwareanforderungen für SharePoint Server 2016 und Hardware- und Softwareanforderungen für SharePoint Server 2019.
Verwalten von Upgraderisiken mithilfe der Kompatibilitätszertifizierung
Die Kompatibilitätszertifizierung ist eine Methode, die sich gut zur Datenbankmodernisierung eignet. Wenn Entwickler auf Der Grundlage der Kompatibilitätsstufe zertifizieren, legen Sie die technischen Anforderungen für eine Anwendung fest, die in SQL Server und Azure SQL-Datenbank unterstützt werden soll, entkoppeln Sie den Anwendungslebenszyklus jedoch vom Lebenszyklus der Datenbankplattform. Unternehmen können auf diese Weise sicherstellen, dass die SQL Server-Datenbank-Engine entsprechend den Lebenszyklusrichtlinien immer auf dem neuesten Stand ist. Dazu werden neue Skalierbarkeits- und Leistungsoptimierungen eingesetzt, die codeunabhängig sind. Vernetzte Anwendungen behalten darüber hinaus durch Upgrades ihren Funktionsstatus bei.
Die wichtigsten Risikofaktoren für jedes Upgrade sind die Möglichkeit, die Funktionalität negativ zu beeinträchtigen und Leistungsprobleme. Mit der Kompatibilitätszertifizierung können die folgenden Upgraderisiken problemlos gesteuert werden:
Wenn sich das Transact-SQL-Verhalten ändert, muss die Anwendung rezertifiziert werden, damit sie richtig funktioniert. Die Einstellung Datenbank-Kompatibilitätsgrad bietet Abwärtskompatibilität mit früheren Versionen von SQL Server. Dies gilt allerdings ausschließlich für die angegebene Datenbank und nicht für den gesamten Server. Mit einem unveränderten Datenbank-Kompatibilitätsgrad wird sichergestellt, dass vorhandene Anwendungsabfragen vor und nach einem Upgrade der Datenbank-Engine weiterhin dasselbe Verhalten aufweisen. Weitere Informationen zum Transact-SQL-Verhalten und zu Kompatibilitätsgraden finden Sie unter Verwenden von Kompatibilitätsgraden für Abwärtskompatibilität.
Im Zusammenhang mit der Leistung können Abweichungen bei Abfrageplänen zwischen verschiedenen Datenbank-Engine-Versionen auftreten, da in jeder neuen Version der Abfrageoptimierer verbessert wird. Abfrageplanunterschiede im Umfang eines Upgrades werden in der Regel in Risiken übersetzt, wenn es möglich ist, dass einige Änderungen für eine bestimmte Abfrage oder Arbeitsauslastung nachteilig sein könnten. Dieses Risiko ist in der Regel der Grund für eine Rezertifizierung der Anwendung. Dies kann zu einer Verzögerung von Upgrades und zu Lebenszyklus- und Supportproblemen führen kann.
Verbesserungen des Abfrageoptimierers werden durch den Standardkompatibilitätsgrad eines neuen Release (d. h. der höchsten verfügbaren Kompatibilitätsstufe für jede neue Version) eingeschränkt, um die Upgraderisiken zu verringern. Die Kompatibilitätszertifizierung umfasst den Abfrageplan-Shape-Schutz: Die Aufrechterhaltung einer Datenbankkompatibilitätsstufe as-is, unmittelbar nach einem Upgrade des Datenbankmoduls, übersetzt sich in die Verwendung des gleichen Abfrageoptimierungsmodells in der neuen Version wie vor dem Upgrade, und das Abfrageplan-Shape sollte sich nicht ändern.
Weitere Informationen finden Sie im Abschnitt Gründe für die Form des Abfrageplans dieses Artikels.
Weitere Informationen zu Kompatibilitätsgraden finden Sie unter Verwenden von Kompatibilitätsgraden für Abwärtskompatibilität.
Aktualisieren Sie bei vorhandenen Anwendungen, die bereits für einen bestimmten Kompatibilitätsgrad zertifiziert wurden, die SQL Server-Datenbank-Engine, und behalten Sie den vorherigen Datenbank-Kompatibilitätsgrad bei. In diesem Szenario muss keine Anwendung erneut zertifiziert werden. Weitere Informationen finden Sie weiter unten in diesem Artikel unter Kompatibilitätsgrade und Upgrades der Datenbank-Engine.
Für neue Entwicklungsarbeiten oder wenn eine vorhandene Anwendung neue Features wie intelligente Abfrageverarbeitung und einige neue Transact-SQL benötigt, planen Sie ein Upgrade der Datenbankkompatibilitätsstufe auf die neueste verfügbare Sql Server-Version, und beglaubigen Sie Ihre Anwendung erneut, um mit dieser Kompatibilitätsstufe zu arbeiten. Ausführlichere Informationen zu einem Upgrade des Datenbank-Kompatibilitätsgrads finden Sie unter Bewährte Methoden zum Aktualisieren des Datenbank-Kompatibilitätsgrads.
Gründe für die Form des Abfrageplans
Die Abfrageplanform bezieht sich auf die visuelle Darstellung der verschiedenen Operatoren, die einen Abfrageplan bilden. Dies schließt Operatoren wie Suchvorgänge, Scans, Joins und Sortierungen sowie die Verbindungen zwischen diesen ein, die den Datenfluss und die Reihenfolge der Vorgänge angeben, die ausgeführt werden müssen, um das gewünschte Resultset zu erzeugen. Die Abfrageplanform wird durch den Abfrageoptimierer bestimmt.
Um die Abfrageleistung während eines Upgrades vorhersagbar zu halten, besteht eines der grundlegenden Ziele darin sicherzustellen, dass dieselbe Abfrageplanform verwendet wird. Dies kann erreicht werden, indem der Datenbank-Kompatibilitätsgrad nicht unmittelbar nach einem Upgrade geändert wird, auch wenn die zugrundeliegende Datenbank-Engine über unterschiedliche Versionen verfügt. Wenn im Ökosystem der Abfrageausführung nichts anderes geändert wird, z. B. bedeutende Änderungen an verfügbaren Ressourcen oder die Datenverteilung in den zugrundeliegenden Daten, sollte die Leistung einer Abfrage unverändert bleiben.
Die Beibehaltung des Shapes eines Abfrageplans ist jedoch nicht der einzige Faktor, der nach einem Upgrade Leistungsauswirkungen haben kann. Wenn Sie die Datenbank in ein neueres Datenbankmodul verschieben und auch Umgebungsänderungen vornehmen, können Sie Faktoren einführen, die sich unmittelbar auf die Leistung einer Abfrage auswirken, auch wenn der Abfrageplan dasselbe Shape in allen Versionen beibehält. Diese Umgebungsänderungen können das neue Datenbankmodul mit mehr oder weniger Arbeitsspeicher und CPU-Ressourcen enthalten, Änderungen an Server- oder Datenbankkonfigurationsoptionen oder Änderungen an der Datenverteilung, die sich auf die Erstellung eines Abfrageplans auswirken. Daher ist es wichtig zu verstehen, dass das Beibehalten des Datenbank-Kompatibilitätsgrads vor Änderungen in der Form des Abfrageplans schützt, jedoch keinen Schutz vor anderen die Abfrageleistung beeinflussenden Umgebungsaspekten bietet, von denen einige vom Benutzer initiiert werden.
Weitere Informationen finden Sie im Handbuch zur Architektur der Abfrageverarbeitung.
Vorteile der Kompatibilitätszertifizierung
Die Datenbankzertifizierung auf Grundlage der Kompatibilität ist in mehrfacher Hinsicht sinnvoller als eine Zertifizierung, die auf Versionsbezeichnungen basiert:
Entkopplung der Anwendungszertifizierung von der Plattform: Für Anwendungen, die Transact-SQL-Abfragen ausführen müssen, sind wegen der gemeinsam verwendeten Datenbank-Engine keine unterschiedlichen Zertifizierungsprozesse für Azure und lokale Umgebungen erforderlich.
Verringerung der Upgraderisiken: Bei der Modernisierung von Datenbankplattformen können die Upgradezyklen für die Anwendungs- und Datenbankebene getrennt werden, was zu weniger Ausfallzeiten und einem verbesserten Change Management führt.
Upgrade ohne Codeänderungen: Bei einem Upgrade auf eine neue Version von SQL Server oder Azure SQL-Datenbank sind keine Codeänderungen erforderlich, wenn der Kompatibilitätsgrad und das Quellsystem beibehalten werden. Eine erneute Zertifizierung ist erst erforderlich, wenn die Anwendung Verbesserungen nutzen muss, die nur von höheren Datenbank-Kompatibilitätsgraden bereitgestellt werden.
Verbesserte Verwaltbarkeit und Skalierbarkeit: Eine Anpassung von Anwendungen ist nicht erforderlich. Außerdem werden Verbesserungen nicht durch den Datenbank-Kompatibilitätsgrad eingeschränkt. In SQL Server sind dies beispielsweise:
Umfassende Verbesserungen bei Überwachung und Problembehandlung mit neuen dynamischen Systemverwaltungsansichten, erweiterten Ereignissen und automatischer Optimierung.
Verbesserte Skalierbarkeit, z. B. mit automatischer Soft-NUMA- oder beschleunigter Datenbankwiederherstellung oder speicheroptimierten tempdb-Metadaten.
Neue Datenbanken werden weiterhin auf den Standardkompatibilitätsgrad der Datenbank-Engine-Version festgelegt. Wenn jedoch eine Datenbank von einer früheren SQL Server-Version auf eine neue Version von SQL Server oder Azure SQL-Datenbank wiederhergestellt oder angefügt wird, behält die Datenbank den vorhandenen Kompatibilitätsgrad bei.
Überprüfen der unterstützten Kompatibilitätsstufe
Wenn Sie eine Datenbank auf eine neue Version von SQL Server oder Azure SQL-Datenbank aktualisieren möchten, müssen Sie vorher überprüfen, ob der Datenbank-Kompatibilitätsgrad noch unterstützt wird. Die Unterstützungsmatrix auf Datenbankkompatibilitätsebene kann in Argumenten der ALTER DATABASE-Kompatibilitätsebene angezeigt werden.
Beim Ausführen eines Upgrades für eine Datenbank, deren Kompatibilitätsgrad unterhalb des zulässigen Grads liegt (beispielsweise 90 in der Standardeinstellung in SQL Server 2005 (9.x)), wird die Datenbank automatisch auf den niedrigsten zulässigen Kompatibilitätsgrad (100) festgelegt.
Um die aktuelle Kompatibilitätsstufe zu ermitteln, fragen Sie die compatibility_level
Spalte in sys.databases ab.
Kompatibilitätsgrade und Upgrades der Datenbank-Engine
Um das Datenbankmodul auf die neueste Version zu aktualisieren, während die Datenbankkompatibilitätsebene beibehalten wird, die vor dem Upgrade und dessen Unterstützungsstatus vorhanden war, sollten Sie eine statische Überprüfung des Anwendungsoberflächenbereichs des Anwendungscodes in der Datenbank durchführen (Programmierbarkeitsobjekte wie gespeicherte Prozeduren, Funktionen, Trigger und andere) und in der Anwendung (mithilfe einer Workloadablaufverfolgung, die den von der Anwendung gesendeten dynamischen Code erfasst).
Dies kann ganz einfach mithilfe der SQL Server-Migrationskomponente in SQL Server Management Studio erfolgen. Das Fehlen von Fehlern in der Berichtsausgabe, bei fehlenden oder inkompatiblen Funktionen, schützt die Anwendung vor allen funktionalen Regressionen in der neuen Zielversion. Wenn Änderungen erforderlich sind, um sicherzustellen, dass Ihre Datenbank in der neuen Version funktioniert, können Sie mit dem Tool ermitteln, wo Änderungen erforderlich sind und welche Problemumgehungen verfügbar sind.
Diese funktionale Überprüfung ist besonders wichtig, wenn eine Datenbank aus einer älteren Version (z. B. SQL Server 2008 R2 (10.50.x) oder SQL Server 2012 (11.x)) in eine neue Version von SQL Server oder Azure SQL-Datenbank verschoben wird, da Ihr Anwendungscode möglicherweise nicht mehr Transact-SQL verwendet, die nicht durch datenbankkompatibilitätsstufe geschützt ist. Wenn Sie jedoch von einer neueren Version (z. B. SQL Server 2016 (13.x)) zu SQL Server 2022 (16.x) oder Azure SQL-Datenbank wechseln, gibt es keine nicht mehr mehr verfügbaren Transact-SQL, um sich Gedanken zu machen. Weitere Informationen zu nicht mehr unterstützten Versionen von Transact-SQL finden Sie unter Verwenden des Kompatibilitätsgrads für Abwärtskompatibilität.
Hinweis
Die SQL Server-Migrationskomponente unterstützt die Datenbankkompatibilitätsebene 100 und höher. SQL Server 2005 (9.x) ist als Quellversion ausgeschlossen.
Es wird empfohlen, einige minimale Tests durchzuführen, um den Erfolg eines Upgrades zu überprüfen, während die vorherige Datenbankkompatibilitätsstufe beibehalten wird. Sie sollten bestimmen, was „minimale Tests“ im Zusammenhang Ihrer Anwendung und Ihres Szenarios bedeutet.
Abfrageplanschutz
Microsoft bietet Schutz für eine Abfrageplanform, wenn Folgendes zutrifft:
Die neue SQL Server-Version (Ziel) wird auf Hardware ausgeführt, die mit der Hardware vergleichbar ist, auf der die vorherige SQL Server-Version (Quelle) ausgeführt wurde.
Die gleiche unterstützte Datenbankkompatibilitätsebene wird sowohl auf dem Ziel-SQL Server als auch auf der Quell-SQL Server-Quelle verwendet.
Die gleiche Datenbank und Arbeitslast werden sowohl auf dem Ziel-SQL-Server als auch auf dem Quell-SQL-Server verwendet.
Jede Regression der Abfrageplanform (im Vergleich zum Quell-SQL-Server), die unter diesen Bedingungen auftritt, wird behoben. Wenden Sie sich in diesem Fall an den Microsoft-Kundensupport.