Kompatibilitätsebenen und Kardinalitätsschätzungs-Primer

Einführung

Zwischen 1998 und Anfang 2014 verwendete SQL Server einen Cardinality Estimator (CE), führte jedoch mit jeder neuen Hauptversion von SQL Server (mit Ausnahme von SQL Server 2008 R2) einen neuen Datenbankkompatibilitätsgrad ein. Die nativen Kompatibilitätsgrade für SQL Server sind in Tabelle 1 nach Hauptversion von SQL Server aufgeführt:

Tabelle 1:SQL Server-Versionen und native Kompatibilitätsstufen

Zwischen SQL Server 7.0 und SQL Server 2012 bestand keine Verbindung zwischen dem Kompatibilitätsgrad einer Datenbank und dem Kardinalitätsschätzer, den Abfragen in dieser Datenbank verwenden würden. Dies liegt daran, dass es nur einen Kardinalitätsschätzer gab, der 1998 ein größeres Update erhielt. Der Kompatibilitätsgrad einer Datenbank wurde nur für die funktionale Rückwärtskompatibilität und zum Aktivieren/Deaktivieren einiger neuer Funktionen in jeder neuen Version von SQL Server verwendet (siehe this Stack Exchange-Antwort für Beispiele, wie sich das Verhalten zwischen 80 und 90 geändert hat, wahrscheinlich die störendste Änderung). Im Gegensatz zur Dateiversion einer SQL Server-Datenbank können Sie den Kompatibilitätsgrad einer Datenbank jederzeit mit einem einfachen ALTER DATABASE-Befehl auf einen beliebigen unterstützten Kompatibilitätsgrad ändern.

Standardmäßig, wenn Sie eine neue erstellt haben Datenbank in SQL Server 2012 wird der Kompatibilitätsgrad auf 110 festgelegt, aber Sie können ihn auf Wunsch auf einen früheren Grad ändern. Wenn Sie wiederhergestellt haben B. eine Datenbanksicherung von einer SQL Server 2008-Instanz auf eine SQL Server 2012-Instanz, würde die Dateiversion der Datenbank aktualisiert, aber der Kompatibilitätsgrad auf der SQL Server 2008-Instanz beibehalten (es sei denn, es wäre 80, was wäre erhalten Sie ein Upgrade auf 90, die von SQL Server 2012 unterstützte Mindestversion). Abgesehen davon, dass sie den grundlegenden Unterschied zwischen der Dateiversion einer Datenbank und dem Kompatibilitätsgrad einer Datenbank kannten, mussten sich die meisten DBAs und Entwickler vor der Veröffentlichung von SQL Server 2014 keine großen Gedanken über Datenbankkompatibilitätsgrade machen. In vielen Fällen wurden die Kompatibilitätsgrade der meisten Datenbanken nach einer Migration auf eine neue Version von SQL Server nie geändert. Dies verursachte normalerweise keine Probleme, es sei denn, Sie benötigten tatsächlich eine neue Funktion oder ein neues Verhalten, das sich in der neuesten Datenbankkompatibilitätsstufe geändert hat.

SQL Server 2014-Änderungen

Dieser alte Stand der Dinge hat sich mit der Veröffentlichung von SQL Server 2014 radikal geändert. SQL Server 2014 führte einen „neuen“ Kardinalitätsschätzer ein, der standardmäßig aktiviert war wenn sich eine Datenbank im Kompatibilitätsgrad 120 befand. Im klassischen Whitepaper „Optimizing Your Query Plans with the SQL Server 2014 Cardinality Estimator“ erläutert Joe Sack die Hintergründe und das Verhalten dieser Änderung im April 2014. In vielen Fällen liefen die meisten Ihrer Abfragen schneller, wenn Sie die neue Kardinalität verwendeten Estimator, aber es kam ziemlich häufig vor, dass einige Abfragen mit dem neuen Kardinalitätsschätzer auf große Leistungsregressionen stießen. In diesem Fall hatte SQL Server 2014 nicht so viele Optionen, um die durch das neue CE verursachten Leistungsprobleme zu lindern. Joes Whitepaper behandelt diese Optionen sehr detailliert, aber im Wesentlichen waren Sie auf Trace-Flags auf Instanzebene oder Abfragehinweise auf Abfrageebene beschränkt, um zu steuern, welcher Kardinalitätsschätzer vom Abfrageoptimierer verwendet wurde, es sei denn, Sie wollten zum Kompatibilitätsgrad 110 oder niedriger zurückkehren .

SQL Server 2016-Änderungen

SQL Server 2016 hat datenbankweite Konfigurationsoptionen eingeführt, die Ihnen die Möglichkeit geben, einige Verhaltensweisen zu steuern, die zuvor auf Instanzebene konfiguriert wurden, indem Sie einen ALTER DATABASE SCOPED CONFIGURATION-Befehl verwenden. In SQL Server 2016 umfassten diese Optionen MAXDOP, LEGACY_CARDINALITY ESTIMATION, PARAMETER_SNIFFING und QUERY_OPTIMIZER_HOTFIXES. Es gab auch eine CLEAR PROCEDURE_CACHE-Option, mit der Sie den gesamten Plan-Cache für eine einzelne Datenbank löschen konnten.

Am relevantesten in diesem Zusammenhang sind die datenbankbezogenen Konfigurationsoptionen LEGACY_CARDINALITY ESTIMATION und QUERY_OPTIMIZER_HOTFIXES. LEGACY_CARDINALITY ESTIMATION aktiviert das Legacy-CE unabhängig von der Einstellung des Kompatibilitätsgrads der Datenbank. Es entspricht dem Ablaufverfolgungsflag 9481, wirkt sich jedoch nur auf die betreffende Datenbank aus, nicht auf die gesamte Instanz. Es ermöglicht Ihnen, den Datenbank-Kompatibilitätsgrad auf 130 festzulegen, um eine Reihe von Funktions- und Leistungsvorteilen zu erhalten, aber dennoch das Legacy-CE datenbankweit zu verwenden (sofern es nicht durch einen Abfragehinweis auf Abfrageebene überschrieben wird).

Die Option QUERY_OPTIMIZER_HOTFIXES entspricht dem Ablaufverfolgungsflag 4199 auf Datenbankebene. SQL Server 2016 aktiviert alle Hotfixes des Abfrageoptimierers vorher SQL Server 2016 RTM, wenn Sie den Datenbankkompatibilitätsgrad 130 verwenden (ohne das Ablaufverfolgungsflag 4199 zu aktivieren). Wenn Sie TF 4199 oder QUERY_OPTIMIZER_HOTFIXES aktivieren, erhalten Sie auch alle Hotfixes des Abfrageoptimierers, die nach veröffentlicht wurden SQL Server 2016 RTM.

SQL Server 2016 SP1 führte auch die USE HINT-Abfragehinweise ein, die einfacher zu verwenden, zu verstehen und zu merken sind als die älteren QUERYTRACEON-Abfragehinweise. Dadurch erhalten Sie eine noch genauere Kontrolle über das Optimiererverhalten, das sich auf den Datenbankkompatibilitätsgrad und die Version des verwendeten Kardinalitätsschätzers bezieht. Sie können sys.dm_exec_valid_use_hints abfragen, um eine Liste gültiger USE HINT-Namen für den genauen Build von SQL Server zu erhalten, den Sie ausführen.

SQL Server 2017-Änderungen

Die neue adaptive Abfrageverarbeitungsfunktion wurde in SQL Server 2017 hinzugefügt und ist standardmäßig aktiviert, wenn Sie den Datenbankkompatibilitätsgrad 140 verwenden.

Microsoft versucht, sich von der alten Terminologie „Neues CE“ und „Altes CE“ zu lösen, da es tatsächlich Änderungen und Korrekturen zur Abfrageoptimierung in jeder neuen Hauptversion von SQL Server gibt. Aus diesem Grund gibt es kein einheitliches „Neues CE“ mehr. Stattdessen möchte Microsoft auf CE70 (Standard-CE für SQL Server 7.0 bis SQL Server 2012), CE120 für SQL Server 2014, CE130 für SQL Server 2016, CE140 für SQL Server 2017 und CE150 für SQL Server 2019 verweisen. Beginnend mit SQL Server 2017 CU10 können Sie die Funktion USE HINT verwenden, um dies mit Abfragehinweisen zu steuern. Zum Beispiel:

/*...query...*/ OPTION (USE HINT('QUERY_OPTIMIZER_COMPATIBILITY_LEVEL_130'));

… wäre ein gültiger Abfragehinweis, um den CE130-Kardinalitätsschätzer für eine bestimmte Abfrage zu erzwingen.

SQL Server 2019-Änderungen

SQL Server 2019 fügt noch mehr Leistungsverbesserungen und Verhaltensänderungen hinzu, die standardmäßig aktiviert sind, wenn eine Datenbank den Kompatibilitätsmodus 150 verwendet. Ein Paradebeispiel ist das skalare UDF-Inlining. Ein weiteres Beispiel ist die intelligente Abfrageverarbeitungsfunktion, die eine Obermenge der adaptiven Abfrageverarbeitung in SQL Server 2017 ist.

Es gibt fünf neue USE HINT-Optionen, darunter Möglichkeiten zum Deaktivieren des Stapelmodus oder des adaptiven Feedbacks zur Speicherzuweisung, wie in Tabelle 2 gezeigt:

Tabelle 2:Neue USE HINT-Optionen

Außerdem gibt es sechzehn neue datenbankbezogene Konfigurationsoptionen (ab CTP 2.2), mit denen Sie mehr Elemente auf Datenbankebene steuern können, die ebenfalls von Ablaufverfolgungsflags oder dem Datenbankkompatibilitätsgrad betroffen sind. Es gibt Ihnen eine genauere Kontrolle über Änderungen auf höherer Ebene, die standardmäßig mit Datenbank-Kompatibilitätsgrad 150 aktiviert sind. Diese sind in Tabelle 3 aufgelistet:

Tabelle 3:Neue datenbankbezogene Konfigurationsoptionen

Schlussfolgerung

Die Migration zu einer modernen Version von SQL Server (d. h. SQL Server 2016 oder neuer) ist erheblich komplizierter als bei älteren Versionen von SQL Server. Aufgrund der Änderungen im Zusammenhang mit den verschiedenen Datenbankkompatibilitätsgraden und verschiedenen Kardinalitätsschätzungsversionen ist es sehr wichtig, sich Gedanken darüber zu machen, zu planen und tatsächlich zu testen, welchen Datenbankkompatibilitätsgrad Sie für die neue Version von SQL Server verwenden möchten migrieren Ihre bestehenden Datenbanken nach.

Der von Microsoft empfohlene Upgradeprozess besteht darin, auf die neueste SQL Server-Version zu aktualisieren, aber den Kompatibilitätsgrad der Quelldatenbank beizubehalten. Aktivieren Sie dann den Abfragespeicher für jede Datenbank und erfassen Sie Basisdaten zur Workload. Als Nächstes stellen Sie den Kompatibilitätsgrad der Datenbank auf die neueste Version ein und verwenden dann den Abfragespeicher, um Leistungsrückgänge zu beheben, indem Sie den letzten bekannten guten Plan erzwingen.

Sie möchten wirklich eine zufällige „blinde“ Migration vermeiden, bei der Sie glücklicherweise nicht wissen, wie dies funktioniert und wie Ihre Workload auf diese Änderungen reagieren wird. Bei modernen Versionen von SQL Server ist es äußerst wichtig, den Kompatibilitätsgrad der Datenbank auf eine geeignete Version zu ändern und die entsprechenden Konfigurationsoptionen für den Datenbankbereich zusammen mit geeigneten Abfragehinweisen zu verwenden, wo dies unbedingt erforderlich ist.