SYS.query_store_query_text

sys.query_store_query_text przechowuje treść zapytań zarejestrowanych w Query Store.

SYS.query_store_query_text – czym jest zapis treści zapytań

Widok systemowy SYS.query_store_query_text należy do mechanizmu Query Store w Microsoft SQL Server i służy do odczytywania tekstów zapytań, które zostały zarejestrowane w magazynie zapytań. Każdy zapis reprezentuje treść polecenia SQL powiązaną z identyfikatorem tekstu. Sam widok nie opisuje całego wykonania zapytania, nie pokazuje planu ani statystyk czasowych. Dostarcza przede wszystkim informacji o tym, jakie polecenie zostało przekazane do silnika bazy danych.

W praktyce SYS.query_store_query_text jest jednym z elementów większego modelu danych Query Store. Tekst zapytania można połączyć z widokiem sys.query_store_query, a następnie z obiektami opisującymi kontekst wykonania, plan oraz agregowane statystyki. Dzięki temu możliwe staje się przejście od samego tekstu SQL do odpowiedzi na pytania: z jakiego obiektu pochodzi zapytanie, w jakim kontekście zostało skompilowane, jakie plany mu przypisano i jak zmieniało się jego wykonanie w czasie.

Warto rozróżnić tekst zapytania od jego identyfikatora. Identyfikator tekstu nie jest samym poleceniem i nie powinien być traktowany jako stabilny opis logiki aplikacji. Jest kluczem używanym do powiązania danych w Query Store. Treść odczytuje się z odpowiedniej kolumny widoku, a szczegóły pozostałych elementów ustala przez relacje z innymi widokami systemowymi.

SYS.query_store_query_text w kontekście Query Store i porównań

Query Store przechowuje informacje o zapytaniach, planach oraz statystykach ich wykonania. SYS.query_store_query_text pełni w tym układzie rolę warstwy tekstowej. Widok sys.query_store_query opisuje zapytanie jako obiekt rozpoznany przez Query Store i wskazuje między innymi identyfikator tekstu, kontekst kompilacji oraz identyfikator obiektu, jeżeli zapytanie jest związane z procedurą lub innym modułem. Z kolei widoki dotyczące planów pozwalają ustalić, jaki plan wykonania został zapisany dla danego zapytania.

Podstawowe połączenie może wyglądać następująco:

SELECT
    q.query_id,
    qt.query_sql_text,
    q.object_id,
    q.context_settings_id
FROM sys.query_store_query AS q
JOIN sys.query_store_query_text AS qt
    ON qt.query_text_id = q.query_text_id
ORDER BY q.query_id;

Takie zapytanie pokazuje tekst razem z identyfikatorem Query Store. W większym rozpoznaniu można dołączyć także sys.query_store_plan, sys.query_store_runtime_stats oraz sys.query_store_runtime_stats_interval. Pozwala to zestawić treść z planami i przedziałami czasu, w których gromadzono dane. Należy jednak pamiętać, że jeden tekst może występować w wielu kontekstach, a jedno zapytanie może mieć kilka planów. Bez sprawdzenia relacji między identyfikatorami łatwo wyciągnąć błędny wniosek, że każda podobna treść oznacza dokładnie ten sam obiekt logiczny.

Istotna jest także różnica między tekstem a zapytaniem po parametryzacji. Dwa polecenia mogą być podobne funkcjonalnie, ale różnić się sposobem zapisania parametrów, komentarzami, białymi znakami albo kontekstem ustawień sesji. W rezultacie mogą pojawić się osobne rekordy lub osobne identyfikatory. Przy porównywaniu należy analizować pełną treść, sposób powiązania z query_id oraz dane o kompilacji, zamiast porównywać jedynie początek polecenia.

SYS.query_store_query_text a typowe problemy diagnostyczne

Jednym z częstych problemów jest brak oczekiwanego zapytania w wynikach. Nie musi to oznaczać błędu widoku. Query Store może być wyłączony dla konkretnej bazy, znajdować się w stanie przejściowym, mieć ograniczoną politykę przechowywania albo nie zarejestrować jeszcze danego wykonania. Najpierw warto sprawdzić stan Query Store w widokach katalogowych oraz upewnić się, że analizowana jest właściwa baza danych.

Drugą trudnością jest interpretacja pustego lub skróconego tekstu. Na widoczność treści mogą wpływać właściwości zapytania, sposób przechowywania danych oraz ograniczenia wynikające z typu obiektu. Tekst przechowywany w Query Store nie zawsze powinien być traktowany jako kompletna dokumentacja źródłowa aplikacji. Do analizy należy zachować oryginalne skrypty, definicje procedur i informacje o wersji wdrożenia.

Problemem bywa także mnożenie pozornie takich samych rekordów. Przyczyną może być inny kontekst ustawień, odmienny obiekt nadrzędny, zmiana sposobu parametryzacji lub modyfikacja samego polecenia. Dlatego przy analizie duplikatów warto wyświetlić co najmniej query_text_id, query_id, object_id oraz ustawienia kontekstu. Sam tekst SQL nie zawsze wystarcza do ustalenia, czy mamy do czynienia z tym samym przypadkiem.

Nie należy też utożsamiać treści zapytania z przyczyną spowolnienia. SYS.query_store_query_text pokazuje, co zostało zapisane, lecz nie odpowiada bezpośrednio na pytanie, dlaczego wykonanie trwało długo. Do takiej oceny potrzebne są statystyki czasu, liczby odczytów, liczby wykonań, zużycia zasobów oraz informacje o planie. Dopiero połączenie tych danych pozwala odróżnić ciężkie zapytanie od problemu wynikającego z chwilowego obciążenia, blokowania lub niekorzystnej zmiany planu.

SYS.query_store_query_text – praktyczne wskazówki pracy

Analizę warto rozpoczynać od ograniczenia zakresu. Przydatne jest filtrowanie po query_id, identyfikatorze obiektu, czasie rejestracji lub charakterystycznym fragmencie query_sql_text. Wyszukiwanie po fragmencie może być pomocne, ale powinno być stosowane ostrożnie, ponieważ podobne konstrukcje mogą występować w wielu niezależnych poleceniach. Przy powtarzalnych analizach lepiej zapisać zapytanie raportowe, które pokazuje relacje między tekstem, obiektem, planem i statystykami.

Podczas odczytu należy stosować aliasy i jednoznacznie wskazywać kolumny. W przykładach szkoleniowych można użyć:

SELECT
    qt.query_text_id,
    qt.query_sql_text
FROM sys.query_store_query_text AS qt
WHERE qt.query_sql_text LIKE N'%SELECT%'
ORDER BY qt.query_text_id;

Filtr tego rodzaju ma charakter orientacyjny. Nie jest dowodem, że każde znalezione polecenie jest istotne diagnostycznie, ponieważ słowo występujące w komentarzu lub w ciągu znaków również może spełnić warunek. W raportach operacyjnych lepiej łączyć wyszukiwanie tekstowe z informacjami z sys.query_store_query i statystykami wykonania.

Warto zachować ostrożność przy interpretowaniu zmian w czasie. Query Store może zawierać dane z wielu okresów, a retencja może usuwać starsze wpisy. Porównanie dwóch raportów ma sens tylko wtedy, gdy wiadomo, jaki przedział obejmują dane, czy zmieniła się konfiguracja Query Store oraz czy porównywane identyfikatory nadal odnoszą się do tych samych obiektów. Przy audycie dobrze jest zapisać datę analizy, nazwę bazy, wersję środowiska i zastosowane filtry.

Jeżeli tekst zawiera dane wrażliwe, wyniki powinny być udostępniane wyłącznie osobom uprawnionym. Treść SQL może ujawniać nazwy tabel, schematów, procedur, kolumn oraz reguły działania aplikacji. Sam widok jest przydatny w diagnostyce, ale dostęp do niego powinien być częścią przemyślanej polityki uprawnień.

Kiedy zgłosić się z problemem SYS.query_store_query_text do serwisu

Pomoc techniczna może być potrzebna, gdy zapytania znikają z Query Store, identyfikatory nie układają się w oczekiwane relacje, raporty pokazują niespójne teksty albo analiza planów nie prowadzi do jednoznacznej przyczyny spowolnienia. Przed zgłoszeniem warto przygotować nazwę bazy, fragment raportu, przedział czasu, identyfikator query_id oraz informację, czy problem dotyczy jednego zapytania, czy większej grupy.

Warszawskie Pogotowie Komputerowe 24/7 może pomóc w uporządkowaniu materiału diagnostycznego, sprawdzeniu podstawowej konfiguracji środowiska i rozdzieleniu problemu z rejestracją treści od problemu z planem lub wykonaniem. Im dokładniej opisano objawy i moment ich wystąpienia, tym łatwiej odtworzyć tok analizy oraz wskazać dalsze działania.

Najważniejsza zasada brzmi: SYS.query_store_query_text należy traktować jako źródło treści zapytań, a nie samodzielny raport wydajności. Pełna diagnoza wymaga zestawienia tekstu z identyfikatorami Query Store, planami, statystykami wykonania, ustawieniami kontekstu i informacjami o zmianach w bazie. Takie podejście ogranicza ryzyko pochopnej optymalizacji i ułatwia sprawdzenie, czy poprawa dotyczy rzeczywistej przyczyny problemu.