Query Store w Azure SQL

Query Store w Azure SQL jest domyślnie włączony i stanowi podstawę wielu wbudowanych mechanizmów optymalizacji.

Rola Query Store w Azure SQL

Query Store w Azure SQL jest mechanizmem zapisującym historię wykonywania zapytań w obrębie konkretnej bazy danych. Gromadzi między innymi tekst zapytania, identyfikator zapytania, informacje o planach wykonania oraz zagregowane statystyki czasu działania. Dane są przechowywane trwale w bazie, dlatego można analizować zachowanie zapytań także po wyczyszczeniu pamięci planów lub ponownym uruchomieniu usługi. Od pamięci podręcznej planów różni się więc tym, że nie służy wyłącznie do bieżącego wykonania, lecz do porównywania historii.

W Azure SQL Query Store jest domyślnie włączony, co pozwala korzystać z funkcji monitorowania bez ręcznego uruchamiania podstawowego mechanizmu. Samo włączenie nie oznacza jednak, że każda informacja jest zapisywana bez ograniczeń. Zakres zbierania danych zależy od opcji Query Store, między innymi trybu pracy, interwału agregacji statystyk, limitu miejsca oraz zasad usuwania starszych wpisów. Ustawienia te mają znaczenie przy bazach o dużej liczbie zapytań lub intensywnym ruchu aplikacji.

Jakie dane są rejestrowane

Query Store identyfikuje zapytania na podstawie ich reprezentacji w silniku Azure SQL, a następnie wiąże je z planami wykonania i okresami agregacji. Dla danego przedziału czasu można analizować między innymi liczbę wykonań, całkowity i średni czas trwania, zużycie procesora, odczyty logiczne, zapisy oraz liczbę zwróconych wierszy. Wartości są agregowane, więc Query Store nie jest pełnym dziennikiem każdej pojedynczej sesji ani zamiennikiem śledzenia zdarzeń diagnostycznych.

W zależności od obsługiwanej konfiguracji i wersji usługi mogą być także rejestrowane statystyki oczekiwania. Pozwalają one powiązać opóźnienie zapytania z kategorią oczekiwania, na przykład oczekiwaniem na zasoby procesora, operacje wejścia-wyjścia albo blokadę. Przy interpretacji trzeba odróżnić czas wykonania od czasu oczekiwania oraz sprawdzić, czy problem dotyczy jednego zapytania, konkretnego planu, czy większej części obciążenia bazy.

Regresja planu i wymuszanie stabilnego wykonania

Jednym z głównych zastosowań Query Store jest wykrywanie regresji planu. Regresja występuje wtedy, gdy to samo zapytanie po zmianie statystyk, danych, indeksów, konfiguracji lub procesu kompilacji zaczyna korzystać z planu zapewniającego gorsze parametry. Porównanie statystyk z kilku przedziałów czasu może ujawnić, że wzrosły czas trwania, liczba odczytów lub zużycie procesora, mimo że tekst zapytania się nie zmienił.

Jeżeli wcześniejszy plan był właściwy, uprawniony administrator Azure SQL może użyć Query Store do jego wymuszenia. Wymuszenie planu ogranicza wybór optymalizatora dla wskazanego zapytania, ale nie usuwa przyczyny problemu i nie gwarantuje poprawności po zmianie schematu lub danych. Operację należy kontrolować, ponieważ plan dobry dla jednego rozkładu danych może później stać się niekorzystny. Query Store umożliwia także sprawdzenie, czy wymuszenie zostało zastosowane oraz czy wykonania nadal kończą się zgodnie z oczekiwaniami.

Query Store w analizie problemu z bazą

Analizę warto rozpocząć od wyznaczenia okresu, w którym pojawiło się spowolnienie, a następnie porównać zapytania według czasu trwania, liczby wykonań, zużycia procesora i operacji wejścia-wyjścia. Następnie należy sprawdzić, czy zmienił się plan wykonania, czy zmieniły się statystyki oczekiwania oraz czy wpis nie został ograniczony przez retencję albo limit miejsca. Sam wysoki czas całkowity nie musi oznaczać wadliwego zapytania, jeżeli wynika z bardzo dużej liczby prawidłowych wykonań.

Query Store wspiera również automatyczne mechanizmy dostrajania Azure SQL, które mogą wykrywać regresje i proponować albo stosować działania korygujące zgodnie z konfiguracją usługi. Wyniki takich mechanizmów należy weryfikować w kontekście aplikacji, schematu oraz aktualnych danych. Przy problemie z komputerem użytkownika Query Store nie wskaże awarii pamięci RAM, dysku ani systemu operacyjnego, ponieważ opisuje zachowanie zapytań po stronie konkretnej bazy Azure SQL. Do diagnostyki potrzebne są więc dane z właściwego środowiska, dostęp do odpowiednich statystyk oraz możliwość porównania planów wykonania.