Rozwiązywanie problemów z powolnym zapytaniem w dedykowanej puli SQL
Dotyczy: Azure Synapse Analytics
Ten artykuł pomaga zidentyfikować przyczyny i zastosować środki zaradcze dla typowych problemów z wydajnością zapytań w dedykowanej puli SQL usługi Azure Synapse Analytics.
Wykonaj kroki, aby rozwiązać problem lub wykonać kroki w notesie za pośrednictwem narzędzia Azure Data Studio. Pierwsze trzy kroki umożliwiają zbieranie danych telemetrycznych, które opisują cykl życia zapytania. Odwołania na końcu artykułu ułatwiają analizowanie potencjalnych szans sprzedaży znalezionych w zebranych danych.
Uwaga 16.
Przed podjęciem próby otwarcia tego notesu upewnij się, że program Azure Data Studio jest zainstalowany na komputerze lokalnym. Aby go zainstalować, przejdź do artykułu Dowiedz się, jak zainstalować program Azure Data Studio.
Ważne
Większość zgłoszonych problemów z wydajnością jest spowodowana:
- Nieaktualne statystyki
- W złej kondycji klastrowane indeksy magazynu kolumn (CCI)
Aby zaoszczędzić czas rozwiązywania problemów, upewnij się, że statystyki zostały utworzone i aktualne oraz że elementy CCI zostały ponownie utworzone.
Krok 1. Identyfikowanie request_id (aka QID)
Wolne request_id zapytanie jest wymagane do badania 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 wartości
submit_time DESClubtotal_elapsed_time DESC, aby mieć najdłużej działające zapytania w górnej części zestawu wyników.Użyj
OPTION(LABEL='<YourLabel>')w zapytaniach, a następnie przefiltruj kolumnęlabel, aby je zidentyfikować.Rozważ odfiltrowanie wszelkich identyfikatorów QID, które nie mają wartości,
resource_allocation_percentagegdy wiadomo, że instrukcja docelowa jest zawarta w partii.Uwaga: należy zachować ostrożność przy użyciu tego filtru, ponieważ może również odfiltrować niektóre zapytania, które są blokowane przez inne sesje.
Krok 2. Określanie, gdzie trwa wykonywanie zapytania
Uruchom następujący skrypt, aby znaleźć krok, który może spowodować problem z wydajnością zapytania. Zaktualizuj zmienne w skry skrycie 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 w powolnym kroku zidentyfikowanym z zestawu wyników.
| Parametr | Opis |
|---|---|
@QID |
request_id Wartość uzyskana w kroku 1 |
@ShowActiveOnly |
0 — Pokaż wszystkie kroki 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 skry skrycie przy użyciu wartości opisanych w poniższej tabeli. @ShowActiveOnly Zmień wartość na 0, aby porównać wszystkie chronometraż dystrybucji. Zanotuj wait_type wartość dystrybucji, która może powodować problem z wydajnością.
| Parametr | Opis |
|---|---|
@QID |
request_id Wartość uzyskana w kroku 1 |
@StepIndex |
StepIndex Wartość zidentyfikowana w kroku 2 |
@ShowActiveOnly |
0 — Pokaż wszystkie rozkłady dla danej StepIndex wartości1 — Pokazywanie tylko aktualnie aktywnych rozkładów 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 ograniczanie ryzyka
Problemy z fazą kompilacji
Zgodnie z wartościami
Descriptionuzyskanymi w kroku 2 sprawdź odpowiednią sekcję, aby uzyskać więcej informacji z poniższej tabeli.opis Typowa przyczyna Compilation ConcurrencyZablokowane: współbieżność kompilacji Resource Allocation (Concurrency)Zablokowane: alokacja zasobów Jeśli zapytanie ma stan "Uruchomiono" zidentyfikowany w kroku 1, ale w kroku 2 nie ma informacji krokowych, sprawdź przyczynę, która najlepiej pasuje do danego scenariusza, aby uzyskać więcej informacji z poniższej tabeli.
Scenariusz Typowa przyczyna Instrukcja zawiera złożoną logikę filtrowania sprzężeń lub wykonuje sprzężenia w WHEREklauzuliZłożone zapytanie lub starsza składnia JOIN Instrukcja jest długotrwałą DROP TABLEinstrukcją lubTRUNCATE TABLEDługotrwała TABELA DROP LUB TRUNCATE TABLE Wskaźniki CCI mają wysoki procent usuniętych lub otwartych wierszy (zobacz Optymalizowanie klastrowanych indeksów magazynu kolumn) Wskaźniki CCI w złej kondycji (ogólnie) Przeanalizuj zestaw wyników w kroku 1 dla co najmniej jednej
CREATE STATISTICSinstrukcji wykonanej natychmiast po powolnym przesłaniu zapytania. Sprawdź przyczynę, która najlepiej pasuje do twojego scenariusza z poniższej tabeli.Scenariusz Typowa przyczyna Statystyki utworzone nieoczekiwanie Opóźnienie z automatycznego tworzenia statystyk Tworzenie statystyk nie powiodło się po 5 minutach Limity czasu statystyk automatycznego tworzenia
Zablokowane: współbieżność kompilacji
Rzadko występują bloki kompilacji współbieżności. Jeśli jednak napotkasz ten typ bloku, oznacza to, że duża liczba zapytań została przesłana w krótkim czasie i została w kolejce do rozpoczęcia kompilacji.
Środki zaradcze
Zmniejsz liczbę zapytań przesyłanych współbieżnie.
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ążenia skojarzonej z użytkownikiem.
- Ilość dostępnej pamięci w systemie lub grupie obciążeń.
- (Opcjonalnie) Ważność grupy/klasyfikatora obciążenia.
Środki zaradcze
- Poczekaj na zakończenie sesji blokującej.
- Oceń wybór klasy zasobów. Aby uzyskać więcej informacji, zobacz Limity współbieżności.
- Oceń, czy lepiej jest zabić sesję blokującą.
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 podzapytania (złożone zapytanie).
- Używa sprzężeń w klauzuli
FROM(nie sprzężeń w stylu ANSI-92).
Chociaż te scenariusze są nietypowe, możesz spróbować zastąpić domyślne zachowanie, aby skrócić czas potrzebny optymalizatorowi zapytań na wybranie planu.
Środki zaradcze
- Użyj sprzężeń w stylu ANSI-92.
- Dodaj wskazówki dotyczące zapytań:
OPTION(FORCE ORDER, USE HINT ('FORCE_LEGACY_CARDINALITY_ESTIMATION')). Aby uzyskać więcej informacji, zobacz FORCE ORDER and Cardinality Est (SQL Server). - Podziel zapytanie na wiele, mniej złożonych kroków.
Długotrwała TABELA DROP LUB TRUNCATE TABLE
W przypadku wydajności czasu wykonywania instrukcje DROP TABLE i TRUNCATE TABLE odroczą czyszczenie magazynu w procesie w tle. Jeśli jednak obciążenie wykonuje dużą liczbę instrukcji DROP/TRUNCATE TABLE w krótkim czasie, istnieje możliwość, że metadane stają się zatłoczone i powodują powolne wykonywanie kolejnych DROP/TRUNCATE TABLE instrukcji.
Środki zaradcze
Zidentyfikuj okno obsługi, zatrzymaj wszystkie obciążenia i uruchom polecenie DBCC SHRINKDATABASE , aby wymusić natychmiastowe czyszczenie wcześniej usuniętych lub obcięte tabel.
Wskaźniki CCI w złej kondycji (ogólnie)
Zła kondycja klastrowanego indeksu magazynu kolumn (CCI) wymaga dodatkowych metadanych, co może spowodować, że optymalizator zapytań zajmie więcej czasu w celu określenia optymalnego planu. Aby uniknąć tej sytuacji, upewnij się, że wszystkie elementy CCI są w dobrej kondycji.
Środki zaradcze
Oceń i popraw kondycję klastrowanego indeksu magazynu kolumn w dedykowanej puli SQL.
Opóźnienie z automatycznego tworzenia statystyk
Opcja AUTO_CREATE_STATISTICS automatycznego tworzenia statystyk jest ON domyślnie pomocna w zapewnieniu, że optymalizator zapytań może podejmować dobre decyzje dotyczące planu rozproszonego. Jednak sam proces automatycznego tworzenia może sprawić, że początkowe zapytanie trwa dłużej niż kolejne wykonania tego samego.
Środki zaradcze
Jeśli pierwsze wykonanie zapytania stale wymaga utworzenia statystyk, należy ręcznie utworzyć statystyki przed wykonaniem zapytania.
Limity czasu statystyk automatycznego tworzenia
Opcja AUTO_CREATE_STATISTICS automatycznego tworzenia statystyk jest ON domyślnie pomocna w zapewnieniu, że optymalizator zapytań może podejmować dobre decyzje dotyczące planu rozproszonego. Automatyczne tworzenie statystyk występuje w odpowiedzi na instrukcję SELECT i ma 5-minutowy próg do ukończenia. Jeśli rozmiar danych i/lub liczba utworzonych statystyk wymagają dłuższego niż 5-minutowy próg, automatyczne tworzenie statystyk zostanie porzucone, aby umożliwić kontynuowanie wykonywania zapytania. Niepowodzenie tworzenia statystyk może negatywnie wpłynąć na zdolność optymalizatora zapytań do generowania wydajnego rozproszonego planu wykonywania, co skutkuje niską wydajnością zapytań.
Środki zaradcze
Ręcznie utwórz statystyki zamiast polegać na funkcji automatycznego tworzenia dla zidentyfikowanych tabel/kolumn.
Problemy z fazą wykonywania
Skorzystaj z poniższej tabeli, aby przeanalizować zestaw wyników w kroku 2. Ustal swój scenariusz i sprawdź wspólną przyczynę szczegółowych informacji i możliwych kroków zaradczych.
Scenariusz Typowa przyczyna EstimatedRowCount/ActualRowCount< 25%Niedokładne szacunki Wartość DescriptionwskazujeBroadcastMoveOperation, a zapytanie odwołuje się do zreplikowanej tabeli.Niebuforowane tabele replikowane 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.Niezgodność typu/rozmiaru danych 1. Wartość DescriptionwskazujeHadoopBroadcastOperation,HadoopRoundRobinOperationlubHadoopShuffleOperation.
2. Wartośćtotal_elapsed_timedanejstep_indexwartości jest niespójna między wykonaniami.Zapytania tabeli zewnętrznej ad hoc total_elapsed_timeSprawdź wartość uzyskaną w kroku 3. Jeśli w kilku dystrybucjach w danym kroku jest znacznie wyższa, wykonaj następujące kroki:Sprawdź dystrybucję danych dla każdej tabeli, do których odwołuje się
TSQLpole skojarzonestep_id, uruchamiając następujące polecenie względem każdej z nich:DBCC PDW_SHOWSPACEUSED(<table>);Jeśli <minimalna wartość wierszy/<maksymalna wartość>>> wierszy wynosi 0,1, przejdź do pozycji Niesymetryczność danych (przechowywana).
W przeciwnym razie przejdź do pozycji Niesymetryczność danych w locie.
Niedokładne szacunki
Zapewnij aktualność statystyk, aby upewnić się, że optymalizator zapytań generuje optymalny plan. Jeśli szacowana liczba wierszy jest znacznie mniejsza niż rzeczywista liczba, należy zachować statystyki.
Środki zaradcze
Tworzenie/aktualizowanie statystyk.
Niebuforowane tabele replikowane
Jeśli utworzono zreplikowane tabele i nie można prawidłowo rozgrzać zreplikowanej pamięci podręcznej tabel, nieoczekiwana niska wydajność będzie skutkować dodatkowymi przenoszeniem danych lub tworzeniem nieoptymalnego planu rozproszonego.
Środki zaradcze
- Rozgrzej replikowana pamięć podręczną po operacjach DML.
- Jeśli często występują operacje DML, zmień rozkład tabeli na
ROUND_ROBIN.
Niezgodność typu/rozmiaru danych
Podczas łączenia tabel upewnij się, że typ danych i rozmiar kolumn łączących są zgodne. W przeciwnym razie spowoduje to niepotrzebne przenoszenie danych, które zmniejszy dostępność procesora CPU, operacji we/wy i ruchu sieciowego do pozostałej części obciążenia.
Środki zaradcze
Skompiluj tabele, aby poprawić powiązane kolumny tabeli, które nie mają identycznego typu i rozmiaru danych.
Zapytania tabeli zewnętrznej ad hoc
Zapytania względem tabel zewnętrznych są projektowane z zamiarem zbiorczego ładowania danych do dedykowanej puli SQL. Zapytania ad hoc względem tabel zewnętrznych mogą cierpieć na zmienne czasy trwania z powodu czynników zewnętrznych, takich jak współbieżne działania kontenera magazynu.
Środki zaradcze
Najpierw załaduj dane do dedykowanej puli SQL, a następnie wykonaj zapytanie dotyczące załadowanych danych.
Niesymetryczność danych (przechowywane)
Niesymetryczność danych oznacza, że dane nie są równomiernie dystrybuowane w różnych dystrybucjach. 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 operacje we/wy, co powoduje wolniejsze czasy wykonywania.
Środki zaradcze
Zapoznaj się z naszymi wskazówkami dotyczącymi tabel rozproszonych, aby ułatwić wybór bardziej odpowiedniej kolumny dystrybucji.
Niesymetryczność danych w locie
Niesymetryczność danych w locie jest wariantem problemu ze niesymetrycznością danych (przechowywanymi). Jednak nie jest to rozkład danych na dysku, który 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 podrzędnego.
Środki zaradcze
- Upewnij się, że statystyki są tworzone i aktualne.
- Zmień kolejność kolumn, aby prowadzić z kolumną o wyższej kardynalności
GROUP BY. - Utwórz statystykę wielokolumna, 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 żadne z powyższych typowych problemów nie ma zastosowania do zapytania, dane kroku 3 zapewniają możliwość określenia, które typy oczekiwania (w systemach 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 ze względu na podobne środki zaradcze. Wykonaj następujące kroki, aby zlokalizować kategorię oczekiwania kroku zapytania:
- Zidentyfikuj wartość
wait_typew kroku 3 , która zajmuje najwięcej czasu. - Znajdź typ oczekiwania w tabeli mapowania kategorii oczekiwania i zidentyfikuj kategorię oczekiwania, do których należy.
- Rozwiń sekcję powiązaną z kategorią oczekiwania z poniższej listy, aby uzyskać zalecane środki zaradcze.
Kompilacja
Wykonaj następujące kroki, aby rozwiązać problemy z typem oczekiwania w kategorii Kompilacja:
- Ponownie skompiluj indeksy dla wszystkich obiektów zaangażowanych w problematyczne zapytanie.
- Zaktualizuj statystyki dotyczące wszystkich obiektów zaangażowanych w problematyczne zapytanie.
- Ponownie przetestuj problematyczne zapytanie, aby sprawdzić, czy problem będzie się powtarzać.
Jeśli problem będzie się powtarzać, wykonaj następujące elementy:
Utwórz plik .sql za pomocą:
SET QUERY_DIAGNOSTICS ON; <Your_SQL>; SET QUERY_DIAGNOSTICS OFF;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>.txtOtwórz <output_file_name>.txt w edytorze tekstów. Znajdź i skopiuj wklej plany wykonywania na poziomie dystrybucji (wiersze rozpoczynające się od
<ShowPlanXML>) z najdłuższego kroku określonego w kroku 2 do oddzielnych plików tekstowych z rozszerzeniem sqlplan .Uwaga: każdy krok planu rozproszonego zwykle rejestrował 60 planów wykonywania na poziomie dystrybucji. Upewnij się, że przygotowujesz i porównujesz plany wykonania z tego samego kroku planu rozproszonego.
Zapytanie krok 3 często ujawnia kilka dystrybucji, które trwa znacznie dłużej niż inne. W programie SQL Server Management Studio porównaj plany wykonywania na poziomie dystrybucji (z utworzonych plików sqlplan ) długotrwałej dystrybucji do szybkiej dystrybucji w celu przeanalizowania potencjalnych przyczyn różnic.
Blokada, wątek procesu roboczego
- Rozważ zmianę tabel, które są często poddawane małym zmianom, aby użyć indeksu magazynu wierszy zamiast CCI.
- Wsaduj zmiany i aktualizuj element docelowy przy użyciu większej liczby wierszy rzadziej.
We/wy buforu, inne we/wy dysku, we/wy dziennika tran
W złej kondycji interfejsy CCI
Wskaźniki CCI w złej kondycji przyczyniają się do zwiększenia alokacji operacji we/wy, procesora CPU i pamięci, co z kolei negatywnie wpływa na wydajność zapytań. Aby rozwiązać ten problem, wypróbuj jedną z następujących metod:
- Oceń i popraw kondycję klastrowanego indeksu magazynu kolumn w dedykowanej puli SQL.
- Uruchom i przejrzyj dane wyjściowe zapytania wymienionego na stronie Optymalizowanie klastrowanych indeksów magazynu kolumn, aby uzyskać punkt odniesienia.
- Wykonaj kroki, aby ponownie skompilować indeksy , aby poprawić jakość segmentu, kierując tabele zaangażowane w przykładowe zapytanie problemu.
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 na danych magazynowanych, ale także na tempdb. Ponieważ operacje We/Wy jest zasobem dostępnym we wszystkich zapytaniach, a wpływ na wydajność może być odczuwalny dla całego obciążenia.
Aby rozwiązać ten problem, upewnij się, że wszystkie statystyki są aktualne, a plan konserwacji jest aktualizowany pod kątem 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 jednostkami DWU. Aby osiągnąć lepszą wydajność, należy wziąć pod uwagę jedną lub obie te elementy:
- Użycie większej klasy zasobów dla zapytań.
- Zwiększ zasoby obliczeniowe.
Procesor CPU, równoległość
| Scenariusz | Czynności zapobiegawcze |
|---|---|
| Słaba kondycja klastrowanych indeksów magazynu kolumn | Ocena i poprawianie kondycji klastrowanego indeksu magazynu kolumn w dedykowanej puli SQL |
| Zapytania użytkowników zawierają przekształcenia | Przenieś całe formatowanie i inną logikę przekształcania do procesów ETL, aby sformatowane wersje były przechowywane |
| Nieprawidłowe ustalanie 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 najbardziej dotkniętego procesu do innego klienta.
W przypadku wszystkich innych operacji przenoszenia danych prawdopodobne jest, że problemy z siecią wydają się być wewnętrzne dla dedykowanej puli SQL. Aby szybko rozwiązać ten problem, wykonaj następujące kroki:
- Skalowanie dedykowanej puli SQL do DW100c
- Skalowanie z powrotem do żądanego poziomu jednostek DWU
SQL CLR
Unikaj częstego używania FORMAT() funkcji, implementując alternatywny sposób przekształcania danych (na przykład CONVERT() ze stylem).