Share via

Rozwiązywanie problemów z powolnym zapytaniem w dedykowanej puli SQL

  • Artykuł

Dotyczy: Azure Synapse Analytics

Ten artykuł pomaga zidentyfikować przyczyny i zastosować środki zaradcze w przypadku typowych problemów z wydajnością zapytań w dedykowanej puli SQL usługi Azure Synapse Analytics.

Wykonaj kroki, aby rozwiązać ten problem lub wykonaj kroki w notesie za pośrednictwem usługi Azure Data Studio. Pierwsze trzy kroki przeprowadzą Cię przez zbieranie danych telemetrycznych, które opisują cykl życia zapytania. Odwołania na końcu artykułu ułatwiają analizowanie potencjalnych możliwości znalezionych w zbieranych danych.

Uwaga

Przed podjęciem próby otwarcia tego notesu upewnij się, że usługa Azure Data Studio jest zainstalowana na komputerze lokalnym. Aby go zainstalować, przejdź do artykułu Dowiedz się, jak zainstalować usługę Azure Data Studio.

Otwieranie notesu w usłudze Azure Data Studio

Ważna

Większość zgłoszonych problemów z wydajnością jest spowodowana przez:

  • Nieaktualne statystyki
  • Indeksy magazynu kolumn w złej kondycji klastra (CCI)

Aby zaoszczędzić czas rozwiązywania problemów, upewnij się, że zostały utworzone statystyki oraz że zostały utworzone aktualne i ccis zostały odbudowane.

Krok 1. Identyfikowanie request_id (aka QID)

Wolne request_id zapytanie jest wymagane do zbadania potencjalnych przyczyn powolnego zapytania. Użyj następującego skryptu jako punktu wyjścia do identyfikowania zapytania, które chcesz rozwiązać. Po zidentyfikowaniu powolnego zapytania zanotuj request_id wartość.

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

Aby lepiej kierować wolne zapytania, użyj następujących wskazówek podczas uruchamiania skryptu:

  • Sortuj według submit_time DESC lub total_elapsed_time DESC , aby najdłużej działające zapytania były obecne w górnej części zestawu wyników.

  • Użyj polecenia OPTION(LABEL='<YourLabel>') w zapytaniach, a następnie przefiltruj kolumnę, label aby je zidentyfikować.

  • Rozważ odfiltrowanie wszystkich identyfikatorów QID, które nie mają wartości, resource_allocation_percentage gdy wiesz, że instrukcja docelowa jest zawarta w partii.

    Uwaga: Należy zachować ostrożność w przypadku tego filtru, ponieważ może on również odfiltrować niektóre zapytania, które są blokowane przez inne sesje.

Krok 2. Określanie, gdzie zapytanie zajmuje czas

Uruchom następujący skrypt, aby znaleźć krok, który może spowodować problem z wydajnością zapytania. Zaktualizuj zmienne w skryptze przy użyciu wartości opisanych w poniższej tabeli. @ShowActiveOnly Zmień wartość na 0, aby uzyskać pełny obraz planu rozproszonego. Zanotuj StepIndexwartości , Phasei Description powolnego kroku zidentyfikowanego z zestawu wyników.

Parametr Opis
@QID Wartość uzyskana request_id w kroku 1
@ShowActiveOnly 0 — Pokaż wszystkie kroki dla zapytania
1 — Pokaż tylko aktualnie aktywny krok		 
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;

Krok 3. Przeglądanie szczegółów kroku

Uruchom następujący skrypt, aby przejrzeć szczegóły kroku zidentyfikowanego w poprzednim kroku. Zaktualizuj zmienne w skryptze przy użyciu wartości opisanych w poniższej tabeli. @ShowActiveOnly Zmień wartość na 0, aby porównać wszystkie chronometraż rozkładu. Zanotuj wait_type wartość dystrybucji, która może powodować problem z wydajnością.

Parametr Opis
@QID Wartość uzyskana request_id w kroku 1
@StepIndex Wartość StepIndex zidentyfikowana w kroku 2
@ShowActiveOnly 0 — Pokaż wszystkie rozkłady dla danej StepIndex wartości
1 — pokaż tylko aktualnie aktywne dystrybucje dla danej StepIndex wartości		 
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

Krok 4. Diagnozowanie i eliminowanie

Problemy z fazą kompilacji

Zablokowane: współbieżność kompilacji

Bloki kompilacji współbieżności rzadko występują. Jeśli jednak wystąpi ten typ bloku, oznacza to, że duża liczba zapytań została przesłana w krótkim czasie i została w kolejce, aby rozpocząć kompilację.

Czynniki

Zmniejsz jednocześnie liczbę przesłanych zapytań.


Zablokowane: alokacja zasobów

Zablokowanie alokacji zasobów oznacza, że zapytanie oczekuje na wykonanie na podstawie:

  • Ilość pamięci przyznanej na podstawie klasy zasobów lub przypisania grupy obciążeń skojarzonego z użytkownikiem.
  • Ilość dostępnej pamięci w systemie lub grupie obciążeń.
  • (Opcjonalnie) Ważność grupy/klasyfikatora obciążenia.

Czynniki

Złożone zapytanie lub starsza składnia JOIN

Może wystąpić sytuacja, w której domyślne metody optymalizatora zapytań są nieskuteczne, ponieważ faza kompilacji zajmuje dużo czasu. Może się to zdarzyć, jeśli zapytanie:

  • Obejmuje dużą liczbę sprzężeń i/lub podzapytów (złożone zapytanie).
  • Wykorzystuje sprzężenia w klauzuli FROM (nie sprzężenia stylu ANSI-92).

Chociaż te scenariusze są nietypowe, masz opcje, aby spróbować zastąpić zachowanie domyślne, aby skrócić czas potrzebny optymalizatorowi zapytań na wybranie planu.

Czynniki

  • Użyj sprzężeń stylu ANSI-92.
  • Dodaj wskazówki dotyczące zapytania: OPTION(FORCE ORDER, USE HINT ('FORCE_LEGACY_CARDINALITY_ESTIMATION')). Aby uzyskać więcej informacji, zobacz FORCE ORDER i Cardinality Estimation (SQL Server).
  • Podziel zapytanie na wiele, mniej złożonych kroków.
Długotrwała tabela DROP TABLE lub TRUNCATE TABLE

W przypadku wydajności czasu wykonywania instrukcje DROP TABLE i TRUNCATE TABLE odroczą oczyszczanie magazynu do procesu w tle. Jeśli jednak obciążenie wykonuje dużą liczbę DROP/TRUNCATE TABLE instrukcji w krótkim czasie, możliwe jest, że metadane stają się zatłoczone i powodują powolne wykonywanie kolejnych DROP/TRUNCATE TABLE instrukcji.

Czynniki

Zidentyfikuj okno obsługi, zatrzymaj wszystkie obciążenia i uruchom polecenie DBCC SHRINKDATABASE , aby wymusić natychmiastowe oczyszczanie wcześniej usuniętych lub obciętych tabel.


W złej kondycji ccis (ogólnie)

Słaba kondycja klastrowanego indeksu magazynu kolumn (CCI) wymaga dodatkowych metadanych, co może spowodować, że optymalizator zapytań będzie miał więcej czasu na określenie optymalnego planu. Aby uniknąć tej sytuacji, upewnij się, że wszystkie twoje ccis są w dobrym stanie zdrowia.

Czynniki

Ocena i poprawianie kondycji indeksu klastrowanego magazynu kolumn w dedykowanej puli SQL.


Opóźnienie w stosunku do statystyk automatycznego tworzenia

Opcja AUTO_CREATE_STATISTICSautomatycznego tworzenia statystyk domyślnie pomaga ON zapewnić, że optymalizator zapytań może podejmować dobre decyzje dotyczące planu rozproszonego. Jednak sam proces automatycznego tworzenia może sprawić, że początkowe zapytanie będzie trwać dłużej niż kolejne wykonania tego samego.

Czynniki

Jeśli pierwsze wykonanie zapytania stale wymaga utworzenia statystyk, należy ręcznie utworzyć statystyki przed wykonaniem zapytania.


Przekroczenia limitu czasu automatycznego tworzenia statystyk

Opcja AUTO_CREATE_STATISTICSautomatycznego tworzenia statystyk domyślnie pomaga ON zapewnić, że optymalizator zapytań może podejmować dobre decyzje dotyczące planu rozproszonego. Automatyczne tworzenie statystyk odbywa się w odpowiedzi na instrukcję SELECT i ma 5-minutowy próg do ukończenia. Jeśli rozmiar danych i/lub liczba utworzonych statystyk wymagają więcej niż 5-minutowy próg, automatyczne tworzenie statystyk zostanie porzucone, aby zapytanie było możliwe do kontynuowania wykonywania. Niepowodzenie tworzenia statystyk może negatywnie wpłynąć na zdolność optymalizatora zapytań do generowania wydajnego planu wykonywania rozproszonego, co powoduje niską wydajność zapytań.

Czynniki

Ręcznie utwórz statystyki , zamiast polegać na funkcji automatycznego tworzenia dla zidentyfikowanych tabel/kolumn.

Problemy z fazą wykonywania

  • Użyj poniższej tabeli, aby przeanalizować zestaw wyników w kroku 2. Określ swój scenariusz i sprawdź wspólną przyczynę, aby uzyskać szczegółowe informacje i możliwe kroki ograniczania ryzyka.

    Scenariusz Wspólna przyczyna
    EstimatedRowCount/ActualRowCount< 25% Niedokładne szacunki
    Wartość Description wskazuje BroadcastMoveOperation , a zapytanie odwołuje się do replikowanej tabeli. Nienadłużone zreplikowane tabele
    1. @ShowActiveOnly = 0
    2. Zaobserwowano dużą lub nieoczekiwaną liczbę kroków (step_index).
    3. Typy danych kolumn sprzężenia nie są identyczne między tabelami.    		 Niezgodny typ/rozmiar danych
    1. Wartość Description wskazuje HadoopBroadcastOperation, HadoopRoundRobinOperation lub HadoopShuffleOperation.
    2. Wartość total_elapsed_time danego step_index elementu jest niespójna między wykonaniami.    		 Zapytania dotyczące tabel zewnętrznych ad hoc

  • Sprawdź wartość uzyskaną total_elapsed_time w kroku 3. Jeśli w kilku dystrybucjach w danym kroku jest znacznie wyższa, wykonaj następujące kroki:

    1. Sprawdź rozkład danych dla każdej tabeli, do których odwołuje się w TSQL polu, dla skojarzonej step_id , uruchamiając następujące polecenie względem każdej z nich:

      DBCC PDW_SHOWSPACEUSED(<table>);

    2. Jeśli <minimalna wartość> wierszy/<maksymalna wartość>> wierszy to 0,1, przejdź do pozycji Niesymetryczność danych (przechowywana).

    3. W przeciwnym razie przejdź do obszaru Niesymetryczność danych podczas lotu.

Niedokładne szacunki

Zapewnij aktualność statystyk, aby upewnić się, że optymalizator zapytań generuje optymalny plan. Gdy szacowana liczba wierszy jest znacznie mniejsza niż rzeczywista liczba, należy zachować statystyki.

Czynniki

Tworzenie/aktualizowanie statystyk.


Nienadłużone zreplikowane tabele

Jeśli utworzono zreplikowane tabele i nie można prawidłowo ogrzać replikowanej pamięci podręcznej tabel, nieoczekiwana niska wydajność spowoduje dodatkowe przenoszenie danych lub utworzenie nieoptymalnego planu rozproszonego.

Czynniki

Niezgodny typ/rozmiar danych

Podczas łączenia tabel upewnij się, że typ danych i rozmiar kolumn sprzężenia są zgodne. W przeciwnym razie spowoduje to niepotrzebne przenoszenie danych, które zmniejszą dostępność procesora CPU, operacji we/wy i ruchu sieciowego do pozostałej części obciążenia.

Czynniki

Ponownie skompiluj tabele, aby poprawić powiązane kolumny tabeli, które nie mają identycznego typu danych i rozmiaru.


Zapytania dotyczące tabel zewnętrznych ad hoc

Zapytania względem tabel zewnętrznych są zaprojektowane z zamiarem zbiorczego ładowania danych do dedykowanej puli SQL. Zapytania ad hoc względem tabel zewnętrznych mogą mieć zmienne czasy trwania z powodu czynników zewnętrznych, takich jak współbieżne działania kontenera magazynu.

Czynniki

Najpierw załaduj dane do dedykowanej puli SQL , a następnie wykonaj zapytanie dotyczące załadowanych danych.


Niesymetryczność danych (przechowywana)

Niesymetryczność danych oznacza, że dane nie są dystrybuowane równomiernie między rozkładami. Każdy krok planu rozproszonego wymaga ukończenia wszystkich dystrybucji przed przejściem do następnego kroku. Gdy dane są niesymetryczne, nie można osiągnąć pełnego potencjału zasobów przetwarzania, takich jak procesor CPU i we/wy, co powoduje wolniejsze czasy wykonywania.

Czynniki

Zapoznaj się z naszymi wskazówkami dotyczącymi tabel rozproszonych , aby ułatwić wybór bardziej odpowiedniej kolumny dystrybucji.


Niesymetryczność danych podczas lotu

Niesymetryczność danych podczas lotu jest wariantem problemu z niesymetrycznością danych (przechowywaną ). Ale to nie rozkład danych na dysku jest niesymetryczny. Charakter planu rozproszonego dla określonych filtrów lub pogrupowanych danych powoduje operację ShuffleMoveOperation typu. Ta operacja generuje niesymetryczne dane wyjściowe do użycia w dół.

Czynniki

  • Upewnij się, że statystyki są tworzone i aktualne.
  • Zmień kolejność GROUP BY kolumn, aby prowadzić z kolumną o wyższej kardynalności.
  • Utwórz statystyki wielokolumnowe, jeśli sprzężenia obejmują wiele kolumn.
  • Dodaj wskazówkę dotyczącą OPTION(FORCE_ORDER) zapytania do zapytania.
  • Refaktoryzacja zapytania.

Problemy z typem oczekiwania

Jeśli żaden z powyższych typowych problemów nie dotyczy zapytania, dane kroku 3 dają możliwość określenia, które typy oczekiwania (w wait_type i wait_time) zakłócają przetwarzanie zapytań dla najdłużej działającego kroku. Istnieje duża liczba typów oczekiwania i są one pogrupowane w powiązane kategorie z powodu podobnych środków zaradczych. Wykonaj następujące kroki, aby zlokalizować kategorię oczekiwania w kroku zapytania:

  1. Zidentyfikuj wait_type element w kroku 3 , który zajmuje najwięcej czasu.
  2. Znajdź typ oczekiwania w tabeli mapowania kategorii oczekiwania i zidentyfikuj kategorię oczekiwania, w ramach która została uwzględniona.
  3. Rozwiń sekcję dotyczącą kategorii oczekiwania z poniższej listy, aby uzyskać zalecane środki zaradcze.
Kompilacji

Wykonaj następujące kroki, aby rozwiązać problemy z typem oczekiwania kategorii Kompilacja:

  1. Ponownie skompiluj indeksy dla wszystkich obiektów biorących udział w problematycznym zapytaniu.
  2. Zaktualizuj statystyki dotyczące wszystkich obiektów biorących udział w problematycznym zapytaniu.
  3. Ponownie przetestuj problematyczne zapytanie, aby sprawdzić, czy problem będzie się powtarzać.

Jeśli problem będzie się powtarzać, wykonaj następujące czynności:

  1. Utwórz plik .sql przy użyciu:

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

  2. Otwórz okno wiersza polecenia i uruchom następujące polecenie:

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

  3. Otwórz <output_file_name>.txt w edytorze tekstów. Znajdź i skopiuj plany wykonywania na poziomie dystrybucji (wiersze rozpoczynające się od <ShowPlanXML>) z najdłużej działającego kroku zidentyfikowanego w kroku 2 do oddzielnych plików tekstowych z rozszerzeniem sqlplan .

    Uwaga: Każdy krok planu rozproszonego zwykle zawiera 60 planów wykonywania na poziomie dystrybucji. Upewnij się, że przygotowujesz i porównujesz plany wykonywania z tego samego kroku planu rozproszonego.

  4. Zapytanie krok 3 często ujawnia kilka dystrybucji, które trwa znacznie dłużej niż inne. W SQL Server Management Studio porównaj plany wykonywania na poziomie dystrybucji (z utworzonych plików sqlplan) długotrwałej dystrybucji z szybką dystrybucją w celu przeanalizowania potencjalnych przyczyn różnic.

Blokada, wątek roboczy
  • Rozważ zmianę tabel, które przechodzą częste, niewielkie zmiany w celu wykorzystania indeksu magazynu wierszy zamiast CCI.
  • Utwórz partię zmian i zaktualizuj element docelowy rzadziej, korzystając z większej liczby wierszy.
Operacje we/wy buforu, inne operacje we/wy dysku, operacje we/wy dziennika trans

W złej kondycji ccis

W złej kondycji certyfikaty CCI przyczyniają się do zwiększenia alokacji operacji we/wy, procesora CPU i pamięci, co z kolei negatywnie wpływa na wydajność zapytania. Aby rozwiązać ten problem, wypróbuj jedną z następujących metod:

Nieaktualne statystyki

Nieaktualne statystyki mogą powodować generowanie niezoptymalizowanego planu rozproszonego, co wiąże się z większym przenoszeniem danych niż jest to konieczne. Niepotrzebne przenoszenie danych zwiększa obciążenie nie tylko dla danych magazynowanych, ale także w systemie tempdb. Ponieważ operacje we/wy są zasobem udostępnionym we wszystkich zapytaniach, wpływ na wydajność może być odczuwalny przez całe obciążenie.

Aby rozwiązać ten problem, upewnij się, że wszystkie statystyki są aktualne, a plan konserwacji jest w stanie aktualizować je dla obciążeń użytkowników.

Duże obciążenia we/wy

Ogólne obciążenie może odczytywać duże ilości danych. Dedykowane pule SQL usługi Synapse skalują zasoby zgodnie z DWU. Aby osiągnąć lepszą wydajność, rozważ jedną lub obie te kwestie:

Procesor CPU, równoległość
Scenariusz Ograniczenie ryzyka
Słaba kondycja CCI Ocena i poprawianie kondycji indeksu klastrowanego magazynu kolumn w dedykowanej puli SQL
Zapytania użytkownika zawierają przekształcenia Przenieś wszystkie formatowanie i inną logikę przekształcania do procesów ETL, aby były przechowywane sformatowane wersje
Nieprawidłowe określanie priorytetów obciążenia Implementowanie izolacji obciążenia
Niewystarczająca liczba jednostek DWU dla obciążenia Rozważ zwiększenie zasobów obliczeniowych

We/wy sieci

Jeśli problem występuje podczas RETURN operacji w kroku 2,

  • Zmniejsz liczbę współbieżnych procesów równoległych.
  • Skalowanie w poziomie procesu o największym wpływie na innego klienta.

W przypadku wszystkich innych operacji przenoszenia danych prawdopodobnie problemy z siecią wydają się być wewnętrzne dla dedykowanej puli SQL. Aby szybko rozwiązać ten problem, wykonaj następujące kroki:

  1. Skalowanie dedykowanej puli SQL do DW100c
  2. Skalowanie z powrotem do żądanego poziomu dwu
SQL CLR

Unikaj częstego używania FORMAT() funkcji, implementując alternatywny sposób przekształcania danych (na przykład CONVERT() ze stylem).