Resetowanie danych Query Store

Resetowanie danych Query Store czyści zgromadzoną historię zapytań i planów wykonania.

Resetowanie danych Query Store — czym jest i jaki ma cel

Resetowanie danych Query Store to działanie administracyjne polegające na usunięciu części albo całości informacji zgromadzonych przez mechanizm monitorowania zapytań w Microsoft SQL Server. W Query Store mogą być przechowywane między innymi teksty zapytań, statystyki ich wykonania, informacje o planach oraz dane potrzebne do porównywania zachowania bazy w kolejnych okresach. Z czasem zbiór ten może stać się obszerny, szczególnie gdy baza obsługuje wiele różnych poleceń, zapytania są generowane dynamicznie, a okres przechowywania danych ustawiono na długi czas.

Wyczyszczenie Query Store nie usuwa tabel, indeksów, procedur ani rekordów z właściwej bazy. Usuwana jest historia obserwacji zgromadzona przez ten mechanizm. Po wykonaniu resetowania nowe zapytania mogą być rejestrowane ponownie, o ile Query Store pozostaje włączony i jego stan pracy pozwala na zbieranie danych. Z tego powodu resetowanie należy traktować jako operację porządkową lub diagnostyczną, a nie jako sposób naprawiania samego kodu aplikacji albo struktury bazy.

Znaczenie tej czynności zależy od przyczyny jej wykonania. Jeżeli problemem jest nadmiar starych danych, można rozważyć usunięcie wybranych wpisów, zmianę zasad przechowywania lub ograniczenie wielkości magazynu. Jeżeli prowadzone jest badanie wydajności po wdrożeniu nowej wersji aplikacji, pełny reset może ułatwić obserwowanie zachowania zapytań od początku. Trzeba jednak pamiętać, że po takim działaniu wcześniejsze punkty odniesienia przestają być dostępne w Query Store.

Resetowanie danych Query Store a historia planów i statystyk

Query Store różni się od chwilowego podglądu aktywnych procesów tym, że gromadzi informacje historyczne. Dzięki temu można sprawdzić, jak zapytanie działało wcześniej, czy zmienił się plan wykonania oraz czy wzrosła liczba odczytów, czas procesora lub czas całkowity. Resetowanie tych danych usuwa właśnie tę warstwę porównawczą. Po operacji nie da się już w prosty sposób odtworzyć z Query Store informacji o planach, które zostały usunięte.

W praktyce warto odróżnić kilka działań. Wyczyszczenie wszystkich danych usuwa całą historię związaną z Query Store. Usunięcie danych dotyczących określonego zapytania pozwala zachować pozostałe obserwacje. Skasowanie pojedynczego planu może być przydatne, gdy podejrzewa się, że konkretny plan jest niekorzystny i chce się sprawdzić, jaki plan zostanie wybrany po ponownej kompilacji. Zmiana konfiguracji przechowywania danych nie jest tym samym co reset, ponieważ może jedynie ograniczyć dalszy przyrost informacji lub zmienić sposób ich porządkowania.

Resetowanie nie gwarantuje poprawy wydajności. Jeżeli źródłem opóźnień jest brak właściwego indeksu, blokowanie, przeciążenie zasobów, nieefektywne zapytanie, duża liczba odczytów lub błędne parametry, samo usunięcie historii nie rozwiąże problemu. Może natomiast utrudnić analizę, jeżeli zostanie wykonane przed zabezpieczeniem istotnych obserwacji. Z tego względu przed czyszczeniem powinno się zapisać najważniejsze teksty zapytań, czasy wykonania, informacje o planach oraz okoliczności występowania problemu.

Resetowanie danych Query Store — typowe problemy i błędne założenia

Jednym z częstszych błędów jest używanie resetowania jako pierwszej reakcji na każde spowolnienie. Jeżeli zapytanie zaczęło działać wolniej, najpierw należy ustalić, czy zmienił się plan, liczba przetwarzanych danych, sposób wywoływania polecenia albo dostępność indeksów. Query Store jest wtedy źródłem informacji diagnostycznej. Usunięcie danych przed analizą może pozbawić możliwości porównania stanu sprzed awarii ze stanem po jej wystąpieniu.

Innym problemem jest mylenie czyszczenia Query Store z usuwaniem pamięci podręcznej planów. Są to różne mechanizmy i ich działanie ma inne konsekwencje. Query Store przechowuje historię obserwacji, natomiast pamięć podręczna planów służy do ponownego wykorzystania planów przez silnik bazy. Wykonanie niewłaściwej operacji może spowodować niepotrzebne kompilacje, chwilowe wahania wydajności albo utratę informacji, które były potrzebne do dalszego badania.

Ryzyko pojawia się także wtedy, gdy reset wykonywany jest bez sprawdzenia uprawnień i stanu bazy. Należy upewnić się, że operacja dotyczy właściwej bazy, a jej zakres został jasno określony. W środowisku testowym można łatwiej sprawdzić skutki czyszczenia, natomiast w bazie używanej przez aplikację trzeba uwzględnić moment wykonania, obciążenie oraz potrzebę zachowania dokumentacji. Po resecie warto obserwować, czy nowe dane pojawiają się prawidłowo i czy nie występują komunikaty o problemach z zapisem informacji.

Nie należy również zakładać, że brak danych w Query Store oznacza brak wykonywania zapytań. Przyczyną może być wyłączenie mechanizmu, ograniczenie zbierania, filtracja, problem z miejscem na dane albo konfiguracja nieodpowiednia dla konkretnej wersji oprogramowania. Weryfikacji wymaga także zakres czasowy raportu, ponieważ świeżo wyczyszczony magazyn będzie potrzebował czasu, aby ponownie zgromadzić użyteczną historię.

Resetowanie danych Query Store — praktyczne przygotowanie operacji

Przed rozpoczęciem należy opisać powód czyszczenia i ustalić, jaki efekt ma zostać sprawdzony. Jeżeli celem jest rozpoczęcie nowej obserwacji po zmianie aplikacji, warto zanotować moment wdrożenia, zakres modyfikacji oraz warunki testu. Jeżeli problem dotyczy wzrostu rozmiaru danych, trzeba sprawdzić ustawienia limitu, tryb przechowywania oraz częstotliwość automatycznego porządkowania. Bez tych informacji reset może jedynie czasowo zmniejszyć ilość danych, a problem powróci.

Bezpieczny proces obejmuje wykonanie kopii najważniejszych wyników diagnostycznych, potwierdzenie nazwy właściwej bazy, sprawdzenie aktywności Query Store i zapisanie aktualnych ustawień. Przydatne może być wyeksportowanie raportu z zapytaniami o największym czasie wykonania, największej liczbie odczytów oraz największej zmienności planów. Warto też zapisać informacje o zapytaniach, które występują rzadko, lecz mają istotne znaczenie dla działania aplikacji.

Zakres operacji powinien być możliwie mały. Jeśli problem dotyczy pojedynczego zapytania lub planu, pełne czyszczenie nie musi być uzasadnione. Po wykonaniu resetowania należy odczekać na zebranie nowych obserwacji, a następnie porównać je z wynikami testów. Analiza powinna uwzględniać te same scenariusze, podobne dane wejściowe i zbliżone obciążenie. Dopiero wtedy można ocenić, czy zmiana planu przyniosła poprawę, czy też przyczyna problemu znajduje się poza Query Store.

Dokumentacja powinna zawierać datę operacji, zakres usuniętych danych, powód działania, osobę wykonującą czynność oraz wynik późniejszej obserwacji. Taki zapis ułatwia odtworzenie historii zmian i ogranicza ryzyko wielokrotnego wykonywania resetu bez wyciągania wniosków. W przypadku baz związanych z ważnymi procesami należy także sprawdzić procedury kopii zapasowych, dostępu i zatwierdzania zmian.

Kiedy zgłosić się w sprawie Resetowania danych Query Store

Pomoc techniczna może być potrzebna, gdy nie jest jasne, czy problem dotyczy Query Store, planu wykonania, zapytania, indeksów, blokad albo konfiguracji systemu. Szczególnej ostrożności wymaga sytuacja, w której dane mają znaczenie dla ustalenia przyczyny awarii, a historia nie została jeszcze zapisana w raporcie. W takim przypadku resetowanie może zamknąć dostęp do ważnych dowodów diagnostycznych, dlatego najpierw powinno się zebrać informacje i określić bezpieczny zakres działania.

Wsparcie przy analizie sprzętu i oprogramowania komputerowego można uzyskać w firmie Warszawskie Pogotowie Komputerowe 24/7 pod numerem +48 22 100 48 29. Przed zgłoszeniem warto przygotować opis objawów, nazwę używanej wersji SQL Server, moment pojawienia się problemu, informacje o ostatnich zmianach oraz komunikaty z dzienników. Przydatne są także wyniki zapytań diagnostycznych i informacja, czy Query Store był wcześniej czyszczony.

Do serwisu warto zgłosić się również wtedy, gdy spowolnienie dotyczy całego komputera, aplikacja przestaje odpowiadać, występują błędy dostępu do danych albo pojawiają się problemy z nośnikiem. W takiej sytuacji analiza powinna obejmować zarówno warstwę programową, jak i stan komputera, ponieważ objawy widoczne w bazie nie zawsze mają źródło w samym Query Store. Najbezpieczniejsza decyzja opiera się na zachowaniu dostępnej historii, kontroli zakresu operacji i sprawdzeniu efektów po ponownym rozpoczęciu zbierania danych.