Plan Id

Plan Id to identyfikator planu wykonania w Query Store, wykorzystywany przy jego wymuszaniu.

Plan Id w Query Store – czym jest identyfikator planu wykonania

Plan Id to numer przypisany konkretnej postaci planu wykonania zapytania zapisanej w Query Store. Warto rozdzielić pojęcie planu od samego zapytania. Jedno zapytanie może mieć ten sam tekst, podobne parametry i ten sam identyfikator zapytania, a mimo to być wykonywane według kilku różnych planów. Każdy z takich planów otrzymuje własny Plan Id, dzięki czemu można wskazać dokładnie tę wersję planu, która ma zostać przeanalizowana albo wykorzystana podczas wymuszania.

Query Store przechowuje informacje o zapytaniach, planach oraz statystykach ich wykonywania. Plan Id nie jest opisem jakości planu i sam w sobie nie oznacza, że plan jest dobry lub zły. Jest technicznym identyfikatorem rekordu dotyczącego planu. Dopiero po połączeniu go z czasem wykonania, zużyciem procesora, liczbą odczytów, liczbą wykonań i innymi statystykami można ocenić zachowanie zapytania. Identyfikator jest szczególnie przydatny wtedy, gdy dla jednego zapytania występuje kilka konkurujących planów i trzeba odróżnić je bez opierania się wyłącznie na obrazie graficznym.

Plan Id należy traktować jako wartość nadawaną w ramach metadanych Query Store, a nie jako stałą cechę zapytania przenoszoną między wszystkimi bazami. Po zmianach środowiska, odtworzeniu bazy, czyszczeniu danych Query Store albo ponownym skompilowaniu zapytania mogą pojawić się inne rekordy. Z tego powodu przy dokumentowaniu problemu warto zapisywać jednocześnie identyfikator zapytania, Plan Id, czas obserwacji oraz wersję środowiska.

Plan Id a stabilność zapytań i różne warianty planu

Wybór planu wykonania zależy między innymi od statystyk, dostępnych indeksów, rozkładu danych, predykatów, parametrów oraz szacowanej liczby wierszy. Gdy optymalizator uzna, że inny sposób realizacji zapytania będzie korzystniejszy, może utworzyć kolejny plan. Jeden wariant może wykorzystywać wyszukiwanie po indeksie i niewielką liczbę operacji, a drugi może korzystać z odczytu większego zakresu danych oraz innego sposobu łączenia tabel. Oba warianty mogą być poprawne logicznie, lecz ich koszt praktyczny może zmieniać się zależnie od parametrów.

Właśnie dlatego Plan Id jest ważniejszy niż ogólne stwierdzenie, że zapytanie działa wolno. Bez wskazania konkretnego planu trudno ustalić, czy problem powstał po zmianie indeksu, aktualizacji statystyk, zmianie danych, zmianie parametrów czy ponownej kompilacji. Porównanie kilku identyfikatorów pozwala sprawdzić, czy pogorszenie czasu wykonania wiąże się z przejściem na inną wersję planu. Należy jednak pamiętać, że sam fakt istnienia nowego Planu Id nie dowodzi awarii. Nowy plan może być korzystniejszy dla jednych parametrów, a mniej korzystny dla innych.

Podczas analizy porównuje się nie tylko numer, lecz także operatorzy planu, szacunki liczby wierszy, rzeczywistą liczbę wierszy, rodzaj dostępu do tabel i indeksów, kolejność operacji oraz poziom równoległości. Istotne jest także sprawdzenie, w jakim przedziale czasu rejestrowano statystyki. Plan, który wygląda na cięższy, może być uzasadniony przy dużym zbiorze wyników, natomiast plan pozornie prosty może nie sprawdzać się przy selektywnych lub nietypowych wartościach parametrów.

Plan Id przy wymuszaniu planu wykonania

Wymuszenie planu polega na przekazaniu silnikowi informacji, aby dla określonego zapytania korzystał z wybranego wariantu zarejestrowanego w Query Store. W takim działaniu Plan Id pełni rolę jednoznacznego wskazania planu, który ma zostać użyty. Nie wymusza się więc „najlepszego planu” w oderwaniu od danych, lecz konkretną wersję planu wcześniej zaobserwowaną i zapisaną.

Przed wymuszeniem należy ustalić, dlaczego wybrano dany Plan Id. Uzasadnieniem może być stabilny czas wykonania w reprezentatywnych warunkach, mniejsze zużycie zasobów albo wyraźne pogorszenie po przełączeniu na inny plan. Warto zweryfikować, czy wybrany wariant działa poprawnie dla typowych wartości parametrów, czy nie korzysta z nieaktualnego indeksu i czy nie maskuje głębszego problemu ze statystykami lub strukturą zapytania.

Wymuszenie powinno być traktowane jako decyzja wymagająca kontroli po wdrożeniu. Po jego zastosowaniu obserwuje się czas trwania, zużycie procesora, liczbę odczytów, opóźnienia oraz wpływ na inne zadania wykonywane w tej samej bazie. Jeżeli dane zmienią się znacząco, pierwotnie korzystny Plan Id może przestać być odpowiedni. Wtedy należy ponownie ocenić dostępne plany, sprawdzić aktualność statystyk i rozważyć usunięcie wymuszenia zamiast pozostawiać je bezterminowo.

Plan Id i typowe problemy diagnostyczne

Jednym z częstych problemów jest pomylenie identyfikatora zapytania z identyfikatorem planu. Query Id odnosi się do rozpoznanego zapytania, natomiast Plan Id wskazuje jedną z jego wersji wykonania. Sam Query Id nie wystarcza, gdy trzeba porównać dwa sposoby realizacji. Innym problemem jest analizowanie numeru bez zakresu czasu. Ten sam zapis może wyglądać inaczej przed i po zmianie danych, aktualizacji statystyk albo zmianie konfiguracji.

Trudności mogą wynikać także z niepełnych danych w Query Store. Jeżeli przechowywanie statystyk zostało ograniczone, dane były czyszczone albo zapytanie wykonywało się poza okresem rejestracji, nie wszystkie warianty muszą być dostępne do porównania. Należy również zwrócić uwagę na status planu, czas jego pierwszego i ostatniego użycia oraz liczbę obserwacji. Plan Id obecny w katalogu nie musi oznaczać planu aktualnie używanego.

W praktyce nie powinno się naprawiać problemu wyłącznie przez mechaniczne wymuszenie pierwszego planu o niskim średnim czasie. Średnia może ukrywać duże różnice między pojedynczymi wykonaniami. Przydatne jest zestawienie mediany, wartości skrajnych, liczby wykonań i zużycia zasobów. Pozwala to odróżnić sporadyczne opóźnienie od trwałej regresji. Warto także sprawdzić, czy problem nie wynika z blokad, przeciążenia pamięci, opóźnień dyskowych lub zmian w aplikacji, ponieważ Plan Id opisuje plan, ale nie wyjaśnia wszystkich przyczyn wolnego działania.

Plan Id – praktyczne wskazówki przed zgłoszeniem problemu

Przed rozpoczęciem analizy dobrze przygotować przykładowe zapytanie, identyfikator bazy, Query Id, obserwowany Plan Id oraz przybliżony czas wystąpienia problemu. Pomocne jest zapisanie informacji, czy spowolnienie dotyczy każdego wykonania, czy tylko określonych parametrów. Należy również odnotować ostatnie zmiany: modyfikację indeksów, aktualizację statystyk, wdrożenie nowej wersji aplikacji, import danych albo zmianę konfiguracji.

Nie powinno się zmieniać planów bez śladu. Przed wymuszeniem warto zachować plan dotychczasowy, zanotować powód decyzji i określić kryteria wycofania. Dzięki temu można porównać efekt przed i po zmianie oraz wrócić do poprzedniego stanu, jeżeli poprawa okaże się pozorna. Przydatne jest także sprawdzenie, czy Query Store działa w sposób zapewniający zapis nowych planów i statystyk, ponieważ brak danych może prowadzić do błędnych wniosków.

Jeżeli analiza dotyczy środowiska używanego na co dzień, zaleca się ograniczenie zmian do jasno określonego zakresu i wykonanie kontroli po wdrożeniu. Przy problemach z bazą danych, konfiguracją Query Store albo interpretacją planu można skorzystać z pomocy serwisu komputerowego w Warszawie; naprawy z reguły realizowane są do 3 dni roboczych. Przekazanie przygotowanych informacji o Query Id i Plan Id ułatwia odtworzenie problemu oraz ogranicza ryzyko przypadkowej zmiany niezwiązanej z rzeczywistą przyczyną.