SYS.query_store_query

sys.query_store_query zawiera metadane zapytań śledzonych przez mechanizm Query Store.

SYS.query_store_query jako opis zapytań w Query Store

SYS.query_store_query to widok katalogowy Microsoft SQL Server, który przechowuje metadane dotyczące zapytań rejestrowanych przez mechanizm Query Store. Nie jest to tabela z pełnym tekstem każdego zapytania ani bezpośredni zapis historii wszystkich uruchomień. Jego zadaniem jest powiązanie rozpoznanego zapytania z bazą danych, kontekstem obiektu, ustawieniami kompilacji oraz innymi elementami potrzebnymi do dalszej analizy planów wykonania i statystyk czasu działania.

W praktyce pojedynczy wpis opisuje zapytanie rozpoznawane przez Query Store w określonym kontekście. Ten kontekst ma znaczenie, ponieważ podobny tekst SQL może być analizowany odmiennie zależnie od bazy danych, obiektu, z którego został wywołany, albo ustawień wpływających na kompilację. Widok pomaga więc odróżnić samo zapytanie od jego planów wykonania i od agregowanych danych runtime. Do pełnego obrazu zwykle potrzebne jest zestawienie go z widokami sys.query_store_query_text, sys.query_store_plan, sys.query_store_runtime_stats oraz sys.query_store_runtime_stats_interval.

Warto rozdzielić trzy pojęcia. Tekst zapytania opisuje jego treść, rekord w SYS.query_store_query opisuje zapytanie jako obiekt śledzony przez Query Store, a plan wykonania pokazuje sposób realizacji operacji przez optymalizator. Jedno zapytanie może mieć więcej niż jeden plan, jeżeli w czasie jego życia zmieniły się warunki optymalizacji, statystyki, indeksy, ustawienia bazy albo inne elementy środowiska. Z kolei statystyki runtime przedstawiają zagregowane wykonania w określonych przedziałach czasu.

Znaczenie SYS.query_store_query w kontekście planów i zapytań

Najważniejszą rolą SYS.query_store_query jest dostarczenie identyfikatora, za pomocą którego można łączyć informacje rozproszone po katalogu Query Store. W analizie problemu z wydajnością sam tekst zapytania często nie wystarcza. Potrzebne jest ustalenie, jaki plan był używany, w jakim okresie zbierano dane, ile trwały wykonania, jaką miały zmienność oraz czy problem pojawił się po zmianie planu. Widok sys.query_store_query stanowi jeden z punktów wejścia do takiego powiązania.

Wśród istotnych informacji znajdują się między innymi query_id, query_text_id oraz context_settings_id. query_text_id wskazuje tekst przechowywany przez Query Store. context_settings_id prowadzi do ustawień kontekstu, w którym zapytanie było kompilowane lub wykonywane. Dzięki temu można sprawdzić, czy różnice między pozornie podobnymi wpisami wynikają z odmiennych ustawień sesji, takich jak opcje wpływające na zachowanie optymalizatora lub sposób interpretacji instrukcji.

Ważne są także identyfikatory obiektu i schematu, gdy zapytanie jest związane z modułem bazy danych, na przykład procedurą składowaną, funkcją albo wyzwalaczem. Wartości wskazujące obiekt nie zawsze będą dostępne dla instrukcji ad hoc. Brak identyfikatora obiektu nie musi zatem oznaczać błędu w Query Store. Może po prostu wskazywać, że zapytanie nie pochodzi z trwałego modułu.

Wersja serwera ma znaczenie dla dokładnego zestawu kolumn, ich typów oraz dostępnych zależności. Przy tworzeniu skryptów diagnostycznych należy sprawdzić dokumentację właściwą dla używanej wersji SQL Server i poziomu zgodności bazy. Nie powinno się zakładać, że każdy serwer udostępnia identyczny schemat katalogu. W środowisku po migracji lub aktualizacji warto porównać metadane widoku z zapytaniami używanymi przez narzędzia monitorujące.

SYS.query_store_query a typowe problemy z wydajnością

SYS.query_store_query jest szczególnie przydatny podczas badania regresji planu. Taka sytuacja występuje wtedy, gdy zapytanie wcześniej wykonywało się sprawnie, a po zmianie planu jego czas działania, zużycie procesora, liczba odczytów albo zapotrzebowanie na pamięć wyraźnie wzrosły. Sam rekord zapytania nie rozstrzyga jeszcze przyczyny, ale pozwala odnaleźć odpowiednie plany i przedziały statystyk runtime.

Typowy przebieg analizy obejmuje odszukanie query_id, odczyt tekstu przez połączenie z sys.query_store_query_text, a następnie zestawienie tego identyfikatora z sys.query_store_plan. Kolejny krok polega na porównaniu danych z sys.query_store_runtime_stats w czasie. Należy zwrócić uwagę nie tylko na średnią, lecz także na wartości minimalne, maksymalne, odchylenie i liczbę wykonań. Średnia może ukrywać problem występujący wyłącznie przy określonych parametrach lub w godzinach większego obciążenia.

Jednym z częstych błędów jest traktowanie query_id jak stałego identyfikatora tekstu SQL niezależnego od wszystkich warunków. Query Store rozpoznaje zapytania w określonym kontekście, a zmiana bazy, modułu lub ustawień może prowadzić do powstania odrębnych wpisów. Innym błędem jest porównywanie dwóch rekordów wyłącznie na podstawie skróconego tekstu, bez uwzględnienia plan_id, czasu zbierania statystyk i kontekstu ustawień.

Problemy mogą wynikać również z retencji danych. Jeżeli Query Store ma ograniczony rozmiar albo ustawiono automatyczne czyszczenie, starsze plany i statystyki mogą nie być już dostępne. W takiej sytuacji brak danych w zapytaniu diagnostycznym nie dowodzi, że instrukcja nigdy nie była wykonywana. Trzeba sprawdzić konfigurację Query Store, stan jego działania, czas ostatniego czyszczenia oraz zakres zachowanych przedziałów.

SYS.query_store_query i praktyczne wskazówki diagnostyczne

Przed uruchomieniem analizy należy ustalić, czy Query Store jest włączony dla właściwej bazy oraz czy jego dane są aktualne. Warto sprawdzić stan zbierania, tryb pracy, rozmiar magazynu i ewentualne komunikaty o ograniczeniu miejsca. Dane katalogowe powinny być interpretowane razem z czasem ostatniego odświeżenia, ponieważ opóźnienie agregacji może powodować różnicę między bieżącym zachowaniem zapytania a obrazem widocznym w statystykach.

Podczas łączenia widoków należy stosować jawne warunki po identyfikatorach. Najczęściej query_id łączy się z query_text_id, plan_id oraz danymi runtime. Tekst zapytania powinien być traktowany jako materiał diagnostyczny, a nie jako bezwarunkowo bezpieczny tekst do dalszego składania dynamicznego SQL. Jeżeli wynik ma być używany w automatycznym raporcie, należy ograniczyć zakres kolumn, sortować po jednoznacznych kluczach i uwzględnić możliwość wystąpienia wartości pustych.

Przydatne jest zapisywanie daty analizy, wersji serwera, nazwy bazy oraz parametrów użytych do filtrowania. Ułatwia to odtworzenie wniosków po zmianie konfiguracji. Warto również zachować informację, czy porównanie dotyczy wszystkich wykonań, czy tylko wybranego przedziału. W przeciwnym razie sezonowość, jednorazowe zadania lub nocne operacje utrzymaniowe mogą zostać pomylone z typowym zachowaniem aplikacji.

Nie należy usuwać danych Query Store tylko dlatego, że raport zawiera dużo wpisów. Czyszczenie może pozbawić zespół materiału potrzebnego do porównania przed i po zmianie indeksu, aktualizacji statystyk albo modyfikacji kodu. Lepszym podejściem jest przemyślana retencja, kontrola rozmiaru i selektywne filtrowanie raportów. Usunięcie danych powinno być poprzedzone oceną, czy nie są potrzebne do analizy długoterminowego trendu.

Kiedy analizować SYS.query_store_query w serwisie komputerowym

Do analizy SYS.query_store_query warto wrócić, gdy aplikacja korzystająca z SQL Server zaczyna działać nierówno, raporty wykonują się wyraźnie dłużej, a czas odpowiedzi zmienia się mimo braku zmian w interfejsie. Zgłoszenie jest zasadne także wtedy, gdy po aktualizacji programu, zmianie struktury bazy lub odtworzeniu danych pojawiają się blokady, wysokie obciążenie procesora albo nagłe skoki użycia pamięci. Przed przekazaniem urządzenia lub środowiska do oceny dobrze przygotować nazwę bazy, przybliżony moment wystąpienia problemu, opis objawów i dostępne wyniki z Query Store.

Warszawskie Pogotowie Komputerowe 24/7 zajmuje się diagnostyką laptopa i komputerów PC, dlatego przy problemach z narzędziami bazodanowymi można przekazać opis objawów wraz z bezpiecznie usuniętymi danymi poufnymi. Szczególnie pomocne są zrzuty wyników pokazujące query_id, plan_id, przedziały czasowe oraz podstawowe statystyki wykonania, bez haseł, danych klientów i pełnej treści wrażliwych zapytań.

W przypadku awarii należy odróżnić problem samego SQL Server od problemu sprzętowego, systemowego lub sieciowego. Spowolnienie może być skutkiem nieoptymalnego planu, lecz także braku wolnego miejsca, uszkodzeń nośnika, przegrzewania, błędów pamięci, nieprawidłowych sterowników albo przerw w komunikacji. Odczyt SYS.query_store_query pomaga zawęzić obszar poszukiwań, ale nie zastępuje pełnej oceny całego środowiska. Zebrane wcześniej informacje skracają drogę do rozpoznania przyczyny i ułatwiają bezpieczne zaplanowanie dalszych działań.