SYS.query_store_runtime_stats

sys.query_store_runtime_stats zawiera zebrane dane wydajnościowe dla poszczególnych planów zapytań.

Gdzie w SQL Server powstają te informacje

sys.query_store_runtime_stats należy do widoków systemowych funkcji Query Store w Microsoft SQL Server. Query Store zapisuje historię wykonywania zapytań, dzięki czemu można analizować zmiany wydajności także po zakończeniu konkretnego połączenia lub ponownym uruchomieniu instancji. Dane nie opisują pojedynczego wywołania w takiej postaci, jak robi to bieżący monitoring sesji. Są agregowane dla planu zapytania oraz przedziału czasowego używanego przez Query Store.

Wiersz w tym widoku należy interpretować razem z identyfikatorem planu i identyfikatorem przedziału statystyk. Sam rekord nie zawiera pełnego tekstu polecenia ani kompletnego planu wykonania. Powiązanie z innymi widokami Query Store pozwala przejść od zagregowanych wartości do zapytania, jego kontekstu oraz XML-a planu. W praktyce analizę zaczyna się od znalezienia zapytania i planu, a dopiero później ocenia się jego czas działania, zużycie procesora oraz operacje wejścia-wyjścia.

Query Store rozdziela statystyki według typu wykonania, dlatego nie należy bez sprawdzenia sumować wszystkich rekordów. W zależności od wersji SQL Server mogą być widoczne między innymi wykonania zakończone powodzeniem oraz wykonania zakończone błędem. Znaczenie kolumn i dostępny zakres danych zależą od wersji silnika, ustawień Query Store oraz zgodności bazy danych. Warto więc weryfikować metadane w dokumentacji odpowiadającej używanej wersji SQL Server.

Jak czytać agregaty i łączyć je z planem

Widok udostępnia między innymi liczbę wykonań, czasy minimalne, maksymalne i średnie, odchylenie czasu, a także wartości związane z procesorem, odczytami logicznymi i fizycznymi, zapisem logicznym, pamięcią, liczbą zwróconych wierszy oraz wykorzystaniem tempdb. Dostępność części kolumn jest zależna od wydania SQL Server. Jednostki również mają znaczenie: czas należy odczytywać zgodnie z opisem danej kolumny, a wartości dotyczące operacji dyskowych lub pamięci rozumieć jako miary agregowane, nie jako bezpośredni pomiar szybkości konkretnego urządzenia.

Średnia nie zastępuje rozkładu wyników. Niski średni czas może ukrywać pojedyncze wykonania trwające znacznie dłużej, natomiast wysoka średnia przy dużej liczbie krótkich wykonań nie musi oznaczać problemu dla każdej sesji. Przydatne jest zestawienie minimum, maksimum, odchylenia i liczby wykonań w kolejnych przedziałach czasu. Jeżeli czas rośnie po pojawieniu się innego planu, trzeba porównać plany, parametry zapytania, aktualność statystyk oraz zmiany danych, a nie wyciągać wniosku wyłącznie z jednej kolumny.

Do rozpoznania źródła problemu przydają się powiązania z sys.query_store_runtime_stats_interval, sys.query_store_query, sys.query_store_query_text i sys.query_store_plan. Przedział statystyk pokazuje ramy czasowe agregacji. Informacje o zapytaniu pomagają odróżnić podobne polecenia wykonywane w różnych kontekstach. Widok tekstów ujawnia treść polecenia, a widok planów pozwala sprawdzić, czy zmieniły się operatory, kolejność złączeń, sposób dostępu do indeksów albo szacowana liczba wierszy.

Wyniki należy odnosić do konfiguracji Query Store: trybu działania, interwału agregacji, limitu miejsca, zasad czyszczenia oraz ewentualnego ograniczania zbierania danych. Brak rekordu nie dowodzi, że zapytanie nigdy się nie wykonało. Dane mogły zostać usunięte przez mechanizm przechowywania, zapytanie mogło nie spełnić warunków rejestrowania albo Query Store mógł być wyłączony, niedostępny lub przejściowo nie zapisywać informacji.

Rozbieżności, które wymagają ostrożnej interpretacji

Jednym z częstych pytań jest to, dlaczego widok pokazuje kilka rekordów dla tego samego zapytania. Przyczyną może być więcej niż jeden plan, kilka przedziałów czasowych albo różne typy wykonania. Inną przyczyną jest zmiana kontekstu zapytania, na przykład inny obiekt nadrzędny lub inna reprezentacja polecenia. Sam identyfikator zapytania nie powinien być traktowany jako dowód, że wszystkie rekordy opisują identyczny przebieg w identycznych warunkach.

Problemy z wydajnością mogą wynikać z planu, lecz statystyki runtime nie wskazują automatycznie jednej przyczyny. Wysoki czas procesora może oznaczać koszt obliczeń, dużą liczbę przetwarzanych wierszy albo niekorzystny plan. Dużo odczytów logicznych wskazuje na intensywną pracę z pamięcią buforową, ale nie przesądza jeszcze o uszkodzeniu dysku. Odczyty fizyczne mogą zależeć od stanu pamięci, konkurencji między zapytaniami i bieżącego obciążenia. Wysokie użycie tempdb wymaga sprawdzenia konkretnego planu oraz operacji, które korzystają z obszaru roboczego.

Warto też sprawdzić, czy porównywane okresy mają podobny charakter obciążenia. Raport z godzin szczytu nie jest bezpośrednio porównywalny z raportem z okresu nocnego, jeżeli zmienia się liczba użytkowników, rozmiar wyników lub rodzaj parametrów. Zmiana planu może być skutkiem aktualizacji danych, zmiany indeksów, aktualizacji statystyk, ustawień bazy albo parametrów kompilacji. Query Store dostarcza śladów do dalszej diagnozy, ale nie zastępuje analizy planu i testu na danych zbliżonych do produkcyjnych.

Jeżeli wartości znikają albo pojawiają się z opóźnieniem, należy zweryfikować stan Query Store i komunikaty SQL Server. Trzeba również uwzględnić, że agregacja odbywa się w przedziałach, więc najnowsze wykonania mogą nie być jeszcze widoczne jako zamknięty okres. Ręczne czyszczenie historii, zmiana ustawień przechowywania lub przekroczenie limitu miejsca może zmienić zakres dostępnych danych i utrudnić porównanie z wcześniejszym raportem.

Co sprawdzić przed wizytą w punkcie naprawy

Analiza tego widoku dotyczy działania bazy danych i konfiguracji SQL Server, natomiast nie każda przyczyna opóźnień leży w samym silniku. Gdy komputer działa wolno także poza aplikacją bazodanową, warto zanotować objawy: czas uruchamiania systemu, zawieszanie programów, nietypowe dźwięki nośnika, restarty, przegrzewanie oraz komunikaty o błędach. Takie informacje pomagają oddzielić problem logiczny zapytania od problemu z pamięcią, zasilaniem, chłodzeniem albo nośnikiem danych.

Przed przekazaniem sprzętu dobrze zabezpieczyć kopię ważnych plików i przygotować informacje o modelu komputera, systemie, ostatnich zmianach oraz momencie pojawienia się objawów. Nie należy kasować historii Query Store tylko po to, aby „odświeżyć” wyniki, ponieważ usuwa to materiał przydatny do porównania. Jeżeli problem dotyczy stabilności fizycznego komputera, Warszawskie Pogotowie Komputerowe wykonuje diagnostykę i naprawę laptopów, komputerów stacjonarnych oraz ich podzespołów, w tym płyt głównych, dysków, pamięci, układów zasilania, matryc i klawiatur.

W przypadku podejrzenia uszkodzenia nośnika priorytetem jest ograniczenie dalszej pracy urządzenia i wykonanie kopii możliwą bezpieczną metodą. Podstawowy odzysk danych z uszkodzonych nośników może wymagać innego postępowania niż zwykła naprawa systemu. Wyniki z sys.query_store_runtime_stats mogą być wtedy cennym kontekstem, lecz nie zastępują kopii zapasowej, diagnostyki sprzętowej ani oceny, czy dane są odczytywane stabilnie.