Kompatybilność planów zapytań

Kompatybilność planów zapytań dotyczy tego, czy zapamiętane plany pozostają ważne po zmianie wersji lub poziomu zgodności.

Jak zmiana poziomu zgodności wpływa na zapisany plan

Kompatybilność planów zapytań w SQL Server opisuje zależność między planem wykonania przechowywanym w pamięci podręcznej a wersją silnika oraz poziomem zgodności bazy danych. Plan wykonania nie jest wyłącznie zapisem tekstu zapytania. Zawiera między innymi wybrane operatory, kolejność dostępu do tabel, sposób użycia indeksów, rodzaj złączeń oraz szacowane liczności wierszy. Optymalizator wybiera te elementy na podstawie metadanych, statystyk, ustawień bazy i reguł właściwych dla danego poziomu zgodności.

Po aktualizacji SQL Server istnieje możliwość uruchamiania bazy na starszym poziomie zgodności, dlatego zachowanie optymalizatora nie musi od razu odpowiadać zachowaniu nowej wersji silnika. Zmiana wartości poziomu zgodności może włączyć nowe reguły optymalizacji, zmienić sposób szacowania kardynalności albo zmodyfikować interpretację określonych konstrukcji języka T-SQL. Z tego powodu plan zapisany przed zmianą nie powinien być traktowany jako bezwarunkowo poprawny wzorzec dla późniejszego środowiska.

Plan w pamięci podręcznej a ponowna kompilacja

SQL Server przechowuje skompilowane plany w plan cache i może użyć ich ponownie, gdy kolejne wykonanie odpowiada warunkom zapisanym dla danego planu. Ponowne wykorzystanie ogranicza koszt kompilacji, ale nie oznacza, że raz wybrany plan będzie optymalny przez cały czas. Plan może zostać usunięty z pamięci podręcznej między innymi wskutek presji pamięci, restartu usługi, zmian w schemacie, aktualizacji statystyk lub jawnego opróżnienia pamięci podręcznej.

Przy zmianie poziomu zgodności należy zweryfikować, czy istniejące zapytania zostały ponownie skompilowane w warunkach obowiązujących po zmianie. Sam fakt ustawienia nowej wartości nie dowodzi, że wszystkie obserwowane wykonania korzystają już z planów wyznaczonych według nowych reguł. W praktyce analizuje się rzeczywisty plan wykonania, czas kompilacji, liczbę użyć planu oraz różnice między estymowanymi a rzeczywistymi licznościami wierszy. Pomocne są widoki dynamiczne, takie jak sys.dm_exec_query_stats, sys.dm_exec_cached_plans i sys.dm_exec_sql_text, używane do powiązania statystyk z tekstem zapytania i uchwytem planu.

Objawy niezgodności i kontrola regresji

Problem z kompatybilnością może ujawnić się jako regresja wydajności po aktualizacji instancji albo po podniesieniu poziomu zgodności bazy. Typowym sygnałem jest wybór innego operatora złączenia, na przykład złączenia zagnieżdżonego zamiast złączenia haszującego, albo zmiana sposobu dostępu z wyszukiwania indeksowego na skan. Nie musi to oznaczać błędu silnika. Nowy plan może być korzystniejszy dla jednego rozkładu danych, lecz gorszy dla innego, zwłaszcza gdy statystyki są nieaktualne albo zapytanie jest wrażliwe na wartości parametrów.

Rzetelne porównanie powinno obejmować ten sam tekst zapytania, te same parametry, porównywalny stan danych oraz pomiar przed i po zmianie. Należy sprawdzić rzeczywisty plan wykonania, zużycie procesora, czas trwania, liczbę odczytanych stron i ostrzeżenia operatorów. Ważne jest także rozróżnienie planu szacowanego od rzeczywistego: plan szacowany pokazuje przewidywania optymalizatora, natomiast rzeczywisty zawiera dane z konkretnego wykonania. Jeżeli problem dotyczy pojedynczego zapytania, można przeanalizować Query Store, który przechowuje historię zapytań, planów i statystyk wykonania, a następnie ocenić, czy regresja pojawiła się dokładnie po zmianie poziomu zgodności.

Bezpieczne postępowanie przed utrwaleniem nowego ustawienia

Zmiana poziomu zgodności powinna być poprzedzona inwentaryzacją zapytań o największym wpływie na obciążenie oraz sprawdzeniem planów, które wcześniej działały stabilnie. Najpierw warto zabezpieczyć dane porównawcze z Query Store i z pomiarów wykonania, a następnie przeprowadzić zmianę w środowisku testowym. Po zmianie należy obserwować nowe kompilacje, odchylenia czasu wykonania i różnice w planach. Szczególnej uwagi wymagają zapytania z parametrami, rozbudowanymi predykatami, funkcjami tabelarycznymi oraz operacjami na dużych zbiorach, ponieważ niewielka zmiana estymacji może wpłynąć na cały plan.

Jeżeli nowy plan powoduje regresję, rozwiązaniem nie jest automatyczne usuwanie wszystkich planów z pamięci. Trzeba ustalić, czy przyczyną są statystyki, parametry, zmiana schematu, ustawienia sesji czy reguły optymalizatora związane z poziomem zgodności. W zależności od ustaleń można rozważyć aktualizację statystyk, korektę zapytania, wymuszenie wcześniej sprawdzonego planu w Query Store albo czasowe pozostawienie niższego poziomu zgodności do zakończenia testów. Każda z tych decyzji powinna być oparta na pomiarze, ponieważ wymuszony plan także może przestać pasować do późniejszego rozkładu danych.

Przy problemach z działaniem laptopa lub komputera PC, na którym używane są narzędzia bazodanowe albo aplikacje korzystające z SQL Server, Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów stacjonarnych i ich podzespołów.