Czyszczenie Query Store

Czyszczenie Query Store to proces usuwania zgromadzonej historii statystyk wykonania zapytań przechowywanej przez ten mechanizm SQL Server.

Czyszczenie Query Store – czym jest i jaki ma cel

Czyszczenie Query Store oznacza uporządkowanie danych gromadzonych przez mechanizm SQL Server, który zapisuje informacje o zapytaniach, planach wykonania oraz statystykach wydajności. W praktyce usuwa się wybrane lub wszystkie historyczne wpisy dotyczące zapytań, aby ograniczyć zajmowane miejsce, usunąć nieaktualny materiał diagnostyczny albo rozpocząć obserwację wydajności od nowego punktu odniesienia. Nie jest to zwykłe kasowanie treści tabel aplikacyjnych. Operacja dotyczy danych pomocniczych wykorzystywanych do analizy pracy bazy i do porównywania zachowania zapytań w czasie.

Query Store może przechowywać wiele wersji planów wykonania tego samego zapytania oraz statystyki zbierane w kolejnych przedziałach czasu. Dzięki temu można sprawdzić, czy zapytanie zaczęło wykonywać się wolniej, kiedy nastąpiła zmiana i jaki plan był wtedy używany. Zgromadzona historia ma dużą wartość diagnostyczną, ale z czasem może stać się obszerna, szczególnie gdy środowisko obsługuje zmienny ruch, często generuje zapytania o różnych tekstach lub długo działa bez przeglądu ustawień retencji. Czyszczenie powinno więc wynikać z określonego celu, a nie z samej chęci usunięcia danych.

Query Store w kontekście technicznym i porównanie metod porządkowania

Przed wykonaniem operacji warto rozróżnić kilka sposobów ograniczania zawartości Query Store. Automatyczne zarządzanie rozmiarem może usuwać najstarsze dane po przekroczeniu ustalonego limitu. Retencja czasowa pozwala przechowywać informacje tylko przez określony okres, co ogranicza narastanie historii bez ręcznego kasowania. Ręczne czyszczenie całej zawartości usuwa zgromadzone statystyki i plany, natomiast czyszczenie częściowe może dotyczyć wybranych zapytań, planów albo przedziałów danych, zależnie od użytej procedury i wersji SQL Server.

Pełne wyczyszczenie jest rozwiązaniem prostym, lecz powoduje utratę materiału potrzebnego do porównań z przeszłości. Selektywne usuwanie lepiej sprawdza się wtedy, gdy problem dotyczy pojedynczego zapytania, błędnie wygenerowanych planów lub danych z konkretnego okresu. Warto również odróżnić czyszczenie od wyłączenia Query Store. Wyłączenie zatrzymuje zbieranie nowych danych, ale samo w sobie nie musi oznaczać usunięcia już zapisanej historii. Z kolei usunięcie statystyk nie powinno być utożsamiane z naprawą przyczyny spowolnienia, ponieważ nie zmienia indeksów, konstrukcji zapytań, parametrów ani zasobów dostępnych dla bazy.

Ważnym elementem jest ustalenie, czy problem dotyczy wielkości magazynu, nadmiaru nieprzydatnych wpisów, nieaktualnych planów, czy też błędnej interpretacji raportów. W niektórych sytuacjach lepsze będzie ustawienie właściwej retencji i limitu rozmiaru niż jednorazowe wyzerowanie historii. Po zmianach należy sprawdzić, czy mechanizm nadal zbiera dane, czy nowe wpisy pojawiają się prawidłowo oraz czy zapytania diagnostyczne zwracają oczekiwane wyniki.

Najczęstsze problemy podczas czyszczenia Query Store

Jednym z typowych problemów jest utrata punktu odniesienia. Jeżeli historia zostanie usunięta tuż przed analizą spadku wydajności, zniknie możliwość porównania bieżących parametrów z wcześniejszym okresem. Trudniejsze może stać się także ustalenie, czy przyczyną była zmiana planu, modyfikacja danych, aktualizacja aplikacji, zmiana indeksu czy inny czynnik. Z tego powodu przed czyszczeniem warto zapisać najważniejsze obserwacje, identyfikatory zapytań, czasy wykonania i informacje o planach, jeżeli będą potrzebne w dalszej analizie.

Innym kłopotem jest oczekiwanie, że usunięcie historii automatycznie poprawi wydajność. Samo czyszczenie zazwyczaj nie przyspiesza zapytań. Może jedynie ograniczyć rozmiar danych diagnostycznych albo usunąć nieaktualne informacje. Jeżeli źródłem problemu jest nieefektywne zapytanie, brak odpowiedniego indeksu, niekorzystne parametry lub zmiana rozkładu danych, konieczne będzie odrębne rozpoznanie i dobranie właściwego rozwiązania.

Ryzyko stanowi również uruchomienie polecenia w niewłaściwej bazie albo objęcie operacją większego zakresu niż planowano. Przed wykonaniem należy potwierdzić kontekst, zakres usuwanych danych oraz uprawnienia. Warto sprawdzić stan Query Store przed operacją i po niej, a także obserwować, czy nie pojawiają się błędy związane z limitem rozmiaru, trybem pracy lub brakiem miejsca. W środowisku, w którym historia jest wykorzystywana do kontroli zmian, przydatne może być odnotowanie daty czyszczenia i powodu wykonania czynności.

Praktyczne wskazówki dotyczące Query Store

Najbezpieczniej rozpocząć od określenia zakresu. Jeżeli potrzebne jest tylko usunięcie bardzo starych danych, warto zastosować retencję lub operację ograniczoną do konkretnego okresu. Gdy problem dotyczy pojedynczego zapytania, należy rozważyć usunięcie jego historii zamiast zerowania całego magazynu. Pełne czyszczenie może mieć uzasadnienie po zakończeniu projektu diagnostycznego, po dużej zmianie aplikacji albo wtedy, gdy dotychczasowe dane są nieaktualne i nie będą już używane.

Przed zmianą ustawień dobrze jest sprawdzić bieżący rozmiar Query Store, liczbę przechowywanych planów, najczęściej wykonywane zapytania oraz okres, z którego pochodzą statystyki. Pomocne jest również ustalenie, czy dostępna jest kopia konfiguracji i czy można odtworzyć poprzednie ustawienia. Po czyszczeniu należy ponownie zweryfikować limit rozmiaru, tryb zbierania danych i czas retencji. Przez następny okres obserwacji warto kontrolować, czy dane narastają w przewidywalnym tempie i czy raporty wydajności są kompletne.

Nie powinno się usuwać historii bez sprawdzenia, czy nie jest ona potrzebna do analizy powtarzających się incydentów. Dobrą praktyką jest zachowanie krótkiej notatki technicznej obejmującej przyczynę, zakres, moment wykonania i wynik kontroli. Jeżeli operacja jest elementem większych prac, można wcześniej wyeksportować najważniejsze wyniki analiz do dokumentacji. Ułatwia to późniejsze porównanie i ogranicza ryzyko podejmowania decyzji wyłącznie na podstawie świeżo zebranych danych.

Kiedy zgłosić się z problemem Query Store do serwisu

Wsparcie serwisowe może być zasadne, gdy nie jest jasne, czy przyczyną problemu jest sam Query Store, konfiguracja bazy, aplikacja czy zmiana planu wykonania. Zgłoszenie warto rozważyć również wtedy, gdy historia szybko zajmuje dostępne miejsce, operacje czyszczenia nie przynoszą oczekiwanego rezultatu, pojawiają się błędy uprawnień albo potrzebne jest bezpieczne rozdzielenie danych diagnostycznych od danych użytkowych. Przed przekazaniem sprawy dobrze przygotować opis objawów, przybliżony moment ich wystąpienia oraz informację o ostatnich zmianach.

Warszawskie Pogotowie Komputerowe 24/7 może pomóc w uporządkowaniu takiego zgłoszenia, sprawdzeniu zależności między konfiguracją a obserwowanym zachowaniem oraz przygotowaniu zaleceń dotyczących dalszej diagnostyki. Warto oczekiwać wyjaśnienia, jaki zakres danych ma zostać usunięty, co pozostanie bez zmian i jakie kontrole zostaną wykonane po zakończeniu prac. Takie podejście pozwala potraktować czyszczenie Query Store jako kontrolowaną czynność administracyjną, a nie przypadkowe kasowanie informacji potrzebnych do rozpoznania problemu.