Freigeben über

Problembehandlung bei langsamen Abfragen in einem dedizierten SQL-Pool

Gilt für: Azure Synapse Analytics

Dieser Artikel hilft Ihnen, die Gründe zu identifizieren und Entschärfungen für allgemeine Leistungsprobleme mit Abfragen in einem dedizierten SQL-Pool von Azure Synapse Analytics anzuwenden.

Führen Sie die Schritte aus, um das Problem zu beheben. Die ersten drei Schritte führen Sie durch die Erfassung von Telemetrie, die den Lebenszyklus einer Abfrage beschreibt. Die Verweise am Ende des Artikels helfen Ihnen, potenzielle Chancen in den gesammelten Daten zu analysieren.

Wichtig

Die meisten gemeldeten Leistungsprobleme werden durch Folgendes verursacht:

  • Veraltete Statistiken
  • Fehlerhafte gruppierte Columnstore-Indizes (CCIs)

Um Die Problembehandlungszeit zu sparen, stellen Sie sicher, dass die Statistiken erstellt und auf dem neuesten Stand sind, und erstellen Sie gruppierte Spaltenspeicherindizes im dedizierten SQL-Pool neu.

Schritt 1: Identifizieren des request_id (auch bekannt als QID)

Das request_id der langsamen Abfrage ist erforderlich, um potenzielle Gründe für die Langsamkeit der Abfrage zu recherchieren. Verwenden Sie das folgende Skript als Ausgangspunkt für die Identifizierung der Abfrage, die Sie behandeln möchten. Sobald die langsame Abfrage identifiziert wurde, notieren Sie sich den request_id Wert.

Überwachen Sie zunächst die aktiven Abfragen. Diese Abfrage wird zuerst nach den neuesten Zeilen sortiert.

-- Monitor active queries
SELECT *
FROM sys.dm_pdw_exec_requests
WHERE [status] NOT IN ('Completed', 'Failed', 'Cancelled')
      AND session_id <> session_id()
-- AND [label] = '<YourLabel>'
-- AND resource_allocation_percentage is not NULL
ORDER BY submit_time DESC;

Suchen Sie dann die aktiven Abfragen, die die längste Laufzeit haben, beginnend mit den längsten ausgeführten Abfragen.

-- Find top 10 longest running queries
SELECT TOP 10 *
FROM sys.dm_pdw_exec_requests
ORDER BY total_elapsed_time DESC;

Wenn Sie die langsamen Abfragen besser ansprechen möchten, verwenden Sie beim Ausführen des Skripts die folgenden Tipps:

  • Sortieren Sie entweder nach submit_time DESC oder total_elapsed_time DESC, um die am längsten laufenden Abfragen oben in der Ergebnisliste anzuzeigen.
  • Verwenden Sie OPTION(LABEL='<YourLabel>') in Ihren Abfragen und filtern Sie dann die label Spalte, um sie zu identifizieren.
  • Erwägen Sie das Filtern von QIDs, für die kein Wert resource_allocation_percentage vorhanden ist, wenn Sie wissen, dass die Zielausweisung in einem Batch enthalten ist. Seien Sie mit diesem Filter vorsichtig, da sie auch einige Abfragen herausfiltern kann, die von anderen Sitzungen blockiert werden.

Schritt 2: Ermitteln, wo die Abfrage Zeit in Anspruch nimmt

Führen Sie das folgende Skript aus, um den Schritt zu finden, der das Leistungsproblem der Abfrage verursachen kann. Aktualisieren Sie die Variablen im Skript mit den in der folgenden Tabelle beschriebenen Werten. Ändern Sie den @ShowActiveOnly Wert auf 0, um das vollständige Bild des verteilten Plans zu erhalten. Notieren Sie sich die Werte von StepIndex, Phase und Description des langsamen Schritts, der aus dem Result-Set identifiziert wurde.

Parameter Beschreibung
@QID Der request_id Wert wird in Schritt 1 abgerufen.
@ShowActiveOnly Durch Festlegen des Werts 0 werden alle Schritte für die Abfrage angezeigt.
Legen Sie den Wert so fest, dass 1 nur der derzeit aktive Schritt angezeigt wird.		 
DECLARE @QID AS VARCHAR (16) = '<request_id>', @ShowActiveOnly AS BIT = 1;
-- Retrieve session_id of QID

DECLARE @session_id AS VARCHAR (16) = (SELECT session_id
                                       FROM sys.dm_pdw_exec_requests
                                       WHERE request_id = @QID);
-- Blocked by Compilation or Resource Allocation (Concurrency)
SELECT @session_id AS session_id, @QID AS request_id, -1 AS [StepIndex], 'Compilation' AS [Phase],
   'Blocked waiting on '
       + MAX(CASE WHEN waiting.type = 'CompilationConcurrencyResourceType' THEN 'Compilation Concurrency'
                  WHEN waiting.type LIKE 'Shared-%' THEN ''
                  ELSE 'Resource Allocation (Concurrency)' END)
       + MAX(CASE WHEN waiting.type LIKE 'Shared-%' THEN ' for ' + REPLACE(waiting.type, 'Shared-', '')
             ELSE '' END) AS [Description],
   MAX(waiting.request_time) AS [StartTime], GETDATE() AS [EndTime],
   DATEDIFF(ms, MAX(waiting.request_time), GETDATE())/1000.0 AS [Duration],
   NULL AS [Status], NULL AS [EstimatedRowCount], NULL AS [ActualRowCount], NULL AS [TSQL]
FROM sys.dm_pdw_waits waiting
WHERE waiting.session_id = @session_id
      AND ([type] LIKE 'Shared-%'
           OR [type] IN ('ConcurrencyResourceType', 'UserConcurrencyResourceType', 'CompilationConcurrencyResourceType'))
      AND [state] = 'Queued'
GROUP BY session_id
-- Blocked by another query
UNION ALL
SELECT @session_id AS session_id,
       @QID AS request_id,
       -1 AS [StepIndex],
       'Compilation' AS [Phase],
       'Blocked by ' + blocking.session_id + ':' + blocking.request_id + ' when requesting ' + waiting.type + ' on ' + QUOTENAME(waiting.object_type) + waiting.object_name AS [Description],
       waiting.request_time AS [StartTime],
       GETDATE() AS [EndTime],
       DATEDIFF(ms, waiting.request_time, GETDATE()) / 1000.0 AS [Duration],
       NULL AS [Status],
       NULL AS [EstimatedRowCount],
       NULL AS [ActualRowCount],
       COALESCE (blocking_exec_request.command, blocking_exec_request.command2) AS [TSQL]
FROM sys.dm_pdw_waits AS waiting
     INNER JOIN
     sys.dm_pdw_waits AS blocking
     ON waiting.object_type = blocking.object_type
        AND waiting.object_name = blocking.object_name
     INNER JOIN
     sys.dm_pdw_exec_requests AS blocking_exec_request
     ON blocking.request_id = blocking_exec_request.request_id
WHERE waiting.session_id = @session_id
      AND waiting.state = 'Queued'
      AND blocking.state = 'Granted'
      AND waiting.type != 'Shared'
-- Request Steps
UNION ALL
SELECT @session_id AS session_id,
       @QID AS request_id,
       step_index AS [StepIndex],
       'Execution' AS [Phase],
       operation_type + ' (' + location_type + ')' AS [Description],
       start_time AS [StartTime],
       end_time AS [EndTime],
       total_elapsed_time / 1000.0 AS [Duration],
       [status] AS [Status],
       CASE WHEN estimated_rows > -1 THEN estimated_rows END AS [EstimatedRowCount],
       CASE WHEN row_count > -1 THEN row_count END AS [ActualRowCount],
       command AS [TSQL]
FROM sys.dm_pdw_request_steps
WHERE request_id = @QID
      AND [status] = CASE @ShowActiveOnly WHEN 1 THEN 'Running' ELSE [status] END
ORDER BY StepIndex;

Schritt 3: Überprüfen der Schrittdetails

Führen Sie das folgende Skript aus, um die Details des im vorherigen Schritt identifizierten Schritts zu überprüfen. Aktualisieren Sie die Variablen im Skript mit den in der folgenden Tabelle beschriebenen Werten. Ändern Sie den @ShowActiveOnly-Wert in 0, um alle Verteilungszeiten zu vergleichen. Notieren Sie sich den wait_type Wert für die Verteilung, die das Leistungsproblem verursachen kann.

Parameter Beschreibung
@QID Der request_id Wert wird in Schritt 1 abgerufen.
@StepIndex Der StepIndex Wert wird in Schritt 2 identifiziert.
@ShowActiveOnly Den Wert auf 0 einstellen, um alle Verteilungen für den angegebenen StepIndex Wert anzuzeigen.
Wenn der Wert auf 1 gesetzt wird, werden nur die derzeitigen aktiven Verteilungen für den angegebenen StepIndex Wert angezeigt.		 
DECLARE @QID VARCHAR(16) = '<request_id>', @StepIndex INT = <StepIndex>, @ShowActiveOnly BIT = 1;
WITH dists
AS (SELECT request_id, step_index, 'sys.dm_pdw_sql_requests' AS source_dmv,
       distribution_id, pdw_node_id, spid, 'NativeSQL' AS [type], [status],
       start_time, end_time, total_elapsed_time, row_count
    FROM sys.dm_pdw_sql_requests
    WHERE request_id = @QID AND step_index = @StepIndex
    UNION ALL
    SELECT request_id, step_index, 'sys.dm_pdw_dms_workers' AS source_dmv,
       distribution_id, pdw_node_id, sql_spid AS spid, [type],
       [status], start_time, end_time, total_elapsed_time, rows_processed as row_count
    FROM sys.dm_pdw_dms_workers
    WHERE request_id = @QID AND step_index = @StepIndex
   )
SELECT sr.step_index, sr.distribution_id, sr.pdw_node_id, sr.spid,
       sr.type, sr.status, sr.start_time, sr.end_time,
       sr.total_elapsed_time, sr.row_count, owt.wait_type, owt.wait_time
FROM dists sr
   LEFT JOIN sys.dm_pdw_nodes_exec_requests owt
      ON sr.pdw_node_id = owt.pdw_node_id
         AND sr.spid = owt.session_id
         AND ((sr.source_dmv = 'sys.dm_pdw_sql_requests'
                 AND sr.status = 'Running') -- sys.dm_pdw_sql_requests status
              OR (sr.source_dmv = 'sys.dm_pdw_dms_requests'
                     AND sr.status not LIKE 'Step[CE]%')) -- sys.dm_pdw_dms_workers final statuses
WHERE sr.request_id = @QID
      AND ((sr.source_dmv = 'sys.dm_pdw_sql_requests' AND sr.status =
               CASE WHEN @ShowActiveOnly = 1 THEN 'Running' ELSE sr.status END)
           OR (sr.source_dmv = 'sys.dm_pdw_dms_workers' AND sr.status NOT LIKE
                  CASE WHEN @ShowActiveOnly = 1 THEN 'Step[CE]%' ELSE '' END))
      AND sr.step_index = @StepIndex
ORDER BY distribution_id

Schritt 4: Diagnostizieren und Minimieren

Probleme bei der Kompilierungsphase

Blockiert: Kompilierungsnebenläufigkeit

Parallelitätskompilierungsblöcke treten selten auf. Wenn Sie jedoch auf diesen Blocktyp stoßen, bedeutet dies, dass eine große Anzahl von Abfragen in kurzer Zeit übermittelt und in die Warteschlange gestellt wurde, um mit der Kompilierung zu beginnen.

Gegenmaßnahmen

Verringern Sie die Anzahl der gleichzeitig übermittelten Abfragen.


Blockiert: Ressourcenzuordnung

Die Sperrung für die Ressourcenzuweisung bedeutet, dass Ihre Abfrage auf die Ausführung wartet, basierend auf:

  • Die Menge an Arbeitsspeicher, die dem Benutzer basierend auf der seiner Ressourcenkategorie oder Arbeitslastgruppe zugewiesenen Klasseneinteilung gewährt wird.
  • Die Menge des verfügbaren Arbeitsspeichers in der System- oder Workloadgruppe.
  • (Optional) Die Wichtigkeit der Workloadgruppe oder des Klassifizierers.

Gegenmaßnahmen

Komplexe Abfrage oder ältere JOIN-Syntax

Möglicherweise kommt es zu einer Situation, in der die Standardmäßigen Abfrageoptimierermethoden als unwirksam erwiesen sind, da die Kompilierungsphase sehr lange dauert. Möglicherweise tritt es auf, wenn die Abfrage:

  • Umfasst eine hohe Anzahl von Verknüpfungen und/oder Unterabfragen (komplexe Abfrage).
  • Verwendet Joiner in der FROM-Klausel (nicht ANSI-92-Stil-Verknüpfungen).

Obwohl diese Szenarien atypisch sind, haben Sie Optionen, um das Standardverhalten außer Kraft zu setzen, um die Zeit zu verringern, die für den Abfrageoptimierer zum Auswählen eines Plans benötigt wird.

Gegenmaßnahmen

  • Verwenden Sie ANSI-92-Stil-Verknüpfungen.
  • Abfragehinweise hinzufügen: OPTION(FORCE ORDER, USE HINT ('FORCE_LEGACY_CARDINALITY_ESTIMATION')). Weitere Informationen finden Sie unter FORCE ORDER und Cardinality Estimation (SQL Server).
  • Unterteilen Sie die Abfrage in mehrere, weniger komplexe Schritte.
Lang andauernde DROP TABLE oder TRUNCATE TABLE

Zur Verbesserung der Ausführungszeiteffizienz verzögern die Anweisungen DROP TABLE und TRUNCATE TABLE die Speicherbereinigung durch einen Hintergrundprozess. Wenn Ihre Workload jedoch eine hohe Anzahl von DROP/TRUNCATE TABLE Anweisungen in einem kurzen Zeitrahmen ausführt, ist es möglich, dass Metadaten überfüllt werden und nachfolgende DROP/TRUNCATE TABLE Anweisungen langsam ausgeführt werden.

Gegenmaßnahmen

Identifizieren Sie ein Wartungsfenster, beenden Sie alle Arbeitslasten, und führen Sie DBCC SHRINKDATABASE aus, um eine sofortige Bereinigung von zuvor verworfenen oder abgeschnittenen Tabellen zu erzwingen.


Fehlerhafte CCIs (allgemein)

Ein schlechter Zustand des Clusterspeicherindex (Clustered Columnstore Index, CCI) erfordert zusätzliche Metadaten, wodurch der Abfrageoptimierer mehr Zeit benötigt, um einen optimalen Plan zu ermitteln. Um diese Situation zu vermeiden, stellen Sie sicher, dass alle Ihre CCIs in guter Gesundheit sind.

Gegenmaßnahmen

Bewerten und Korrigieren des Indexstatus des gruppierten Columnstores in einem dedizierten SQL-Pool.


Verzögerung beim automatischen Erstellen von Statistiken

Die Option zum automatischen Erstellen von Statistiken ist AUTO_CREATE_STATISTICS standardmäßig, um sicherzustellen, ON dass der Abfrageoptimierer gute verteilte Planentscheidungen treffen kann. Der automatische Erstellungsprozess selbst kann jedoch eine anfängliche Abfrage länger dauern als nachfolgende Ausführungen desselben.

Gegenmaßnahmen

Wenn für die erste Ausführung der Abfrage konsistent Statistiken erstellt werden müssen, müssen Sie vor der Ausführung der Abfrage manuell Statistiken erstellen.


Zeitüberschreitungen beim automatischen Erstellen von Statistiken

Die Option zum automatischen Erstellen von Statistiken ist AUTO_CREATE_STATISTICS standardmäßig, um sicherzustellen, ON dass der Abfrageoptimierer gute verteilte Planentscheidungen treffen kann. Die automatische Erstellung von Statistiken erfolgt als Reaktion auf eine SELECT-Anweisung und hat einen Schwellenwert von 5 Minuten, der abgeschlossen werden soll. Wenn die Größe von Daten und/oder die Anzahl der zu erstellenden Statistiken länger als der Schwellenwert von 5 Minuten ist, wird die automatische Erstellung von Statistiken abgebrochen, damit die Abfrage die Ausführung fortsetzen kann. Das Nichterstellen der Statistiken kann sich negativ auf die Fähigkeit des Abfrageoptimierers auswirken, einen effizienten verteilten Ausführungsplan zu generieren, was die Abfrageleistung verschlechtern kann.

Gegenmaßnahmen

Erstellen Sie die Statistiken manuell, anstatt sich auf das Feature zum automatischen Erstellen für die identifizierten Tabellen/Spalten zu verlassen.

Probleme bei der Ausführungsphase

  • Verwenden Sie die folgende Tabelle, um die Ergebnismenge in Schritt 2 zu analysieren. Ermitteln Sie Ihr Szenario, und überprüfen Sie die häufigsten Ursachen, um detaillierte Informationen zu erhalten und mögliche Gegenmaßnahmen dazu.

    Szenario Übliche Ursache
    EstimatedRowCount / ActualRowCount < 25% Ungenaue Schätzungen
    Der Description Wert gibt an BroadcastMoveOperation , und die Abfrage verweist auf eine replizierte Tabelle. Nicht zwischengespeicherte replizierte Tabellen
    1. @ShowActiveOnly = 0
    2. Es wird eine hohe oder unerwartete Anzahl von Schritten (step_index) beobachtet.
    3. Datentypen von Verbindungsspalten sind nicht identisch zwischen Tabellen.    		 Nicht übereinstimmender Datentyp/Größe
    1. Der Description Wert gibt an HadoopBroadcastOperation, HadoopRoundRobinOperation oder HadoopShuffleOperation.
    2. Der total_elapsed_time Wert eines angegebenen step_index Werts ist zwischen Ausführungen inkonsistent.    		 Ad-hoc-Abfragen für externe Tabellen

  • Überprüfen Sie den total_elapsed_time in Schritt 3 abgerufenen Wert. Wenn es in einigen Verteilungen in einem bestimmten Schritt deutlich höher ist, führen Sie die folgenden Schritte aus:

    1. Überprüfen Sie die Datenverteilung jeder Tabelle, die im Feld TSQL referenziert ist und mit step_id in Verbindung steht, indem Sie den folgenden Befehl für jede Tabelle ausführen:

      DBCC PDW_SHOWSPACEUSED(<table>);

    2. Wenn der minimale Zeilenwert/maximale Zeilenwert 0,1 beträgt, wechseln Sie zu "Daten-Skew (gespeichert)".

    3. Wechseln Sie andernfalls zu In-Flight-Datenverzerrung.

Ungenaue Schätzungen

Halten Sie Ihre Statistiken auf dem neuesten Stand, um sicherzustellen, dass der Abfrageoptimierer einen optimalen Plan generiert. Wenn die geschätzte Zeilenanzahl deutlich kleiner ist als die tatsächliche Anzahl, müssen die Statistiken beibehalten werden.

Gegenmaßnahmen

Überprüfen Sie zunächst die Genauigkeit der Statistiken für einen dedizierten SQL-Pool. Erstellen oder aktualisieren Sie bei Bedarf die Statistiken.


Nicht zwischengespeicherte replizierte Tabellen

Wenn Sie replizierte Tabellen erstellt haben und der replizierte Tabellencache nicht ordnungsgemäß vorab geladen wird, führt dies zu unerwartet schlechter Leistung aufgrund unvorhergesehener zusätzlicher Datenverschiebungen oder der Erstellung eines suboptimalen verteilten Plans.

Gegenmaßnahmen

Nicht übereinstimmender Datentyp/Größe

Stellen Sie beim Verknüpfen von Tabellen sicher, dass der Datentyp und die Größe der verknüpfungsspalten übereinstimmen. Andernfalls führt dies zu unnötigen Datenbewegungen, die die Verfügbarkeit von CPU, E/A und Netzwerkverkehr für den restlichen Workload verringern.

Gegenmaßnahmen

Erstellen Sie die Tabellen neu, um die verknüpften Tabellenspalten zu korrigieren, die nicht über identischen Datentyp und die gleiche Größe verfügen.


Ad-hoc-Abfragen für externe Tabellen

Abfragen für externe Tabellen sind mit der Absicht konzipiert, Daten in den dedizierten SQL-Pool zu laden. Ad-hoc-Abfragen für externe Tabellen könnten aufgrund externer Faktoren, wie z. B. gleichzeitigen Speichercontaineraktivitäten, variable Ausführungszeiten aufweisen.

Gegenmaßnahmen

Laden Sie Zuerst Daten in den dedizierten SQL-Pool, und fragen Sie dann die geladenen Daten ab.


Datenneigung (gespeichert)

Daten-Skew bedeutet, dass die Daten nicht gleichmäßig über die Verteilungen verteilt sind. Jeder Schritt des verteilten Plans erfordert, dass alle Verteilungen abgeschlossen werden müssen, bevor sie zum nächsten Schritt wechseln. Wenn Ihre Daten schief sind, kann das volle Potenzial der Verarbeitungsressourcen, z. B. CPU und E/A, nicht erreicht werden, was zu langsameren Ausführungszeiten führt.

Gegenmaßnahmen

Lesen Sie unsere Anleitungen für verteilte Tabellen , um Ihre Auswahl einer geeigneteren Verteilungsspalte zu unterstützen.


In-Flight-Daten-Schräglage

In-Flight-Datenverknüfung ist eine Variante des Datenverknüfungsproblems (gespeichert). Aber es ist nicht die Verteilung von Daten auf dem Datenträger, die schief ist. Die Art des verteilten Plans für spezifische Filter oder gruppierte Daten verursacht einen Vorgang vom Typ ShuffleMoveOperation. Dieser Vorgang erzeugt eine schiefe Ausgabe, die für nachgelagerte Prozesse verbraucht wird.

Gegenmaßnahmen

  • Stellen Sie sicher, dass Statistiken erstellt und auf dem neuesten Stand sind. Sie können deren Genauigkeit überprüfen, indem Sie die in der Überprüfungsstatistikgenauigkeit für einen dedizierten SQL-Pool beschriebenen Schritte ausführen.
  • Ändern Sie die Reihenfolge Ihrer GROUP BY Spalten, sodass eine Spalte mit höherer Kardinalität an erster Stelle steht.
  • Erstellen Sie mehrspaltige Statistiken, wenn Verknüpfungen mehrere Spalten abdecken.
  • Fügen Sie Ihrer Abfrage Einen OPTION(FORCE_ORDER) Abfragehinweis hinzu.
  • Umgestalten Sie die Abfrage.

Wartetyp-Probleme

Wenn keines der oben genannten häufig auftretenden Probleme auf Ihre Abfrage zutrifft, bieten die Schritt 3-Daten die Möglichkeit, zu bestimmen, welche Wartetypen (in wait_type und wait_time) die Abfrageverarbeitung für den längsten ausgeführten Schritt beeinträchtigen. Es gibt eine große Anzahl von Wartetypen, und sie werden aufgrund ähnlicher Gegenmaßnahmen in verwandte Kategorien gruppiert. Führen Sie die folgenden Schritte aus, um die Wartekategorie Ihres Abfrageschritts zu finden:

  1. Identifizieren Sie die wait_type in Schritt 3, die am meisten Zeit beansprucht.
  2. Suchen Sie den Wartetyp in der Zuordnungstabelle für Wartekategorien, und identifizieren Sie die Wartekategorie, in der sie enthalten ist.
  3. Erweitern Sie den Abschnitt zur Wartekategorie aus der folgenden Liste für empfohlene Minderungsmaßnahmen.
Kompilierung

Führen Sie die folgenden Schritte aus, um Wartetypprobleme der Kompilierungskategorie zu beheben:

  1. Erstellen Sie Indizes für alle Objekte neu, die an der problematischen Abfrage beteiligt sind.
  2. Aktualisieren Sie Statistiken zu allen Objekten, die an der problematischen Abfrage beteiligt sind.
  3. Testen Sie die problematische Abfrage erneut, um zu überprüfen, ob das Problem weiterhin besteht.

Wenn das Problem weiterhin besteht, gehen Sie wie vor:

  1. Erstellen Sie eine .sql Datei mit:

    SET QUERY_DIAGNOSTICS ON; <Your_SQL>; SET QUERY_DIAGNOSTICS OFF;

  2. Öffnen Sie ein Eingabeaufforderungsfenster, und führen Sie den folgenden Befehl aus:

    sqlcmd −S <servername>.database.windows.net −d <databasename> −U <username> −G −I −i .\<sql_file_name>.sql −y0 −o .\<output_file_name>.txt

  3. Öffnen Sie <output_file_name>.txt in einem Text-Editor. Suchen und kopieren Sie die Ausführungspläne auf Verteilungsebene (Zeilen, die mit <ShowPlanXML> beginnen) vom in Schritt 2 identifizierten längsten Schritt in separate Textdateien und fügen Sie sie mit einer .sqlplan-Erweiterung ein.

    Hinweis: Jeder Schritt des verteilten Plans hat in der Regel 60 Ausführungspläne auf Verteilungsebene aufgezeichnet. Stellen Sie sicher, dass Sie Ausführungspläne aus demselben verteilten Planschritt vorbereiten und vergleichen.

  4. Die Schritt 3-Abfrage zeigt häufig einige Verteilungen an, die viel länger dauern als andere. Vergleichen Sie in SQL Server Management Studio die Ausführungspläne auf Verteilungsebene (aus den erstellten SQLPLAN-Dateien ) einer lang andauernden Verteilung mit einer schnell ausgeführten Verteilung, um potenzielle Ursachen für Unterschiede zu analysieren.

Sperre, Arbeitsthread
  • Erwägen Sie das Ändern von Tabellen, die häufigen, kleinen Änderungen unterzogen werden, um einen Zeilenspeicherindex anstelle von CCI zu verwenden.
  • Stapeln Sie Ihre Änderungen, und aktualisieren Sie das Ziel mit mehr Zeilen auf einer weniger häufigen Basis.
Puffer-I/O, andere Datenträger-I/O, Transaktionsprotokoll-I/O

Ungesunde CCIs

Nicht optimale CCIs tragen zu einer erhöhten Ein-/Ausgabe-, CPU- und Speicherzuordnung bei, was wiederum die Abfrageleistung negativ beeinflusst. Um dieses Problem zu beheben, probieren Sie eine der folgenden Methoden aus:

Veraltete Statistiken

Veraltete Statistiken können dazu führen, dass ein nicht optimierter verteilter Plan generiert wird, der mehr Datenbewegungen erfordert als nötig. Unnötige Datenverschiebung erhöht die Belastung nicht nur für Ruhedaten, sondern auch für die tempdb. Da E/A eine gemeinsam genutzte Ressource für alle Abfragen ist, kann die Leistungseinbuße die gesamte Workload betreffen.

Der Optimierer basiert auf Statistiken, um die Anzahl der Zeilen zu schätzen, die von einer Abfrage zurückgegeben werden. Statistiken ermöglichen es dem Abfrageoptimierer, den effizientesten Plan auszuwählen oder die beste Verschiebungsoperation (z. B. eine "Shuffle Move Operation" oder "Broadcast Move Operation") durchzuführen, um die Daten bei der Erfüllung der Verknüpfungsbedingung auszurichten. Die beste Verknüpfungsbedingung hängt vom Tabellenverteilungstyp ab.

Wenn beispielsweise die tatsächliche Anzahl von Zeilen für eine angegebene Tabelle 60 Millionen beträgt und die geschätzte Anzahl von Zeilen 1.000 (auf der Ebene des Kontrollknotens) beträgt, kann der Optimierer eine Broadcast-Verschiebung auswählen. Dieses Verhalten liegt daran, dass die Kosten im Vergleich zu einer Shuffle Move niedriger wahrgenommen werden, da die Optimierer davon ausgehen, dass die Tabelle nur 1.000 Zeilen enthält. Sobald jedoch die tatsächliche Ausführung beginnt, wird die Engine 60 Millionen Zeilen im Rahmen der Ausführung mittels einer Broadcast-Bewegung übertragen, was angesichts sowohl der Datengröße als auch der Zeilenanzahl ein kostspieliger Vorgang sein kann. Wenn die Datengröße erheblich ist, kann dies zu Leistungsproblemen für die Abfrage selbst und andere Abfragen führen, was zu einer hohen CPU-Auslastung führt.

Um diese Situation zu beheben, stellen Sie sicher, dass alle Statistiken auf dem neuesten Stand sind und ein Wartungsplan vorhanden ist, um sie für Benutzerworkloads auf dem neuesten Stand zu halten. Sie können die Genauigkeit der Statistiken überprüfen, indem Sie die in der Überprüfungsstatistikgenauigkeit für einen dedizierten SQL-Pool beschriebenen Schritte ausführen.

Hohe E/A-Arbeitslasten

Ihre Gesamtarbeitsbelastung könnte darin bestehen, große Datenmengen zu lesen. Dedizierte Synapse SQL-Pools skalieren Ressourcen entsprechend der DWU. Um eine bessere Leistung zu erzielen, sollten Sie entweder oder beides in Betracht ziehen:

CPU, Parallelität
Szenario Risikoabschwaechung
Schlechte CCI-Gesundheit Bewerten und korrigieren des Zustands von geclusterten Columnstore-Indizes in einem dedizierten SQL Pool
Benutzerabfragen enthalten Transformationen Verschieben sie alle Formatierungs- und andere Transformationslogik in ETL-Prozesse, damit die formatierten Versionen gespeichert werden.
Die Arbeitslast wurde nicht angemessen priorisiert Implementierung der Workload-Isolation
Unzureichende DWU für Arbeitslast Erwägen Sie , Rechenressourcen zu erhöhen

Netzwerk-IO

Wenn das Problem während eines RETURN Vorgangs in Schritt 2 auftritt,

  • Verringern Sie die Anzahl gleichzeitiger paralleler Prozesse.
  • Skalieren Sie den am stärksten betroffenen Prozess auf einen anderen Client.

Bei allen anderen Datenverschiebungsvorgängen ist es wahrscheinlich, dass die Netzwerkprobleme innerhalb des dedizierten SQL-Pools auftreten. Führen Sie die folgenden Schritte aus, um dieses Problem schnell zu beheben:

  1. Skalieren Ihres dedizierten SQL-Pools auf DW100c
  2. Zurückskalieren wieder auf die gewünschte DWU-Ebene
SQL CLR

Vermeiden Sie die häufige Verwendung der FORMAT() Funktion, indem Sie eine alternative Methode zum Transformieren der Daten implementieren (z. B. CONVERT() mit Formatvorlage).


  • Last updated on