Freigeben über

Kompatibilitätszertifizierung

  • Artikel

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.

SharePoint Server 2016 und SharePoint Server 2019 führen Zertifizierungen für SQL Server und Verwaltete Azure SQL-Instanz auf dieselbe Weise durch, sodass Sie jede SQL Server-Datenbank-Engine bereitstellen können, die die unterstützten Datenbank-Kompatibilitätsgrade für diese SharePoint Server-Versionen verwenden kann. 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. Durch eine Zertifizierung auf Grundlage des Kompatibilitätsgrads legen Entwickler die technischen Anwendungsanforderungen fest. Diese müssen erfüllt sein, damit die Anwendungen in SQL Server und Azure SQL-Datenbank unterstützt werden. Gleichzeitig wird jedoch der Lebenszyklus der Anwendung vom Lebenszyklus der Datenbankplattform getrennt. 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.

Bei einem Upgrade bestehen die wesentlichen Risikofaktoren in einer eingeschränkten Funktionalität und Leistung. 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. Abfrageplanabweichungen, die bei einem Upgrade auftreten, führen in der Regel zu einem Risiko, wenn eine bestimmte Abfrage oder Workload durch Änderungen beeinträchtigt werden können. 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 Schutz der Abfrageplanform. Das bedeutet: Wenn der Datenbank-Kompatibilitätsgrad nach einem Upgrade der Datenbank-Engine beibehalten wird, wird dasselbe Modell zur Abfrageoptimierung in der neuen Version verwendet wie vor dem Upgrade. Die Abfrageplanform 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.

Wichtig

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 ist ein erneutes Zertifizieren der Anwendungen nicht erforderlich. Weitere Informationen finden Sie weiter unten in diesem Artikel unter Kompatibilitätsgrade und Upgrades der Datenbank-Engine.

Bei Neuentwicklungen oder wenn eine vorhandene Anwendung neue Features wie die intelligente Abfrageverarbeitung sowie eine neue Version von Transact-SQL nutzen muss, sollten Sie ein Upgrade auf den neuesten in SQL Server verfügbaren Datenbank-Kompatibilitätsgrad planen und Ihre Anwendung so erneut zertifizieren, dass sie mit diesem Kompatibilitätsgrad verwendet werden kann. 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.

Das Beibehalten der Form eines Abfrageplans ist jedoch nicht der einzige Faktor, der nach einem Upgrade zu Leistungseinbußen führen kann. Wenn Sie die Datenbank auf eine neuere Datenbank-Engine verschieben und auch Umgebungsänderungen vornehmen, führen Sie möglicherweise Faktoren ein, die unmittelbare Auswirkungen auf die Leistung einer Abfrage haben, auch wenn der Abfrageplan die gleiche Form in verschiedenen Versionen beibehält. Diese Umgebungsänderungen können das neue Datenbank-Engine enthalten, das mehr oder weniger Arbeitsspeicher und CPU-Ressourcen verfügbar macht, Änderungen an Server-oder Datenbank-Konfigurationsoptionen 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. SQL Server enthält beispielsweise folgende Optimierungen:

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.

Wichtig

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 Matrix für die unterstützten Datenbank-Kompatibilitätsgrade finden Sie unter Argumente.

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.

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

Kompatibilitätsgrade und Upgrades der Datenbank-Engine

Wenn Sie für die Datenbank-Engine ein Upgrade auf die neueste Version durchführen, dabei aber den Datenbank-Kompatibilitätsgrad von vor dem Upgrade und dessen Unterstützbarkeitsstatus beibehalten möchten, empfiehlt es sich, eine statische Funktionsüberprüfung des Oberflächenbereichs des Anwendungscodes in der Datenbank (Programmierbarkeitsobjekte wie gespeicherte Prozeduren, Funktionen und Trigger) und in der Anwendung (mithilfe einer Arbeitsauslastungs-Ablaufverfolgung, die den von der Anwendung gesendeten dynamischen Code erfasst) durchzuführen.

Dies ist mit dem Tool Microsoft Datenmigrations-Assistent (DMA) problemlos möglich. Gibt es in der Ausgabe von DMA keine Fehler hinsichtlich fehlender oder inkompatibler Funktionalität, ist zu erwarten, dass es keine funktionalen Rückschritte für die Anwendung in der neuen Zielversion gibt. Wenn Änderungen erforderlich sind, um sicherzustellen, dass Ihre Datenbank in der neuen Version funktioniert, können Sie mit dem DMA ermitteln, wo Änderungen erforderlich sind und welche Problemumgehungsmöglichkeiten es gibt. Weitere Informationen finden Sie unter Übersicht über den Datenmigrations-Assistenten.

Tipp

Diese Funktionsüberprüfung ist besonders wichtig, wenn eine Datenbank von einer Legacyversion (z. B. SQL Server 2008 R2(10.50.x) oder SQL Server 2012 (11.x)) zu einer neuen Version von SQL Server oder Azure SQL-Datenbank migriert wird, da Ihr Anwendungscode möglicherweise eine nicht mehr unterstützte Version von Transact-SQL verwendet, die vom Datenbank-Kompatibilitätsgrad nicht umfasst ist. Wenn Sie jedoch von einer neueren Version (z. B. SQL Server 2016 (13.x)) zu SQL Server 2019 (15.x) oder Azure SQL-Datenbank wechseln, müssen Sie sich keine Gedanken über eine nicht mehr unterstützte Version von Transact-SQL 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

DMA unterstützt Datenbank-Kompatibilitätsgrad 100 und höher. SQL Server 2005 (9.x) ist als Quellversion ausgeschlossen.

Wichtig

Microsoft empfiehlt, einige Minimaltests auszuführen, um den Erfolg eines Upgrades zu überprüfen, wenn der frühere Datenbank-Kompatibilitätsgrad beibehalten wird. Sie sollten bestimmen, was „minimale Tests“ im Zusammenhang Ihrer Anwendung und Ihres Szenarios bedeutet.

Wichtig

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.
  • Derselbe unterstützte Datenbank-Kompatibilitätsgrad wird sowohl in der SQL Server-Ziel- als auch in der SQL Server-Quellinstanz verwendet.
  • Dieselbe Datenbank und Workload werden sowohl für die SQL Server-Zielinstanz als auch für die SQL Server-Quellinstanz verwendet.

Alle Rückschritte der Abfrageplanform (im Vergleich mit der SQL Server-Quellinstanz), die bei den oben genannten Bedingungen auftreten, werden behandelt. Wenden Sie sich an den Microsoft-Kundensupport, wenn dies der Fall ist.

Siehe auch