Query Store

Query Store to mechanizm SQL Server gromadzący historię zapytań i ich planów wykonania.

Query Store – czym jest i do czego służy

Query Store to wbudowany mechanizm SQL Server, który zapisuje historię pracy zapytań oraz informacje o planach ich wykonania. Dzięki temu można przeanalizować nie tylko bieżący stan bazy danych, lecz także zmiany zachodzące w czasie. Gromadzone dane pozwalają sprawdzić, jakie zapytania były uruchamiane, jak długo trwało ich wykonanie, ile zasobów procesora lub pamięci wymagały oraz czy korzystały z tych samych planów co wcześniej.

Znaczenie Query Store polega przede wszystkim na zachowaniu kontekstu. Bez tego mechanizmu analiza problemu często opiera się wyłącznie na aktualnym planie zapytania i chwilowych odczytach wydajności. Jeżeli zapytanie działało poprawnie rano, a po kilku godzinach zaczęło wykonywać się znacznie dłużej, sam podgląd bieżącego planu może nie wyjaśnić przyczyny. Query Store może natomiast pokazać, że w określonym momencie nastąpiła zmiana planu albo wzrosła liczba odczytywanych stron danych.

Mechanizm działa na poziomie konkretnej bazy danych. Po włączeniu przechowuje statystyki wykonania zapytań i wiąże je z planami, które zostały zastosowane przez optymalizator. W zależności od konfiguracji dane mogą być agregowane w przedziałach czasu, co ułatwia obserwowanie trendów i ogranicza ilość szczegółów potrzebnych do codziennego monitoringu. Query Store nie jest kopią danych biznesowych ani dziennikiem każdej wartości przekazywanej do zapytania. Jego głównym zadaniem jest opisanie zachowania zapytań z punktu widzenia wydajności.

Query Store a plan wykonania, pamięć podręczna i dziennik

Query Store warto odróżnić od pamięci podręcznej planów. Pamięć podręczna służy do szybkiego ponownego wykorzystania planu, ale jej zawartość może zostać usunięta między innymi po ponownym uruchomieniu instancji, zmianie ustawień, presji pamięci albo ręcznym opróżnieniu pamięci. Historia przechowywana przez Query Store jest trwalsza, ponieważ trafia do obszaru danych powiązanego z bazą. Umożliwia to porównanie zachowania zapytań przed i po zmianie konfiguracji, aktualizacji statystyk lub modyfikacji indeksów.

Nie należy też utożsamiać Query Store z dziennikiem transakcji. Dziennik transakcji służy do zapewnienia spójności operacji zapisu i odtwarzania stanu po awarii. Query Store opisuje zapytania oraz ich wydajność, lecz nie zastępuje mechanizmów odzyskiwania danych. Nie jest również tym samym co śledzenie zdarzeń. Narzędzia śledzące mogą rejestrować szczegółowy przebieg wybranych zdarzeń w czasie rzeczywistym, natomiast Query Store skupia się na uporządkowanej historii zapytań i planów.

W praktyce Query Store może przechowywać między innymi identyfikator zapytania, tekst zapytania, identyfikator planu, liczbę wykonań, czas trwania, zużycie procesora, liczbę odczytów logicznych oraz informacje o oczekiwaniach. Wartości te są zazwyczaj agregowane, dlatego należy pamiętać, że średnia może ukrywać pojedyncze bardzo wolne wykonania. Przy analizie problemu przydatne bywają jednocześnie średnia, wartość maksymalna, odchylenie oraz liczba wykonań.

Query Store ułatwia także odróżnienie problemu stałego od problemu zależnego od obciążenia. Jeżeli czas wykonania rośnie wraz z liczbą danych, można podejrzewać niewystarczający indeks, niekorzystny sposób filtrowania lub zmianę rozkładu wartości. Jeżeli spowolnienie pojawia się tylko w określonych porach, większe znaczenie mogą mieć współbieżność, blokady, obciążenie procesora albo operacje wykonywane równolegle przez inne zadania.

Query Store – typowe problemy wykrywane w praktyce

Jednym z częstych zastosowań Query Store jest wykrywanie regresji wydajności. Regresja występuje wtedy, gdy to samo zapytanie po pewnym czasie zaczyna działać wolniej, mimo że tekst zapytania nie uległ zmianie. Przyczyną może być wybór innego planu wykonania, aktualizacja statystyk, zmiana liczby danych, przebudowa indeksu albo zmiana parametrów wejściowych. Porównanie planów zapisanych w Query Store pozwala sprawdzić, co faktycznie się zmieniło.

Problemem bywa również tak zwana niestabilność planu. Optymalizator może dla jednych parametrów wybrać plan odpowiedni, a dla innych plan mniej korzystny. Zjawisko jest szczególnie widoczne wtedy, gdy wartości w kolumnie są nierównomiernie rozłożone. Query Store pokazuje, czy zapytanie korzystało z wielu planów i czy jeden z nich wiązał się z wyraźnie gorszym czasem wykonania. Taka obserwacja pomaga skierować dalszą analizę na parametry, statystyki, sposób kompilacji oraz strukturę indeksów.

Query Store może ujawnić zapytania, które nie są uruchamiane często, lecz pojedyncze wykonanie pochłania dużo zasobów. Inną kategorię stanowią zapytania wykonywane bardzo często, nawet jeżeli każde z nich trwa krótko. W tym przypadku suma czasu procesora lub liczba odczytów może być istotniejsza niż wynik pojedynczego wykonania. Dlatego ranking problemów powinien uwzględniać zarówno koszt jednostkowy, jak i częstotliwość.

W analizie mogą pojawić się także zapytania oczekujące na blokadę. Query Store pomaga zauważyć wzrost czasu oczekiwania, ale nie zawsze wskaże pełną przyczynę blokowania. Do ustalenia, która sesja przetrzymuje blokadę, potrzebne są dodatkowe informacje z chwili wystąpienia problemu. Historia Query Store jest więc ważnym elementem diagnozy, lecz nie zawsze jedynym źródłem danych.

Warto kontrolować również rozmiar magazynu Query Store. Zbyt krótka retencja usuwa wartościową historię, a zbyt duża ilość przechowywanych danych może utrudniać zarządzanie. Znaczenie mają limit rozmiaru, tryb czyszczenia, okres przechowywania oraz częstotliwość agregacji. Ustawienia powinny odpowiadać temu, jak długi okres porównawczy jest potrzebny do wykrywania zmian.

Query Store – praktyczne wskazówki konfiguracji i analizy

Przed rozpoczęciem analizy należy upewnić się, że Query Store jest włączony dla właściwej bazy i rzeczywiście zapisuje dane. Następnie warto ustalić zakres czasu, w którym pojawiło się spowolnienie. Porównywanie bardzo odległych okresów może prowadzić do błędnych wniosków, zwłaszcza gdy w międzyczasie zmieniły się dane, indeksy, aplikacja lub sposób obciążania bazy.

Analizę dobrze rozpocząć od zapytań o najwyższym łącznym czasie procesora, największej liczbie odczytów oraz największym średnim czasie wykonania. Każdy z tych rankingów odpowiada na inne pytanie. Łączny czas wskazuje wpływ na całość obciążenia, średni czas pokazuje koszt pojedynczego wykonania, a liczba odczytów pomaga szukać zapytań przetwarzających zbyt wiele danych. Dopiero po takim przeglądzie można ocenić, czy warto analizować indeks, predykat, kolejność złączeń albo sposób przekazywania parametrów.

Podczas porównywania planów nie należy oceniać ich wyłącznie po rozmiarze graficznym. Istotne są między innymi rodzaj dostępu do tabeli, kolejność operacji, szacowana i rzeczywista liczba wierszy, wykorzystanie indeksów oraz koszt operacji sortowania lub złączenia. Różnica między estymowaną a rzeczywistą liczbą wierszy może wskazywać na nieaktualne statystyki lub trudny do oszacowania rozkład danych.

Query Store może wspierać kontrolowane wymuszenie wybranego planu, gdy wiadomo, że określony plan działał poprawnie, a nowy powoduje regresję. Takie działanie powinno być traktowane jako rozwiązanie świadome i podlegające obserwacji. Wymuszony plan nie usuwa przyczyny źródłowej, a po zmianie schematu, danych lub indeksów może przestać być korzystny. Po zastosowaniu wymuszenia należy sprawdzać dalsze statystyki i ocenić, czy problem rzeczywiście ustąpił.

Przydatne jest dokumentowanie zmian wykonywanych w bazie. Informacja o aktualizacji aplikacji, modyfikacji zapytania, zmianie indeksu lub odświeżeniu statystyk pozwala zestawić zdarzenie z późniejszym zachowaniem zapytań. Bez takiego kontekstu historia Query Store pokazuje objaw, lecz ustalenie przyczyny może wymagać dodatkowych testów.

Query Store – kiedy zgłosić się do serwisu komputerowego

Do konsultacji warto przygotować opis problemu, przybliżony moment jego wystąpienia, nazwę bazy, identyfikator zapytania oraz porównanie planu działającego wcześniej z planem obserwowanym obecnie. Pomocne są także informacje o ostatnich zmianach w aplikacji, strukturze tabel, indeksach i ustawieniach środowiska. Nie powinno się udostępniać przypadkowych kopii danych zawierających informacje poufne; do analizy często wystarczą metadane, statystyki i zanonimizowany tekst zapytania.

Wsparcie serwisu komputerowego może być przydatne wtedy, gdy problem z Query Store łączy się z ogólną niestabilnością systemu, błędami dysku, nieprawidłowym działaniem pamięci, przegrzewaniem podzespołów albo trudnościami z odczytem danych. W Warszawskim Pogotowiu Komputerowym 24/7 dostępna jest darmowa diagnoza laptopa, dzięki której można najpierw ustalić, czy źródła problemu należy szukać w sprzęcie, systemie operacyjnym czy konfiguracji używanego oprogramowania.

Jeżeli Query Store nie pokazuje historii mimo wcześniejszego występowania problemu, warto zweryfikować, czy mechanizm był aktywny, czy dane nie zostały wyczyszczone oraz czy analizowana jest właściwa baza. Należy też sprawdzić uprawnienia do odczytu widoków i raportów. Brak wyników nie musi oznaczać braku zapytań; może wynikać z konfiguracji, retencji danych albo niewłaściwego zakresu czasu.

Najlepszy efekt daje połączenie informacji z Query Store z obserwacją obciążenia, analizą planów, kontrolą blokad i znajomością zmian w aplikacji. Samo znalezienie najwolniejszego zapytania nie przesądza jeszcze o sposobie naprawy. Dopiero zestawienie historii, planów, statystyk i warunków pracy pozwala dobrać działanie, które poprawi wydajność bez pogorszenia innych elementów systemu.