Diagnostyka z wykorzystaniem Query Store

Diagnostyka z wykorzystaniem Query Store to proces analizy historii wykonania zapytań zgromadzonej przez ten mechanizm SQL Server.

Diagnostyka z wykorzystaniem Query Store – czym jest i czemu służy

Diagnostyka z wykorzystaniem Query Store polega na odtworzeniu zachowania zapytań SQL na podstawie danych zbieranych w czasie ich wykonywania. Mechanizm ten przechowuje informacje o zapytaniach, planach wykonania oraz statystykach wydajności, dzięki czemu możliwe staje się porównanie pracy bazy danych w różnych okresach. Analiza nie ogranicza się więc do sprawdzenia pojedynczego, aktualnie uruchomionego polecenia. Uwzględniana jest także historia, która pomaga ustalić, czy problem występował stale, pojawił się po zmianie konfiguracji, czy rozpoczął się po zastosowaniu innego planu wykonania.

Query Store może być wykorzystywany jako warstwa obserwacyjna dla zapytań wykonywanych przez aplikacje, raporty i procesy cykliczne. Rejestrowane dane pozwalają ocenić czas trwania, zużycie procesora, liczbę odczytów logicznych, liczbę zapisów oraz częstotliwość wykonywania. Szczególne znaczenie ma możliwość zestawienia wartości średnich z wartościami maksymalnymi. Zapytanie, które zwykle kończy się szybko, lecz sporadycznie wykonuje się znacznie dłużej, może wymagać innego podejścia niż polecenie stale obciążające zasoby.

W praktyce Query Store pomaga przejść od ogólnego stwierdzenia, że baza działa wolno, do wskazania konkretnych zapytań i momentu wystąpienia odchylenia. Ułatwia to planowanie dalszych czynności, ponieważ można oddzielić problem aplikacyjny od problemu z indeksami, statystykami, blokowaniem lub zmianą planu wykonania. Samo zebranie danych nie stanowi jeszcze diagnozy. Konieczne jest powiązanie informacji z Query Store z objawami obserwowanymi podczas pracy systemu.

Query Store w kontekście technicznym i porównaniu metod analizy

Tradycyjne badanie wydajności często opiera się na aktualnym planie wykonania oraz chwilowych licznikach zasobów. Takie podejście jest przydatne, gdy problem występuje w momencie analizy, ale może nie wyjaśnić zdarzeń, które już minęły. Query Store rozszerza ten obraz o perspektywę historyczną. Można sprawdzić, jak zmieniała się wydajność danego zapytania, kiedy pojawiła się nowa wersja planu i czy pogorszenie było związane z konkretnym przedziałem czasu.

Ważnym pojęciem jest identyfikator zapytania. Pozwala on śledzić tę samą logiczną instrukcję nawet wtedy, gdy zmieniają się jej plany wykonania. Dzięki temu możliwe jest rozpoznanie regresji planu, czyli sytuacji, w której nowy plan działa wyraźnie gorzej od wcześniejszego. Porównanie planów powinno obejmować między innymi sposób dostępu do danych, kolejność łączenia tabel, rodzaj użytych operatorów, przewidywaną i rzeczywistą liczbę wierszy oraz wpływ parametrów.

Query Store nie zastępuje dzienników aplikacyjnych, monitoringu zasobów ani analizy blokad. Każde z tych źródeł odpowiada na inne pytania. Historia zapytań wskazuje, co i kiedy wykonywało się wolniej. Monitoring może pokazać, czy w tym samym czasie występował brak pamięci, wysokie obciążenie procesora lub przeciążenie podsystemu dyskowego. Dzienniki aplikacji pomagają ustalić, który ekran, moduł lub proces wywołał daną instrukcję. Dopiero zestawienie tych informacji daje wiarygodny obraz przyczyny.

Warto także rozróżniać czas wykonania pojedynczej operacji od czasu oczekiwania użytkownika. Na wydłużenie odpowiedzi może wpływać kolejka zadań, blokowanie przez inną transakcję, opóźnienia wejścia i wyjścia albo wielokrotne wywołanie tego samego zapytania. Query Store może ujawnić wzrost czasu realizacji, lecz interpretacja wymaga sprawdzenia, czy wzrost wynikał z większej ilości danych, innego planu, zmiany parametrów czy warunków zewnętrznych.

Typowe problemy wykrywane przez diagnostykę Query Store

Jednym z częstszych przypadków jest regresja planu wykonania. Zapytanie przez długi czas działa poprawnie, a po aktualizacji statystyk, zmianie danych lub ponownej kompilacji zaczyna zużywać więcej zasobów. W Query Store można wtedy porównać wcześniejszy i bieżący plan oraz określić, czy pogorszenie koreluje ze zmianą planu. Przydatne bywa również sprawdzenie, czy nowy plan jest używany zawsze, czy tylko dla wybranych wartości parametrów.

Innym problemem jest niewłaściwe oszacowanie liczby wierszy. Jeżeli przewidywania znacząco różnią się od rzeczywistego rozmiaru wyniku, wybór operatorów może okazać się niekorzystny. Skutkiem może być nadmierne zużycie pamięci, niepotrzebne sortowanie, zbyt późne filtrowanie danych albo wybór nieefektywnej metody łączenia. Analiza Query Store powinna w takim przypadku zostać uzupełniona o sprawdzenie aktualności statystyk, rozkładu wartości i sposobu przekazywania parametrów.

Możliwe jest również wykrycie zapytań, które nie są najwolniejsze jednostkowo, lecz są wykonywane bardzo często. Ich łączny koszt może przewyższać koszt rzadko uruchamianych instrukcji o długim czasie trwania. Warto analizować zarówno czas pojedynczego wykonania, jak i sumaryczny czas, liczbę wywołań oraz sumaryczne zużycie procesora i operacji odczytu. Taki podział pomaga ustalić, czy większy efekt przyniesie optymalizacja jednej ciężkiej operacji, czy ograniczenie liczby powtarzalnych zapytań.

Query Store może także wskazać nagły wzrost czasu odpowiedzi po wdrożeniu nowej wersji aplikacji. W takiej sytuacji porównuje się okres przed zmianą i po zmianie, a następnie identyfikuje nowe lub zmodyfikowane zapytania. Sprawdzane są również zmiany w filtrach, sortowaniu, sposobie stronicowania oraz pobieraniu danych. Niekiedy przyczyną nie jest pojedynczy wadliwy plan, lecz zwiększona liczba zapytań generowanych przez jeden widok albo proces.

Praktyczne wskazówki dotyczące Query Store i interpretacji danych

Przed rozpoczęciem analizy należy ustalić ramy czasowe problemu. Pomocne jest określenie, od kiedy użytkownicy obserwują opóźnienia, czy dotyczą one wszystkich operacji oraz czy występują regularnie. Następnie można wybrać w Query Store zapytania o największym czasie całkowitym, największym czasie średnim, największym zużyciu procesora lub największej liczbie odczytów. Każde kryterium pokazuje inny fragment sytuacji, dlatego pojedynczy ranking nie powinien być traktowany jako pełna odpowiedź.

Należy unikać pochopnego uznawania każdego zapytania o dużym czasie trwania za wadliwe. Długie działanie może wynikać z przetwarzania dużego, uzasadnionego zestawu danych, a nie z błędu. Weryfikowana powinna być proporcja między zakresem żądanych danych a kosztem operacji. Sprawdzane są także parametry, częstotliwość wywołań, sposób prezentowania wyników oraz to, czy użytkownik rzeczywiście potrzebuje wszystkich zwracanych kolumn i rekordów.

Dobrym zwyczajem jest zachowanie informacji o planach przed wprowadzeniem zmian. Ułatwia to późniejsze porównanie i ogranicza ryzyko oceny wyłącznie na podstawie pojedynczego pomiaru. Po zmianie indeksu, statystyk, zapytania lub konfiguracji należy obserwować kilka kolejnych okresów pracy, ponieważ poprawa może być widoczna dopiero po ustabilizowaniu obciążenia. Warto odnotować datę modyfikacji, zakres zmian i oczekiwany efekt.

Przy interpretacji wyników należy zwracać uwagę na agregację. Średni czas wykonania może ukrywać pojedyncze bardzo wolne przypadki, natomiast wartość maksymalna może być skutkiem incydentalnego zdarzenia. Przydatne jest zestawienie średniej, wartości maksymalnej, odchyleń między wykonaniami i liczby wywołań. W ten sposób można odróżnić stałą degradację od sporadycznego skoku opóźnienia.

Kiedy zgłosić się w sprawie diagnostyki z Query Store

Do analizy warto zgłosić się wtedy, gdy spowolnienie powtarza się, pojawia się po aktualizacji, dotyczy konkretnej funkcji albo nie daje się wyjaśnić prostym sprawdzeniem połączenia i obciążenia. Szczególnie pomocne są informacje o czasie wystąpienia problemu, nazwie aplikacji lub modułu, rodzaju wykonywanej operacji oraz tym, czy trudność dotyczy wszystkich użytkowników. Przygotowanie takich danych skraca drogę do odtworzenia sytuacji i pozwala skupić się na najbardziej prawdopodobnych przyczynach.

W przypadku problemów ze sprzętem, systemem lub działaniem oprogramowania komputerowego można skorzystać z pomocy firmy Warszawskie Pogotowie Komputerowe 24/7. Przed przekazaniem urządzenia warto opisać objawy, moment ich wystąpienia oraz ostatnie zmiany, takie jak aktualizacja programu, wymiana podzespołu lub instalacja nowego sterownika. Takie informacje ułatwiają uporządkowanie dalszej diagnostyki i dobranie odpowiedniego zakresu sprawdzenia.

Jeżeli Query Store wskazuje na problem dotyczący samego zapytania, planu lub konfiguracji bazy danych, potrzebna jest analiza wykonana w środowisku, w którym występuje błąd. Nie powinno się usuwać historii ani zmieniać wielu ustawień jednocześnie przed zebraniem danych porównawczych. Zachowanie pierwotnego stanu, opisanie wykonanych czynności i zebranie przykładów powolnych operacji zwiększa wartość diagnostyczną całego procesu.