| Termin | Definicja |
|---|---|
| Store Runtime Statistics | Store Runtime Statistics to funkcja Query Store gromadząca rzeczywiste dane o czasie i zasobach zużytych przez zapytanie. Store Runtime Statistics w Query StoreStore Runtime Statistics jest funkcją mechanizmu Query Store w Microsoft SQL Server. Jej zadaniem jest zapis rzeczywistych statystyk wykonania zapytań, a nie tylko informacji o samym planie wykonania. SQL Server może dzięki temu przechowywać dane opisujące czas trwania zapytania, zużycie procesora, liczbę odczytów logicznych i fizycznych oraz inne zasoby wykorzystane podczas wykonania. Statystyki są przypisywane do konkretnego zapytania, planu wykonania, kontekstu bazy danych i przedziału czasu. Mechanizm ma znaczenie przede wszystkim wtedy, gdy analiza nie może ograniczać się do jednorazowego uruchomienia zapytania w narzędziu SQL Server Management Studio. Pojedynczy plan może wyglądać poprawnie podczas testu, a jednocześnie powodować problemy przy większej liczbie użytkowników, innym zestawie parametrów albo większym obciążeniu systemu. Store Runtime Statistics pozwala porównywać rzeczywiste zachowanie tego samego zapytania w kolejnych okresach i zestawiać je z planami przechowywanymi przez Query Store. Jak SQL Server agreguje dane wykonawczeStatystyki wykonania są zapisywane w przedziałach czasu reprezentowanych przez obiekty Query Store Runtime Stats Interval. Dla każdego przedziału SQL Server gromadzi zagregowane wartości dotyczące wykonań danego planu. Nie oznacza to, że Query Store przechowuje pełny, osobny zapis każdego uruchomienia zapytania. Dane są podsumowaniem obserwacji z danego okresu, dlatego przy interpretacji należy uwzględnić długość przedziału oraz liczbę wykonań. W katalogu systemowym Query Store można sprawdzać te informacje między innymi przez widok Interpretacja czasu, CPU i operacji wejścia-wyjściaŚredni czas trwania wskazuje typowy koszt wykonania w analizowanym przedziale, ale nie pokazuje pełnego rozrzutu wyników. Dlatego warto porównywać go z wartościami minimalnymi, maksymalnymi i odchyleniem standardowym. Duża różnica między średnią a maksimum może wskazywać na niestabilność wykonania, zależność od parametrów, blokowanie, presję na zasoby albo zmianę planu. Sama wysoka średnia nie rozstrzyga jeszcze, czy problemem jest procesor, dysk, pamięć, blokady czy sposób dostępu do danych. Statystyki CPU pomagają odróżnić zapytania intensywnie wykorzystujące procesor od tych, które długo oczekują na inne zasoby. Z kolei odczyty logiczne pokazują liczbę stron danych przetworzonych w buforze, natomiast odczyty fizyczne wskazują na konieczność pobierania stron z magazynu danych. Duża liczba odczytów logicznych może oznaczać skanowanie większego zakresu tabeli lub indeksu, nie musi jednak oznaczać problemu z urządzeniem dyskowym. Przy ocenie należy również sprawdzić liczbę wierszy, plan wykonania i częstotliwość uruchomień, ponieważ krótkie zapytanie wykonywane bardzo często może obciążać system bardziej niż pojedyncze zapytanie trwające dłużej. Warto zwrócić uwagę na kolumny opisujące typ wykonania, w tym wykonania zakończone błędem, przerwane oraz odrzucone. Nie każdy wpis oznacza udane pobranie danych. Porównanie liczby wszystkich wykonań z czasem trwania i typem zakończenia pomaga ustalić, czy obserwowane opóźnienie dotyczy normalnego przebiegu zapytania, czy powtarzających się nieudanych prób. Kontrola konfiguracji i użycie danych w praktyceStore Runtime Statistics działa w ramach konfiguracji Query Store konkretnej bazy danych. Przy analizie trzeba sprawdzić, czy Query Store jest włączony, czy zbieranie statystyk jest aktywne oraz jaki tryb przechowywania danych został ustawiony. Istotne są również interwał agregacji, limit miejsca, sposób reagowania po zapełnieniu magazynu i okres czyszczenia danych. Zbyt krótka historia może usunąć informacje potrzebne do porównania, a zbyt szeroka interpretacja danych zagregowanych może prowadzić do błędnego wniosku o pojedynczym wykonaniu. Praktyczna analiza zwykle polega na połączeniu statystyk runtime z identyfikatorem zapytania, tekstem zapytania i planem wykonania, a następnie porównaniu kilku przedziałów czasu. Należy sprawdzić, czy wzrost czasu wystąpił jednocześnie ze wzrostem CPU, odczytów lub liczby wierszy. Jeżeli zmienił się plan, trzeba ocenić różnice w operatorach, sposobie dostępu do indeksów i szacowaniu liczności. Jeżeli plan pozostał taki sam, a czas wzrósł, przyczyny należy szukać również w blokowaniu, konkurencji o zasoby, zmianie danych wejściowych albo stanie środowiska wykonawczego. Diagnostyka na komputerze z narzędziami administracyjnymi powinna uwzględniać uprawnienia do odczytu widoków katalogowych Query Store oraz aktualny stan bazy. Same dane Store Runtime Statistics nie zastępują planu wykonania, dziennika błędów ani monitorowania blokad. Są warstwą pomiarową pokazującą, jak zapytanie zachowywało się w czasie, dlatego najlepiej wykorzystywać je do ustalenia trendu, wskazania zapytań wymagających dalszej analizy i weryfikacji skutków zmian konfiguracji lub planu. |