Kompatybilność optymalizatora zapytań

Kompatybilność optymalizatora zapytań określa, według reguł której wersji silnika budowany jest plan wykonania.

Jak kompatybilność wpływa na plan wykonania zapytania

Kompatybilność optymalizatora zapytań określa, z jakiego zestawu reguł korzysta silnik podczas analizowania instrukcji SQL i wyboru sposobu dostępu do danych. W Microsoft SQL Server ustawienie poziomu kompatybilności bazy danych pozwala zachować określone zachowanie optymalizatora po zmianie wersji silnika. Baza może działać na nowszym serwerze, ale jej zapytania nadal mogą być optymalizowane według reguł przypisanych do wcześniejszego poziomu zgodności.

Optymalizator ocenia między innymi dostępne indeksy, kolejność łączenia tabel, rodzaj złączeń, sposób filtrowania danych oraz przewidywaną liczbę wierszy zwracanych przez poszczególne operatory. Wynikiem jest plan wykonania, czyli uporządkowany opis operacji, które silnik wykona podczas realizacji zapytania. Zmiana kompatybilności nie zmienia samego tekstu instrukcji SQL, ale może spowodować wybór innego planu.

Poziom zgodności bazy a wersja silnika SQL Server

W SQL Server poziom kompatybilności jest właściwością bazy danych, a nie pojedynczej tabeli ani pojedynczego zapytania. Jego wartość jest powiązana z określoną generacją zachowania silnika. Po przywróceniu lub podłączeniu starszej bazy do nowszej instancji SQL Server jej poziom zgodności może pozostać niższy, aby ograniczyć automatyczne zmiany w optymalizacji i semantyce niektórych funkcji.

Weryfikacja poziomu może być wykonana przez odczyt właściwości bazy w widoku katalogowym sys.databases. Przykładowe zapytanie diagnostyczne ma postać SELECT name, compatibility_level FROM sys.databases;. Ustawienie wartości wymaga polecenia ALTER DATABASE, jednak taka zmiana powinna być poprzedzona analizą planów i testami. Sama obecność nowszej wersji serwera nie jest wystarczającym powodem do natychmiastowego podniesienia poziomu zgodności.

Dlaczego ten sam SQL może otrzymać inny plan

Po zmianie poziomu kompatybilności optymalizator może zastosować nowsze mechanizmy szacowania kardynalności, transformacji zapytań albo wyboru operatorów. Szacowanie kardynalności to przewidywanie liczby wierszy przekazywanych między etapami planu. Jeżeli przewidywanie będzie inne, SQL Server może wybrać na przykład skan zamiast wyszukiwania po indeksie, inną kolejność złączeń albo inny typ operatora łączenia.

Różnica nie musi oznaczać błędu w składni. Zapytanie może nadal zwracać poprawne dane, lecz wykonywać się wolniej albo zużywać więcej pamięci i czasu procesora. Szczególnie istotne są instrukcje pracujące na dużych tabelach, zapytania z wieloma złączeniami, filtry o nierównomiernym rozkładzie wartości oraz procedury składowane zależne od parametrów. Do oceny zmiany należy porównać rzeczywisty plan wykonania, czas trwania, liczbę odczytów logicznych i rzeczywistą liczbę przetworzonych wierszy.

Jeżeli po podniesieniu poziomu zgodności pojawi się regresja, trzeba ustalić, czy przyczyną jest nowy plan, nieaktualne statystyki, zmiana indeksów, inny rozkład danych czy ograniczenie zasobów. Przydatne jest zestawienie planu wcześniejszego z planem bieżącym oraz sprawdzenie ostrzeżeń operatorów. W środowisku testowym warto wykonać te same scenariusze obciążenia przed i po zmianie, ponieważ pojedyncze uruchomienie nie zawsze pokazuje zachowanie typowe dla aplikacji.

Znaczenie kompatybilności podczas serwisowej analizy komputera

Problemy związane z kompatybilnością optymalizatora dotyczą przede wszystkim konfiguracji konkretnego silnika SQL Server i sposobu działania aplikacji korzystającej z bazy. W praktyce diagnostycznej należy rozdzielić błąd połączenia, błąd składni, problem z uprawnieniami oraz regresję wydajności wynikającą z innego planu wykonania. Zmiana poziomu zgodności nie naprawia uszkodzonego dysku, niestabilnej pamięci RAM ani awarii systemu operacyjnego, dlatego objawy sprzętowe powinny być sprawdzane osobno.

Przy pracy na komputerze użytkownika można zweryfikować wersję zainstalowanych składników, stan systemu, dostępność miejsca na dysku oraz logi aplikacji, o ile problem dotyczy lokalnego środowiska uruchomieniowego. Analiza planu i ustawień bazy wymaga jednak dostępu do właściwej instancji SQL Server oraz uprawnień pozwalających odczytać konfigurację, natomiast interpretacja planów optymalizatora powinna być prowadzona w kontekście konkretnej konfiguracji silnika i aplikacji.