Freigeben über

Problembehandlung bei langsamen Abfragen in einem dedizierten SQL-Pool

  • Artikel

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 oder die Schritte im Notizbuch über Azure Data Studio auszuführen. 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.

Notiz

Bevor Sie versuchen, dieses Notizbuch zu öffnen, stellen Sie sicher, dass Azure Data Studio auf Ihrem lokalen Computer installiert ist. Informationen zum Installieren von Azure Data Studio finden Sie unter "Informationen zum Installieren von Azure Data Studio".

Notebook in Azure Data Studio öffnen

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 aktuell und CCIs neu erstellt wurden.

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

Die request_id langsame Abfrage ist erforderlich, um potenzielle Gründe für eine langsame 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 nach unten.

-- 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;

-- 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 nach den submit_time DESC total_elapsed_time DESC am längsten ausgeführten Abfragen oben im Resultset.

  • Verwenden Sie sie in Ihren Abfragen, und filtern Sie OPTION(LABEL='<YourLabel>') 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.

    Hinweis: 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 in 0, um das vollständige Bild des verteilten Plans abzurufen. Notieren Sie sich die StepIndexWerte Phaseund Description Werte des langsamen Schritts, der aus dem Resultset identifiziert wird.

Parameter Beschreibung
@QID Der request_id in Schritt 1 abgerufene Wert
@ShowActiveOnly 0 – Alle Schritte für die Abfrage anzeigen
1 – Nur den aktuell aktiven Schritt anzeigen		 
DECLARE @QID VARCHAR(16) = '<request_id>', @ShowActiveOnly BIT = 1; 
-- Retrieve session_id of QID
DECLARE @session_id 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 waiting
   INNER JOIN sys.dm_pdw_waits blocking
      ON waiting.object_type = blocking.object_type
      AND waiting.object_name = blocking.object_name
   INNER JOIN sys.dm_pdw_exec_requests 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 Verteilungszeitdauern zu vergleichen. Notieren Sie sich den wait_type Wert für die Verteilung, die das Leistungsproblem verursachen kann.

Parameter Beschreibung
@QID Der request_id in Schritt 1 abgerufene Wert
@StepIndex Der StepIndex in Schritt 2 identifizierte Wert
@ShowActiveOnly 0 – Anzeigen aller Verteilungen für den angegebenen StepIndex Wert
1 – Nur die derzeit aktiven Verteilungen für den angegebenen StepIndex Wert anzeigen		 
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: Kompilierungskoncurrency

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 des vom Benutzer zugewiesenen Arbeitsspeichers basierend auf der Ressourcenklassen- oder Workloadgruppenzuordnung.
  • Die Menge des verfügbaren Arbeitsspeichers in der System- oder Workloadgruppe.
  • (Optional) Die Workloadgruppen-/Klassifizierer-Wichtigkeit.

Gegenmaßnahmen

  • Warten Sie, bis die blockierende Sitzung abgeschlossen ist.
  • Wertet die Auswahl der Ressourcenklasse aus. Weitere Informationen finden Sie unter Parallelitätsgrenzwerte.
  • Bewerten Sie, ob es vorzuziehen ist, die Blockierungssitzung zu beenden.
Komplexe Abfrage oder ältere JOIN-Syntax

Es kann vorkommen, dass die Standardmäßigen Abfrageoptimierermethoden unwirksam sind, da die Kompilierungsphase sehr lange dauert. Die Abfrage kann auftreten:

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

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-Stilverknnungen.
  • Abfragehinweise hinzufügen: OPTION(FORCE ORDER, USE HINT ('FORCE_LEGACY_CARDINALITY_ESTIMATION')). Weitere Informationen finden Sie unter FORCE ORDER and Cardinality Estimation (SQL Server).For more information, see FORCE ORDER and Cardinality Estimation (SQL Server).
  • Unterteilen Sie die Abfrage in mehrere, weniger komplexe Schritte.
Lange laufende DROP TABLE oder TRUNCATE TABLE

Zur Effizienz der Ausführungszeit verzögern die Anweisungen TRUNCATE TABLE die DROP TABLE Speicherbereinigung auf 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)

Für einen schlechten Clusterspeicherindex (Clustered ColumnStore Index, CCI) sind zusätzliche Metadaten erforderlich. Dies kann dazu führen, dass 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 ON standardmäßig, um sicherzustellen, AUTO_CREATE_STATISTICS 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 für automatische Erstellung von Statistiken

Die Option zum automatischen Erstellen von Statistiken ist ON standardmäßig, um sicherzustellen, AUTO_CREATE_STATISTICS 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. Der Fehler beim Erstellen der Statistiken kann sich negativ auf die Fähigkeit des Abfrageoptimierers auswirken, einen effizienten verteilten Ausführungsplan zu generieren, was zu einer schlechten Abfrageleistung führt.

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 das Resultset in Schritt 2 zu analysieren. Ermitteln Sie Ihr Szenario, und überprüfen Sie die häufige Ursache für detaillierte Informationen und die möglichen Gegenmaßnahmen.

    Szenario Häufige 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 Joinerspalten sind nicht zwischen Tabellen identisch.    		 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 für jede Tabelle, auf die TSQL im Feld verwiesen wird, für die zugeordnet step_id ist, indem Sie den folgenden Befehl für jeden ausführen:

      DBCC PDW_SHOWSPACEUSED(<table>);

    2. Wenn <der Wert für minimale Zeilen/<maximale Zeilenwerte>>> 0,1 beträgt, wechseln Sie zu "Datenverknen (gespeichert)".

    3. Wechseln Sie andernfalls zu "In-Flight-Datenverknüppung".

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

Erstellen/Aktualisieren von Statistiken.


Nicht zwischengespeicherte replizierte Tabellen

Wenn Sie replizierte Tabellen erstellt haben und der replizierte Tabellencache nicht ordnungsgemäß warm wird, führt unerwartete schlechte Leistung aufgrund zusätzlicher Datenverschiebungen oder der Erstellung eines suboptimalen verteilten Plans.

Gegenmaßnahmen

  • Warm the replid cache after DML operations.
  • Wenn häufige DML-Vorgänge vorhanden sind, ändern Sie die Verteilung der Tabelle in ROUND_ROBIN.
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 Netzwerkdatenverkehr bis zum Rest der 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önnen aufgrund externer Faktoren, wie z. B. gleichzeitige Speichercontaineraktivitäten, variable Dauern leiden.

Gegenmaßnahmen

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


Datenneigung (gespeichert)

Datenneigung bedeutet, dass die Daten nicht gleichmäßig über die Verteilung verteilt werden. 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-Datenverknükung

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 bestimmte Filter oder gruppierte Daten verursacht einen ShuffleMoveOperation Typvorgang. Dieser Vorgang erzeugt eine schiefe Ausgabe, die nachgeschaltet werden soll.

Gegenmaßnahmen

  • Stellen Sie sicher, dass Statistiken erstellt und aktuell sind.
  • Ändern Sie die Reihenfolge Ihrer GROUP BY Spalten, um mit einer Spalte mit höherer Kardinalität zu führen.
  • 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.

Probleme beim Warten des Typs

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 die meiste Zeit in Anspruch nimmt.
  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 im Zusammenhang mit der Wartekategorie aus der folgenden Liste für empfohlene Entschärfungen.
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>) aus dem in Schritt 2 identifizierten längsten Schritt in separate Textdateien mit einer SQLPLAN-Erweiterung einfügen.

    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.

Sperren, 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-E/A, andere Datenträger-E/A, Tranprotokoll-E/A

Fehlerhafte CCIs

Fehlerhafte CCIs tragen zu einer erhöhten E/A-, 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 Arbeitsauslastung nicht nur für Ruhedaten, sondern auch für die tempdb. Da E/A eine gemeinsam genutzte Ressource für alle Abfragen ist, können Leistungsbeeinträchtigungen von der gesamten Workload beeinflusst werden.

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.

Hohe E/A-Workloads

Ihre Gesamtarbeitsauslastung kann große Datenmengen 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 Minderung
Schlechte CCI-Integrität 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.
Workload nicht ordnungsgemäß priorisiert Implementieren der Workloadisolation
Unzureichende DWU für Workload Erwägen Sie , Rechenressourcen zu erhöhen

Netzwerk-E/A

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 häufig die Verwendung der FORMAT() Funktion, indem Sie eine alternative Methode zum Transformieren der Daten implementieren (z CONVERT() . B. mit Formatvorlage).