Problembehandlung bei einer langsamen Abfrage in einem dedizierten SQL-Pool

  • Artikel

Gilt für: Azure Synapse Analytics

Dieser Artikel hilft Ihnen, die Gründe für häufige Leistungsprobleme bei Abfragen in einem dedizierten SQL-Pool von Azure Synapse Analytics zu identifizieren und Abhilfemaßnahmen anzuwenden.

Führen Sie die Schritte zum Beheben des Problems aus, oder führen Sie die Schritte im Notebook über Azure Data Studio aus. Die ersten drei Schritte führen Sie durch das Sammeln von Telemetriedaten, die den Lebenszyklus einer Abfrage beschreibt. Die Referenzen am Ende des Artikels helfen Ihnen bei der Analyse potenzieller Möglichkeiten, die in den gesammelten Daten gefunden werden.

Hinweis

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

Öffnen des Notebooks in Azure Data Studio

Wichtig

Die meisten der gemeldeten Leistungsprobleme werden verursacht durch:

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

Um Zeit zur Problembehandlung zu sparen, stellen Sie sicher, dass die Statistiken erstellt und auf dem neuesten Stand sind und CCIs neu erstellt wurden.

Schritt 1: Identifizieren der request_id (qid)

Der request_id der langsamen Abfrage ist erforderlich, um mögliche Gründe für eine langsame Abfrage zu untersuchen. 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.

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

Verwenden Sie beim Ausführen des Skripts die folgenden Tipps, um die langsamen Abfragen besser zu erreichen:

  • Sortieren Sie nach submit_time DESC oder total_elapsed_time DESC , um die abfragen mit der längsten Ausführungszeit am Anfang des Resultsets zu erhalten.

  • Verwenden Sie in Ihren Abfragen, und filtern Sie OPTION(LABEL='<YourLabel>') dann die label Spalte, um sie zu identifizieren.

  • Erwägen Sie, alle QIDs herauszufiltern, die keinen Wert für resource_allocation_percentage haben, wenn Sie wissen, dass die Ziel-Anweisung in einem Batch enthalten ist.

    Hinweis: Seien Sie mit diesem Filter vorsichtig, da er möglicherweise auch einige Abfragen herausfiltert, die von anderen Sitzungen blockiert werden.

Schritt 2: Bestimmen, 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 zu erhalten. Notieren Sie sich die StepIndexWerte , Phaseund Description des langsamen Schritts, der aus dem Resultset identifiziert wird.

Parameter Beschreibung
@QID Der request_id in Schritt 1 abgerufene Wert
@ShowActiveOnly 0 – Anzeigen aller Schritte für die Abfrage
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 Verteilungszeitpunkte zu vergleichen. Notieren Sie sich den wait_type Wert für die Verteilung, der 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 – Alle Verteilungen für den angegebenen StepIndex Wert anzeigen
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: Diagnose und Entschärfung

Probleme bei der Kompilierungsphase

Blockiert: Kompilierungsparallelität

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

Entschärfungen

Reduzieren Sie die Anzahl der gleichzeitig gesendeten Abfragen.


Blockiert: Ressourcenzuordnung

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

  • Die Menge des gewährten Arbeitsspeichers basierend auf der Ressourcenklasse oder Arbeitsauslastungsgruppenzuweisung, die dem Benutzer zugeordnet ist.
  • Die Menge des verfügbaren Arbeitsspeichers auf dem System oder der Arbeitsauslastungsgruppe.
  • (Optional) Die Workloadgruppen-/Klassifiziererpriorität.

Entschärfungen

Komplexe Abfrage oder ältere JOIN-Syntax

Möglicherweise tritt eine Situation auf, in der sich die Standardmäßigen Abfrageoptimierermethoden als ineffektiv erweisen, da die Kompilierungsphase sehr lange dauert. Dies kann auftreten, wenn die Abfrage:

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

Obwohl diese Szenarien atypisch sind, können Sie versuchen, das Standardverhalten zu überschreiben, um die Zeit zu verkürzen, die der Abfrageoptimierer benötigt, um einen Plan auszuwählen.

Entschärfungen

  • Verwenden Sie ANSI-92-Stiljoins.
  • Hinzufügen von Abfragehinweisen: OPTION(FORCE ORDER, USE HINT ('FORCE_LEGACY_CARDINALITY_ESTIMATION')). Weitere Informationen finden Sie unter FORCE ORDER und Kardinalitätsschätzung (SQL Server).
  • Unterteilen Sie die Abfrage in mehrere, weniger komplexe Schritte.
DROP TABLE oder TRUNCATE TABLE mit langer Ausführungszeit

Aus Gründen der Effizienz der Ausführungszeit verschieben die Anweisungen und TRUNCATE TABLE die DROP TABLE Speicherbereinigung auf einen Hintergrundprozess. Wenn Ihre Workload jedoch eine große Anzahl von DROP/TRUNCATE TABLE Anweisungen in einem kurzen Zeitrahmen ausführt, ist es möglich, dass die Metadaten überlastet werden und nachfolgende DROP/TRUNCATE TABLE Anweisungen langsam ausgeführt werden.

Entschärfungen

Identifizieren Sie ein Wartungsfenster, beenden Sie alle Workloads, und führen Sie DBCC SHRINKDATABASE aus, um eine sofortige Bereinigung zuvor gelöschter oder abgeschnittener Tabellen zu erzwingen.


Fehlerhafte CCIs (allgemein)

Eine schlechte Integrität des gruppierten Columnstore-Indexes (CCI) erfordert zusätzliche Metadaten, was dazu führen kann, dass der Abfrageoptimierer mehr Zeit in Anspruch nimmt, um einen optimalen Plan zu bestimmen. Um diese Situation zu vermeiden, stellen Sie sicher, dass alle Ihre CCIs in gutem Zustand sind.

Entschärfungen

Bewerten und korrigieren Sie die Integrität des gruppierten Columnstore-Indexes 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 Entscheidungen für verteilte Pläne treffen kann. Der automatische Erstellungsprozess selbst kann jedoch dazu führen, dass eine anfängliche Abfrage länger dauert als nachfolgende Ausführungen derselben.

Entschärfungen

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


Timeouts für die automatische Erstellung von Statistiken

Die Option zum automatischen Erstellen von Statistiken ist ON standardmäßig, um sicherzustellen, AUTO_CREATE_STATISTICS dass der Abfrageoptimierer gute Entscheidungen für verteilte Pläne treffen kann. Die automatische Erstellung von Statistiken erfolgt als Reaktion auf eine SELECT-Anweisung und weist einen Schwellenwert von 5 Minuten auf. Wenn die Größe der Daten und/oder die Anzahl der zu erstellenden Statistiken länger als der 5-Minuten-Schwellenwert erfordert, wird die automatische Erstellung von Statistiken abgebrochen, damit die Ausführung der Abfrage fortgesetzt werden 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.

Entschärfungen

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

Probleme mit der Ausführungsphase

  • Verwenden Sie die folgende Tabelle, um das Resultset in Schritt 2 zu analysieren. Bestimmen Sie Ihr Szenario, und überprüfen Sie die häufige Ursache für detaillierte Informationen und mögliche Schritte zur Entschärfung.

    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 zwischen Tabellen nicht 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 ist zwischen den 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, auf zugeordnet step_id , indem Sie jeweils den folgenden Befehl ausführen:

      DBCC PDW_SHOWSPACEUSED(<table>);

    2. Wenn <mindester Zeilenwert>/<Maximale Zeilenwert>> 0,1 ist, wechseln Sie zu Datenschiefe (gespeichert).

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

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.

Entschärfungen

Erstellen/Aktualisieren von Statistiken.


Nicht zwischengespeicherte replizierte Tabellen

Wenn Sie replizierte Tabellen erstellt haben und der Cache der replizierten Tabelle nicht ordnungsgemäß aufgewärmt werden kann, führt eine unerwartete schlechte Leistung aufgrund zusätzlicher Datenverschiebungen oder der Erstellung eines suboptimalen verteilten Plans.

Entschärfungen

Nicht übereinstimmender Datentyp/Größe

Stellen Sie beim Verknüpfen von Tabellen sicher, dass der Datentyp und die Größe der verknüpften Spalten übereinstimmen. Andernfalls führt dies zu unnötigen Datenverschiebungen, die die Verfügbarkeit von CPU-, E/A- und Netzwerkdatenverkehr für den Rest der Workload verringern.

Entschärfungen

Erstellen Sie die Tabellen neu, um die zugehörigen Tabellenspalten zu korrigieren, die nicht denselben Datentyp und die gleiche Größe aufweisen.


Ad-hoc-Abfragen für externe Tabellen

Abfragen für externe Tabellen werden mit der Absicht entworfen, Daten in den dedizierten SQL-Pool zu laden. Ad-hoc-Abfragen für externe Tabellen können aufgrund externer Faktoren, z. B. gleichzeitiger Speichercontaineraktivitäten, eine variable Dauer aufweisen.

Entschärfungen

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


Datenschiefe (gespeichert)

Datenschiefe bedeutet, dass die Daten nicht gleichmäßig auf die Verteilungen verteilt sind. Jeder Schritt des verteilten Plans erfordert, dass alle Verteilungen abgeschlossen werden, bevor mit dem nächsten Schritt fortzufahren. Wenn Ihre Daten schief sind, kann das volle Potenzial der Verarbeitungsressourcen wie CPU und E/A nicht erreicht werden, was zu langsameren Ausführungszeiten führt.

Entschärfungen

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


In-Flight-Datenschiefe

Datenschiefe in-Flight ist eine Variante des (gespeicherten) Datenschiefeproblems . Es ist jedoch 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 genutzt werden soll.

Entschärfungen

  • Stellen Sie sicher, dass Statistiken erstellt und auf dem neuesten Stand sind.
  • Ändern Sie die Reihenfolge Ihrer GROUP BY Spalten, um mit einer Spalte mit höherer Kardinalität zu führen.
  • Erstellen Sie statistiken mit mehreren Spalten, wenn Joins mehrere Spalten abdecken.
  • Fügen Sie Ihrer Abfrage einen Abfragehinweis hinzu OPTION(FORCE_ORDER) .
  • Umgestalten sie die Abfrage.

Wartetypprobleme

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

  1. Identifizieren Sie den wait_type in Schritt 3 , der die meiste Zeit in Anspruch nimmt.
  2. Suchen Sie den Wartetyp in der Zuordnungstabelle der Wartekategorien , und identifizieren Sie die Wartekategorie, in der er enthalten ist.
  3. Erweitern Sie den Abschnitt, der sich auf die Wartekategorie bezieht, aus der folgenden Liste, um empfohlene Risikominderungen zu erhalten.
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 für alle Objekte, 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, dann:

  1. Erstellen Sie eine .sql-Datei mit:

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

  2. Führen Sie in einem Eingabeaufforderungsfenster 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) aus dem in Schritt 2 identifizierten Schritt mit der längsten Ausführungszeit in separate Textdateien mit der Erweiterung SQLPLAN .

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

  4. Die Abfrage von Schritt 3 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 Verteilung mit langer Laufzeit mit einer schnell ausgeführten Verteilung, um mögliche Ursachen für Unterschiede zu analysieren.

Sperren, Arbeitsthread
  • Erwägen Sie das Ändern von Tabellen, die häufigen, kleinen Änderungen unterliegen, um einen Zeilenspeicherindex anstelle von CCI zu verwenden.
  • Führen Sie ein Batch für Ihre Änderungen aus, und aktualisieren Sie das Ziel seltener mit mehr Zeilen.
Puffer-E/A, andere Datenträger-E/A, Tranprotokoll-E/A

Fehlerhafte CCIs

Fehlerhafte CCIs tragen zu einer höheren E/A-, CPU- und Arbeitsspeicherbelegung bei, was sich wiederum negativ auf die Abfrageleistung auswirkt. Um dieses Problem zu beheben, probieren Sie eine der folgenden Methoden aus:

Veraltete Statistiken

Veraltete Statistiken können zur Generierung eines nicht optimierten verteilten Plans führen, der mehr Datenverschiebungen als erforderlich erfordert. Unnötige Datenverschiebungen erhöhen die Workload nicht nur für Ihre ruhenden Daten, sondern auch für .tempdb Da E/A eine gemeinsam genutzte Ressource für alle Abfragen ist, können Sich auf die Leistung der gesamten Workload auswirken.

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 Gesamtworkload kann das Lesen großer Datenmengen sein. Dedizierte Synapse SQL-Pools skalieren Ressourcen entsprechend der DWU. Um eine bessere Leistung zu erzielen, sollten Sie eine oder beides in Betracht ziehen:

CPU, Parallelität
Szenario Risikominderung
Schlechte CCI-Gesundheit Bewerten und Korrigieren der Integrität von gruppierten Columnstore-Indizes in einem dedizierten SQL-Pool
Benutzerabfragen enthalten Transformationen Verschieben sie die gesamte Formatierung und andere Transformationslogik in ETL-Prozesse, damit die formatierten Versionen gespeichert werden.
Workload falsch priorisiert Implementieren der Workloadisolation
Unzureichende DWU für Workload Erwägen der Erhöhung von Computeressourcen

Netzwerk-E/A

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

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

Bei allen anderen Datenverschiebungsvorgängen ist es wahrscheinlich, dass die Netzwerkprobleme im dedizierten SQL-Pool intern zu sein scheinen. Führen Sie die folgenden Schritte aus, um dieses Problem schnell zu beheben:

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

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