SYS.database_query_store_options

sys.database_query_store_options zwraca aktualną konfigurację Query Store dla danej bazy.

SYS.database_query_store_options — czym jest konfiguracja Query Store

Widok sys.database_query_store_options służy do odczytania bieżących ustawień funkcji Query Store w konkretnej bazie danych Microsoft SQL Server. Query Store gromadzi informacje o wykonywanych zapytaniach, planach wykonania oraz statystykach wydajności, dzięki czemu można obserwować zachowanie obciążenia w czasie. Sam widok nie prezentuje historii zapytań ani nie zastępuje widoków przeznaczonych do analizy planów. Pokazuje natomiast, w jaki sposób mechanizm został skonfigurowany i czy może aktualnie zbierać dane.

Zapytanie do widoku wykonuje się w kontekście wybranej bazy, ponieważ ustawienia Query Store są przechowywane na poziomie bazy danych. Typowy odczyt ma postać SELECT * FROM sys.database_query_store_options;. Wynik zawiera zestaw kolumn opisujących między innymi stan funkcji, tryb pracy, sposób przechowywania danych, limity rozmiaru, interwał zbierania statystyk oraz zasady czyszczenia starszych informacji. W praktyce jest to punkt wyjścia do oceny, czy analiza wydajności będzie oparta na kompletnych i aktualnych danych.

SYS.database_query_store_options a ustawienia zbierania danych

Najważniejszą informacją jest stan Query Store. Jeżeli funkcja jest wyłączona, widok nadal może zwracać konfigurację, ale nowe dane o zapytaniach nie będą rejestrowane. Włączenie mechanizmu nie oznacza jednak, że każda analiza od razu pokaże pełny obraz. Najpierw muszą zostać wykonane zapytania, a SQL Server potrzebuje czasu na zapisanie statystyk i planów. Przy krótkiej obserwacji pusty lub skromny zestaw danych nie musi więc wskazywać na awarię.

Istotny jest również tryb pracy. Ustawienie określające, czy Query Store działa w trybie odczytu i zapisu, tylko odczytu albo jest zatrzymany, wpływa na możliwość rejestrowania kolejnych zdarzeń. Tryb tylko do odczytu bywa stosowany po przekroczeniu dostępnego miejsca lub podczas czynności administracyjnych. W takiej sytuacji wcześniejsze dane mogą być dostępne, lecz nowe zapytania nie zostaną dopisane do repozytorium. Przy interpretacji wyników należy zestawić ten parametr z rozmiarem magazynu oraz regułami usuwania danych.

Ważnym elementem jest interwał zbierania statystyk. SQL Server nie musi zapisywać informacji po każdym pojedynczym wykonaniu zapytania. Statystyki mogą być agregowane w określonych przedziałach, co ogranicza narzut zapisu i ułatwia analizę trendów. Krótszy interwał daje bardziej szczegółowy obraz zmian, ale może zwiększać ilość danych. Dłuższy przedział upraszcza przechowywanie, lecz może utrudnić uchwycenie krótkich skoków czasu wykonania.

Wynik widoku warto porównywać z konfiguracją ustaloną dla konkretnej wersji SQL Server. Dostępne kolumny, wartości domyślne i znaczenie niektórych opcji mogą zależeć od wersji silnika oraz poziomu zgodności bazy. Z tego powodu bezpieczniej jest analizować nazwy i wartości razem z dokumentacją używanej wersji, zamiast przenosić bez sprawdzenia ustawienia z innego środowiska.

SYS.database_query_store_options w porównaniu z historią planów

Widok konfiguracji odpowiada na pytanie, jak działa Query Store, ale nie odpowiada bezpośrednio na pytanie, które zapytanie zużywa najwięcej zasobów. Do analizy treści zapytań, planów i statystyk służą inne obiekty systemowe, między innymi widoki z rodziny sys.query_store_query, sys.query_store_query_text, sys.query_store_plan oraz sys.query_store_runtime_stats. Dopiero połączenie tych danych pozwala przejść od ustawień do konkretnej diagnozy.

Można przyjąć prosty podział. sys.database_query_store_options opisuje warunki obserwacji, widoki zapytań identyfikują rejestrowane instrukcje, widoki planów pokazują warianty optymalizacji, a statystyki wykonania wskazują między innymi czas trwania, zużycie procesora, odczyty i liczbę wykonań. Taki podział pomaga uniknąć błędnego wniosku, że sam odczyt opcji ujawni przyczynę spowolnienia.

Query Store różni się od doraźnego podglądu aktywnych sesji. Narzędzia monitorujące bieżące wykonania pokazują stan w konkretnej chwili, natomiast Query Store przechowuje dane umożliwiające porównanie okresów i planów. Dzięki temu można sprawdzić, czy czas wykonania pogorszył się po zmianie planu, aktualizacji statystyk, modyfikacji indeksu albo zmianie parametrów aplikacji. Warunkiem jest jednak odpowiednio długa historia i prawidłowo ustawione czyszczenie danych.

Warto rozdzielić retencję danych od limitu rozmiaru. Retencja określa, jak długo informacje mają być zachowywane, a limit rozmiaru wskazuje, ile miejsca może zająć magazyn Query Store. Jeżeli przyjęte wartości nie są dopasowane do aktywności bazy, starsze dane mogą być usuwane szybciej, niż zakładano, albo mechanizm może przejść w tryb ograniczający zapis. Odczyt wszystkich opcji przed analizą pozwala ocenić wiarygodność dostępnej historii.

SYS.database_query_store_options i typowe problemy diagnostyczne

Jednym z częstych problemów jest sprawdzanie widoku w niewłaściwej bazie. Ponieważ konfiguracja Query Store nie jest globalnym ustawieniem całej instancji, wynik należy interpretować w kontekście bazy, której dotyczy problem. W narzędziu administracyjnym trzeba potwierdzić wybraną bazę przed wykonaniem zapytania. Pomyłka w kontekście może prowadzić do wniosku, że funkcja jest wyłączona, mimo że działa poprawnie w innym miejscu.

Inną sytuacją jest brak oczekiwanych danych mimo włączonego Query Store. Przyczyną może być niewielka liczba wykonań, świeże włączenie funkcji, filtr czasu użyty podczas raportowania albo zbyt krótki okres obserwacji. Należy też sprawdzić, czy zapytania są faktycznie wykonywane w tej bazie oraz czy analizowany użytkownik ma uprawnienia pozwalające na odczyt odpowiednich widoków.

Problemy może powodować przepełnienie magazynu. Po osiągnięciu limitu SQL Server może ograniczyć zapisywanie kolejnych informacji. Wtedy przydatne jest sprawdzenie kolumn dotyczących rozmiaru, stanu operacyjnego i zasad czyszczenia. Samo zwiększenie limitu nie rozwiązuje każdego problemu, ponieważ trzeba również uwzględnić dostępne miejsce, tempo przyrostu danych oraz zakres potrzebnej historii.

Ostrożności wymaga zmiana trybu pracy podczas diagnostyki. Wyłączenie Query Store usuwa możliwość gromadzenia nowych danych w okresie, który może być kluczowy dla rozpoznania problemu. Przed modyfikacją ustawień warto zapisać aktualny wynik widoku, zanotować przyczynę zmiany i ustalić sposób powrotu do poprzedniej konfiguracji. Zmiany powinny być wykonywane w kontrolowanym oknie administracyjnym, z uwzględnieniem znaczenia danej bazy dla użytkowników.

SYS.database_query_store_options — praktyczne wskazówki odczytu

Na początku warto wykonać pełny odczyt kolumn, a następnie przygotować krótsze zapytanie zawierające tylko parametry istotne dla konkretnego zadania. Pełny wynik ułatwia rozpoznanie dostępnych ustawień, natomiast ograniczony zestaw jest wygodniejszy w raportach i dokumentacji. Przy porównywaniu dwóch baz należy stosować tę samą listę kolumn oraz zapisywać datę odczytu, ponieważ konfiguracja może zmieniać się w trakcie prac administracyjnych.

Dobrą praktyką jest zestawienie opcji z obserwowanym okresem. Jeżeli analizowany jest incydent z ostatnich godzin, należy sprawdzić, czy retencja, interwał statystyk i stan zapisu pozwalają zebrać wystarczająco szczegółowe dane. Jeżeli celem jest analiza wielotygodniowa, trzeba zweryfikować, czy magazyn nie usuwa starszych informacji przed zakończeniem obserwacji. Wnioski powinny uwzględniać te ograniczenia.

W przypadku zmiany planu wykonania warto przejść przez kilka etapów: potwierdzić stan Query Store, znaleźć zapytanie, porównać plany, zestawić statystyki wykonania i dopiero później oceniać możliwe działania. Sam fakt istnienia wielu planów nie oznacza jeszcze problemu. Znaczenie ma ich czas aktywności, częstotliwość użycia i różnica w kosztach rzeczywistego wykonania. Pomocne bywa także sprawdzenie, czy zmiana wiąże się z innym zestawem parametrów lub zmianą danych.

SYS.database_query_store_options — kiedy zgłosić się do serwisu

Do serwisu warto zgłosić się wtedy, gdy odczyt konfiguracji jest niejasny, Query Store przechodzi w ograniczony tryb pracy, historia znika szybciej niż zakładano albo różne bazy zachowują się odmiennie mimo podobnych ustawień. Warszawskie Pogotowie Komputerowe 24/7 może pomóc uporządkować informacje o konfiguracji, przygotować bezpieczny plan diagnostyczny i rozdzielić problem ustawień od problemu z konkretnym zapytaniem.

Przed zgłoszeniem dobrze przygotować wersję SQL Server, nazwę bazy, wynik odczytu sys.database_query_store_options, przybliżony moment wystąpienia spowolnienia oraz informację, czy problem dotyczy wszystkich zapytań, czy tylko wybranych. Nie należy wklejać danych uwierzytelniających ani treści zawierających poufne informacje. Zebrany kontekst ułatwia ocenę stanu i ogranicza ryzyko przypadkowej zmiany ustawień podczas rozpoznania.

Jeżeli problem pojawia się cyklicznie, warto zachować kilka odczytów wykonanych w różnych momentach. Porównanie wyników może ujawnić przejście w tryb tylko do odczytu, zmianę rozmiaru magazynu albo modyfikację retencji. Tak przygotowana dokumentacja jest użyteczna zarówno podczas samodzielnej pracy administratora, jak i przy przekazaniu sprawy do serwisu, ponieważ pokazuje nie tylko aktualny stan, lecz także jego zmienność.