Freigeben über

Leitfaden für die Überprüfung und Optimierung nach der Migration

Gilt für:SQL Server

Der in SQL Server nach der Migration ausgeführte Schritt ist entscheidend für die Abstimmung eventueller Datenungenauigkeiten, die Überprüfung der Vollständigkeit und das Beheben von Leistungsproblemen der Workload.

Allgemeine Leistungsszenarios

Im Folgenden sind einige der häufigsten Leistungsszenarios aufgelistet, die nach der Migration zur SQL Server-Plattform auftreten, und wie sie behoben werden können. Hierzu gehören auch Szenarios, die für die Migration von älteren SQL Server-Versionen zu neueren sowie für die Migration von Drittanbieterplattformen (z. B. Oracle, DB2, MySQL und Sybase) zu SQL Server spezifisch sind.

Abfrageregressionen aufgrund einer Änderung in der Version der Kardinalitätsschätzun (CE)

Gilt für: Migration von älteren SQL Server-Versionen zu neueren.

Wenn Sie von einer älteren SQL Server-Version zu SQL Server 2014 (12.x) oder höheren Versionen migrieren und ein Upgrade auf den aktuellen Datenbank-Kompatibilitätsgrad durchführen, können bei einer Workload womöglich Leistungseinbußen auftreten.

Dies liegt daran, dass seit SQL Server 2014 (12.x) alle Änderungen des Abfrageoptimierers an den neuesten Datenbank-Kompatibilitätsgrad gebunden sind, sodass Pläne nicht sofort im Moment des Upgrades geändert werden, sondern erst, wenn ein Benutzer die Datenbankoption COMPATIBILITY_LEVEL auf den neusten Stand aktualisiert. Diese Möglichkeit gibt Ihnen in Kombination mit dem Abfragespeicher ein großes Maß an Kontrolle über die Abfrageleistung im Upgradeprozess.

Weitere Informationen zu Änderungen des Abfrageoptimierers, der in SQL Server 2014 (12.x) eingeführt wurde, finden Sie unter Optimizing Your Query Plans with the SQL Server 2014 Cardinality Estimator (Optimieren Ihrer Abfragepläne mit der Kardinalitätsschätzung von SQL Server 2014).

Weitere Informationen zu CE finden Sie unter Kardinalitätsschätzung (SQL Server).

Schritte zum Beheben

Ändern Sie den Datenbank-Kompatibilitätsgrad auf die Quellversion, und befolgen Sie den empfohlenen Upgradeworkflow wie in folgendem Bild gezeigt:

Diagramm: Empfohlener Upgradeworkflow

Weitere Informationen zu diesem Artikel finden Sie unter Aufrechterhalten einer stabilen Leistung während des Upgrades auf SQL Server 2016.

Sensitivität für die Parameterermittlung

Gilt für: Migration von Drittanbieterplattformen (z. B. Oracle, DB2, MySQL und Sybase) zu SQL Server.

Hinweis

Für SQL Server-zu SQL Server-Migrationen wird dieses Szenario nicht behoben, wenn dieses Problem in der SQL Server-Quelle vorhanden ist, wenn die Migration zu einer neueren Version von SQL Server as-is nicht behoben ist.

SQL Server kompiliert Abfragepläne in gespeicherten Prozeduren, indem die Eingabeparameter bei der ersten Kompilierung ermittelt werden. Anschließend wird ein parametrisierter und wiederverwendbarer Plan generiert, der für diese Verteilung von Eingabedaten optimiert ist. Die meisten Anweisungen, die triviale Pläne generieren, werden parametrisiert, wenn auch nicht in gespeicherten Prozeduren. Nachdem Sie ein Plan zuerst zwischengespeichert wird, wird jede spätere Ausführung einem zuvor zwischengespeicherten Plan zugeordnet.

Ein mögliches Problem tritt auf, wenn diese erste Kompilierung möglicherweise nicht die am häufigsten verwendeten Parametersätze für die übliche Arbeitsauslastung verwendet hat. Bei anderen Parametern wird derselbe Ausführungsplans ineffizient. Weitere Informationen zu diesem Artikel finden Sie unter Parameterempfindlichkeit.

Schritte zum Beheben

  1. Verwenden Sie den RECOMPILE-Hinweis. Ein Plan wird jedes Mal je nach Parameterwert berechnet.

  2. Schreiben Sie die gespeicherte Prozedur neu, sodass die Option (OPTIMIZE FOR(<input parameter> = <value>)) verwendet wird. Entscheiden Sie, welcher Wert verwendet werden soll, der die am besten zu den meisten der relevanten Arbeitsauslastungen passt und einen Plan erstellt und verwaltet, der für die parametrisierten Werte effizient wird.

  3. Schreiben Sie die gespeicherten Prozeduren mithilfe der lokalen Variablen innerhalb der Prozedur neu. Nun verwendet der Optimierer den Dichtevektor für Einschätzungen, was zu dem gleichen Plan führt, unabhängig vom Parameterwert.

  4. Schreiben Sie die gespeicherte Prozedur neu, sodass die Option (OPTIMIZE FOR UNKNOWN) verwendet wird. Dies hat dieselbe Wirkung wie die Verwendung der lokalen Variablen.

  5. Schreiben Sie die Abfrage neu, sodass der Hinweis DISABLE_PARAMETER_SNIFFING verwendet wird. Dies hat denselben Effekt wie die Verwendung der lokalen Variablen: Die Parameterermittlung wird vollständig deaktiviert, es sei denn, OPTION(RECOMPILE), WITH RECOMPILE oder OPTIMIZE FOR <value> wird verwendet.

Tipp

Nutzen Sie die Vorteile der Management Studio-Plananalyse, um schnell zu ermitteln, ob es sich um ein Problem handelt. Weitere Informationen finden Sie unter "Neu" in SSMS: Problembehandlung zur Abfrageleistung, die einfacher gemacht wurde.

Fehlende Indizes

Gilt für: Migration von Drittanbieterplattformen (z. B. Oracle, DB2, MySQL und Sybase) und SQL Server zu SQL Server.

Falsche oder fehlende Indizes führt zu zusätzlicher Eingabe/Ausgabe, wegen der zusätzlicher Arbeitsspeicher und CPU verschwendet wird. Dies kann daran liegen, dass das Arbeitsauslastungsprofil geändert wurde, also z.B. die Verwendung anderer Prädikate, die den vorhandenen Indexentwurf ungültig machen. Anzeichen einer schlechten Indizierungsstrategie oder Änderungen am Arbeitsauslastungsprofil sind z.B. folgende:

  • Doppelte, redundante, selten verwendete und vollständig nicht verwendete Indizes
  • Nicht verwendete Indizes mit Updates. Dabei ist besondere Sorgfalt geboten.

Schritte zum Beheben

  1. Verwenden Sie den grafischen Ausführungsplan für alle fehlenden Indexreferenzen.

  2. Indizieren Sie generierte Vorschläge mit dem Datenbankoptimierungsratgeber.

  3. Verwenden Sie die sys.dm_db_missing_index_details.

  4. Verwenden Sie bereits vorhandene Skripts, die vorhandene DMVs verwenden können, um Einblicke in fehlende, duplizierte, redundante, selten verwendete und vollständig nicht verwendete Indizes zu erhalten, aber auch wenn ein Indexverweis in vorhandene Prozeduren und Funktionen in Ihrer Datenbank angedeutet/hartcodiert ist.

Tipp

Beispiele für solche vorhandenen Skripts sind Indexerstellung und Indexinformationen.

Unmöglichkeit, mit Prädikaten Daten zu filtern

Gilt für: Migration von Drittanbieterplattformen (z. B. Oracle, DB2, MySQL und Sybase) und SQL Server zu SQL Server.

Hinweis

Für SQL Server-zu SQL Server-Migrationen wird dieses Szenario nicht behoben, wenn dieses Problem in der SQL Server-Quelle vorhanden ist, wenn die Migration zu einer neueren Version von SQL Server as-is nicht behoben ist.

Der SQL Server-Abfrageoptimierer kann nur Informationen berücksichtigen, die zur Kompilierzeit bekannt sind. Wenn eine Arbeitsauslastung Prädikate nutzt, die nur zum Zeitpunkt der Ausführung bekannt sein können, erhöht sich das Risiko einer schlechten Planauswahl. Für einen besseren Plan müssen Prädikate SARGable sein.

Hinweis

Der Begriff SARGable in relationalen Datenbanken bezieht sich auf ein SarchARGumentfähiges Prädikat, das einen Index verwenden kann, um die Ausführung der Abfrage zu beschleunigen. Weitere Informationen finden Sie in der SQL Server- und Azure SQL-Indexarchitektur und im Entwurfshandbuch.

Einige Beispiele für nicht SARGable Prädikate:

  • Implizite Datenkonvertierungen wie varchar zu nvarchar oder int zu varchar. Suchen Sie in den tatsächlichen Ausführungsplänen nach CONVERT_IMPLICIT-Laufzeitwarnungen. Das Konvertieren von einem Typ in einen anderen kann auch zu einem Genauigkeitsverlust führen.

  • Komplexe unbestimmte Ausdrücke wie WHERE UnitPrice + 1 < 3.975, aber nicht WHERE UnitPrice < 320 * 200 * 32.

  • Ausdrücke mit Funktionen wie WHERE ABS(ProductID) = 771 oderWHERE UPPER(LastName) = 'Smith'

  • Zeichenfolgen mit einem führenden Platzhalterzeichen wie WHERE LastName LIKE '%Smith', aber nicht WHERE LastName LIKE 'Smith%'

Schritte zum Beheben

  1. Deklarieren Sie Variablen/Parameter immer als vorgesehenen Zieldatentyp.

    Dies kann ein Vergleich von benutzerdefinierten Codekonstrukten umfassen, die in der Datenbank (z. B. gespeicherte Prozeduren, benutzerdefinierte Funktionen oder Ansichten) gespeichert sind, mit Systemtabellen, die Informationen zu Datentypen enthalten, die in zugrunde liegenden Tabellen (z. B. sys.columns) verwendet werden.

  2. Wenn der gesamte Code nicht bis zum vorherigen Punkt durchsucht werden kann, ändern Sie zum gleichen Zweck den Datentyp für die Tabelle entsprechend einer Variablen-/Parameterdeklaration.

  3. Gründe für die Nützlichkeit der folgenden Konstrukte:

    • Funktionen werden als Prädikate verwendet
    • Platzhaltersuchen
    • Komplexe Ausdrücke auf Grundlage von spaltenbasierten Daten. Bewerten Sie die Notwendigkeit, stattdessen persistente berechnete Spalten zu erstellen, die indiziert werden können

Hinweis

Alles, was oben aufgeführt ist, kann programmgesteuert ausgeführt werden.

Verwendung von Tabellenwertfunktionen (Funktionen mit mehreren Anweisungen oder Inlinefunktionen)

Gilt für: Migration von Drittanbieterplattformen (z. B. Oracle, DB2, MySQL und Sybase) und SQL Server zu SQL Server.

Hinweis

Für SQL Server-zu SQL Server-Migrationen wird dieses Szenario nicht behoben, wenn dieses Problem in der SQL Server-Quelle vorhanden ist, wenn die Migration zu einer neueren Version von SQL Server as-is nicht behoben ist.

Tabellenwertfunktionen geben einen table-Datentyp zurück, der eine Alternative zu Ansichten sein kann. Ansichten sind auf eine einzelne SELECT-Anweisung beschränkt, während benutzerdefinierte Funktionen zusätzliche Anweisungen enthalten können, die mehr Logik als ansichten ermöglichen.

Da die Ausgabetabelle einer mehrwertigen Tabellenfunktion (MSTVF) zur Kompilierungszeit nicht erstellt wird, basiert der SQL Server-Abfrageoptimierer auf Heuristiken und nicht auf tatsächlichen Statistiken, um Zeilenschätzungen zu bestimmen.

Auch wenn Indizes zu den Basistabellen hinzugefügt werden, wird dies nicht hilfreich sein.

Für MSTVFs verwendet SQL Server eine feste Schätzung von 1 für die Anzahl der Zeilen, die erwartungsgemäß von einem MSTVF zurückgegeben werden sollen (ab SQL Server 2014 (12.x) beträgt diese feste Schätzung 100 Zeilen).

Schritte zum Beheben

  1. Wenn es sich bei der MSTVF-Anweisung nur um eine einzelne Anweisung handelt, konvertieren Sie sie in eine Inline-Tabellenwertfunktion.

    CREATE FUNCTION dbo.tfnGetRecentAddress (@ID INT)
RETURNS
    @tblAddress TABLE ([Address] VARCHAR (60) NOT NULL)
AS
BEGIN
    INSERT INTO @tblAddress ([Address])
    SELECT TOP 1 [AddressLine1]
    FROM [Person].[Address]
    WHERE AddressID = @ID
    ORDER BY [ModifiedDate] DESC;
    RETURN;
END

    Es folgt das Beispiel für das Inline-Format.

    CREATE FUNCTION dbo.tfnGetRecentAddress_inline
(@ID INT)
RETURNS TABLE
AS
RETURN
    (SELECT TOP 1 [AddressLine1] AS [Address]
     FROM [Person].[Address]
     WHERE AddressID = @ID
     ORDER BY [ModifiedDate] DESC)

  2. Wenn sie komplexer ist, sollten Sie die Zwischenergebnisse verwenden, die in speicheroptimierten Tabellen oder in temporären Tabellen gespeichert sind.

Zugehöriger Inhalt

  • Last updated on