Forced Plan Invalidation

Forced Plan Invalidation to unieważnienie wcześniej wymuszonego planu wykonania, np. w wyniku zmiany struktury tabeli.

Na czym polega unieważnienie wymuszonego planu w SQL Server

Forced Plan Invalidation oznacza sytuację, w której plan wykonania zapisany w Query Store i wcześniej wymuszony dla określonego zapytania przestaje być możliwy do zastosowania albo traci zgodność z aktualnym stanem obiektów bazy danych. W SQL Server wymuszenie planu ma za zadanie nakazać optymalizatorowi korzystanie z wybranego planu zamiast swobodnego wyboru innego wariantu. Nie jest to jednak obietnica, że plan pozostanie użyteczny niezależnie od zmian w schemacie, indeksach, typach danych czy dostępności obiektów.

Unieważnienie wymuszonego planu nie jest tym samym co zwykłe usunięcie planu z pamięci podręcznej. SQL Server może ponownie skompilować zapytanie, ponieważ zmieniły się statystyki albo zależności schematu, a jednocześnie nadal próbować zastosować plan wymuszony zapisany w Query Store. Do invalidacji dochodzi wtedy, gdy ten konkretny plan nie może zostać poprawnie odtworzony lub wykonany w aktualnym środowisku. W takiej sytuacji system może zgłosić niepowodzenie wymuszenia i dopuścić wybór innego planu przez optymalizator.

Zmiany schematu, indeksów i zależności zapytania

Typowym powodem unieważnienia jest zmiana struktury tabeli, do której odwołuje się zapytanie. Znaczenie mogą mieć między innymi usunięcie kolumny używanej w predykacie, zmianę typu danych, zmianę klucza indeksu albo usunięcie indeksu, którego istnienie było istotne dla wybranego planu. Jeżeli plan zawiera operator wykorzystujący obiekt, który nie istnieje lub nie pasuje już do definicji zapytania, SQL Server nie może bezwarunkowo zastosować starego planu.

Wpływ mogą mieć także zmiany widoków, funkcji, procedur składowanych i innych obiektów zależnych. Wymuszony plan jest związany z konkretnym zapytaniem oraz jego identyfikacją w Query Store, ale sam plan odzwierciedla określony układ tabel, indeksów, typów i relacji dostępnych podczas kompilacji. Zmiana schematu może więc spowodować, że plan pozostanie zapisany w historii, lecz nie będzie już prawidłowym opisem możliwego wykonania. Sam fakt obecności planu w Query Store nie oznacza, że plan nadal jest wykonalny.

Jak rozpoznać nieudane wymuszenie planu

Analizę należy rozpocząć od ustalenia, czy zapytanie rzeczywiście ma wymuszony plan. W Query Store można sprawdzić właściwość is_forced_plan w widoku sys.query_store_plan, a następnie powiązać ją z identyfikatorem zapytania i tekstem zapytania. Istotne są również informacje o liczbie nieudanych prób wymuszenia, takie jak force_failure_count, oraz opis ostatniej przyczyny błędu dostępny w polach dotyczących ostatniego niepowodzenia wymuszenia. Taki odczyt pozwala odróżnić problem z wymuszaniem od ogólnego wzrostu czasu wykonania.

Warto porównać plan wymuszony z planem aktualnie używanym i sprawdzić ostatnie zmiany schematu, indeksów oraz statystyk. Należy również przeanalizować, czy zapytanie nie zostało zmienione w sposób powodujący powstanie innego identyfikatora zapytania. W SQL Server nawet pozornie niewielka modyfikacja tekstu, kontekstu lub parametrów może wpłynąć na sposób zapisania zapytania w Query Store. Jeżeli wymuszenie przestało działać po zmianie tabeli, nie należy od razu ponownie wymuszać starego planu. Najpierw trzeba potwierdzić, że wszystkie obiekty i zależności wymagane przez ten plan nadal istnieją.

Postępowanie po invalidacji wymuszonego planu

Naprawa polega na ustaleniu aktualnego, poprawnego planu dla konkretnego zapytania, a nie na mechanicznym przywracaniu historycznej wersji. Gdy zmiana schematu była zamierzona, poprzedni plan może być już nieaktualny. W takim przypadku należy ocenić plan wybrany przez optymalizator, sprawdzić aktualne statystyki i zweryfikować, czy zapytanie korzysta z właściwych indeksów. Jeśli dostępny jest poprawny plan zapisany w Query Store, można rozważyć jego wymuszenie za pomocą procedur Query Store przeznaczonych do zarządzania planami, takich jak sp_query_store_force_plan. Przed taką operacją trzeba potwierdzić zgodność planu z obecnym schematem.

W przypadku utrzymujących się błędów konieczne jest sprawdzenie definicji obiektów, planów wykonania, parametrów zapytania i komunikatów SQL Server. Czasem właściwym rozwiązaniem jest usunięcie wymuszenia procedurą sp_query_store_unforce_plan, aby optymalizator mógł wybrać plan zgodny z bieżącymi warunkami. Diagnostyka powinna obejmować także wpływ zmian na komputerze klienckim, jeśli objawem jest zawieszanie programu, długi czas oczekiwania albo błędy połączenia z bazą. Przy pracy na laptopie lub komputerze PC należy oddzielić problem lokalnego oprogramowania od problemu planu wykonywanego po stronie SQL Server, ponieważ sama naprawa systemu klienta nie unieważni ani nie naprawi niezgodnego wymuszenia planu.