Monitorowanie planu zapytania

Monitorowanie planu zapytania to śledzenie, czy optymalizator nie zmienił sposobu jego wykonania na mniej efektywny.

Na czym polega obserwacja planu zapytania

Monitorowanie planu zapytania oznacza sprawdzanie, w jaki sposób silnik bazy danych realizuje konkretne zapytanie oraz czy ten sposób wykonania pozostaje korzystny po zmianach danych, indeksów, statystyk, konfiguracji i samego zapytania. Plan opisuje między innymi kolejność operacji, sposób odczytu tabel, użycie indeksów, warunki filtrowania, metody łączenia danych oraz operacje sortowania lub agregowania. Ten sam tekst zapytania może być wykonywany według różnych planów, ponieważ optymalizator wybiera wariant na podstawie dostępnych informacji o danych i szacowanego kosztu poszczególnych operacji.

Nie wystarczy zanotować, że zapytanie zwróciło poprawny wynik. Plan może prowadzić do pełnego skanowania dużej tabeli, wielokrotnego odczytu tych samych danych, kosztownego sortowania albo przekazywania znacznie większej liczby wierszy między operatorami, niż ostatecznie wykorzystuje zapytanie. Monitorowanie polega więc na porównywaniu planu z rzeczywistym zachowaniem: czasem wykonania, liczbą odczytów, zużyciem procesora, pamięcią oraz liczbą wierszy przetwarzanych przez poszczególne etapy.

Dlaczego optymalizator może wybrać gorszy wariant

Zmiana planu nie zawsze oznacza błąd. Jeżeli tabela powiększyła się albo rozkład wartości w kolumnie uległ zmianie, wcześniejszy indeks może przestać być opłacalny dla określonego zakresu wyszukiwania. Dla niewielkiej liczby pasujących wierszy korzystny może być odczyt indeksu i pobranie danych z tabeli, natomiast dla dużego zakresu wyników szybszy może okazać się odczyt sekwencyjny. Optymalizator próbuje wybrać plan odpowiedni dla przewidywanej selektywności, czyli udziału wierszy spełniających warunek.

Jednym z ważnych źródeł rozbieżności są nieaktualne lub niedokładne statystyki. Jeżeli oszacowana liczba wierszy znacząco różni się od liczby rzeczywiście przetworzonych, kolejne operatory mogą otrzymać niewłaściwy plan. Taka sytuacja bywa widoczna przy nierównomiernym rozkładzie wartości, silnej korelacji kolumn, nowych danych dopisanych po ostatniej aktualizacji statystyk albo parametrach, dla których jeden plan nie pasuje do wszystkich przypadków. W monitoringu należy odróżnić zwykłą zmianę planu od regresji, czyli sytuacji, w której nowe wykonanie systematycznie zużywa więcej zasobów lub trwa dłużej.

Jak porównywać plan z rzeczywistym wykonaniem

Analiza powinna zaczynać się od jednoznacznej identyfikacji zapytania. Przydatne są tekst zapytania, jego parametry, czas wykonania, kontekst aplikacji oraz identyfikator lub skrót planu, jeżeli dany silnik takie informacje udostępnia. Następnie porównuje się plan uznany za prawidłowy z planem aktualnym. Warto sprawdzić, czy zmienił się typ dostępu do danych, kolejność złączeń, algorytm łączenia, kolejność sortowania, sposób realizacji agregacji albo miejsce zastosowania predykatu filtrującego.

Szczególnie istotna jest różnica między wartościami szacowanymi a rzeczywistymi. Jeżeli operator miał przetworzyć kilka wierszy, a w praktyce przetworzył ich bardzo dużo, wybór kolejnego operatora mógł zostać oparty na błędnym założeniu. Należy także obserwować operacje oczekujące na pamięć, nadmiarowe odczyty, powtarzane wywołania oraz przekazywanie danych pomiędzy etapami. Sam koszt procentowy pokazany na diagramie nie jest uniwersalną miarą problemu, ponieważ jest wyliczany w odniesieniu do konkretnego planu. Wiarygodniejszy obraz daje zestawienie czasu, odczytów i obciążenia dla wielu podobnych wykonań.

Monitoring powinien uwzględniać historię, a nie tylko pojedynczy przypadek. Rejestrowanie planów wraz z metrykami pozwala wykryć moment regresji i powiązać go ze zmianą indeksu, aktualizacją aplikacji, wzrostem tabeli lub innym zdarzeniem. Przydatne jest grupowanie wykonań według znormalizowanej postaci zapytania, ponieważ identyczna instrukcja z różnymi wartościami parametrów może być raportowana jako wiele osobnych wpisów. Trzeba również zachować ostrożność przy automatycznym wymuszaniu wcześniejszego planu: rozwiązanie doraźne może ograniczyć regresję, ale po zmianie danych lub schematu stać się kolejnym ograniczeniem.

Wnioski z monitorowania w praktyce serwisowej

Zmiana planu zapytania jest sygnałem do sprawdzenia całego łańcucha zależności: danych, statystyk, indeksów, parametrów, kodu aplikacji i obciążenia systemu. Prawidłowa diagnoza nie powinna opierać się wyłącznie na nazwie operatora ani na pojedynczym pomiarze. Należy ustalić, czy problem występuje stale, tylko dla wybranych parametrów, po określonej zmianie środowiska, czy też wynika z chwilowego przeciążenia. Dopiero wtedy można zdecydować, czy potrzebna jest korekta zapytania, przebudowa indeksu, odświeżenie statystyk, zmiana parametrów monitorowania albo dalsza analiza konfiguracji.

W przypadku komputera używanego do pracy z aplikacją bazodanową przydatne jest rozdzielenie problemu bazy danych od problemu lokalnego stanowiska. Opóźnienie może powstawać w aplikacji, podczas komunikacji sieciowej, przy zapisie plików tymczasowych, przez brak pamięci operacyjnej albo wskutek przeciążenia procesora i nośnika danych. Warszawskie Pogotowie Komputerowe wykonuje profesjonalną naprawę laptopów, komputerów PC i ich podzespołów, gdy analiza objawów wskazuje na lokalny problem sprzętowy lub systemowy. Sam plan zapytania pozostaje jednak artefaktem silnika bazy danych i powinien być interpretowany razem z jego dokumentacją oraz pomiarami z rzeczywistego środowiska.