Model zgodności zapytań

Model zgodności zapytań to poziom compatibility level bazy, decydujący o zachowaniu optymalizatora i dostępnej składni.

Compatibility level jako ustawienie bazy danych SQL Server

Model zgodności zapytań, określany w SQL Server jako compatibility level, jest właściwością konkretnej bazy danych. Nie opisuje on bezpośrednio wersji zainstalowanego silnika, lecz określa, z jakim zestawem reguł zgodności ma działać parser, optymalizator zapytań i część mechanizmów przetwarzania zapytań. W jednej instancji SQL Server mogą znajdować się bazy ustawione na różnych poziomach zgodności.

Wartość jest przechowywana w katalogu systemowym i można ją odczytać między innymi z widoku sys.databases, korzystając z kolumny compatibility_level. Przykładowe poziomy to 100 dla SQL Server 2008 i 2008 R2, 110 dla SQL Server 2012, 120 dla SQL Server 2014, 130 dla SQL Server 2016, 140 dla SQL Server 2017, 150 dla SQL Server 2019 oraz 160 dla SQL Server 2022. Konkretna możliwość ustawienia zależy od wersji silnika, dlatego baza nie może zostać przełączona na poziom wyższy niż obsługiwany przez daną instalację.

Wpływ poziomu zgodności na składnię i plan wykonania

Zmiana poziomu zgodności może wpływać na sposób interpretowania niektórych konstrukcji języka T-SQL, dostępność określonych zachowań oraz wybór planu wykonania. Szczególne znaczenie ma część optymalizacyjna: nowszy poziom może włączyć nowsze reguły optymalizatora, zmienione modele estymacji liczby wierszy i nowe mechanizmy przetwarzania zapytań. W efekcie to samo zapytanie może otrzymać inny plan po zmianie poziomu, nawet jeśli tekst zapytania i dane nie zostały zmienione.

Poziom zgodności nie jest przełącznikiem zmieniającym format plików danych ani metodą aktualizacji całego silnika. Nie powoduje również automatycznej konwersji aplikacji do nowszej składni. Jego działanie dotyczy przede wszystkim zgodności zachowania bazy z wcześniejszą wersją SQL Server oraz możliwości kontrolowanego włączania zmian wprowadzonych w kolejnych wydaniach. Dlatego migracja bazy na nowszy silnik może początkowo pozostawić jej starszy poziom zgodności, aby ograniczyć ryzyko nagłej zmiany planów zapytań.

W praktyce ten parametr trzeba odróżniać od ustawień takich jak READ_COMMITTED_SNAPSHOT, sortowanie bazy czy poziom izolacji transakcji. Są to odrębne właściwości, które mogą również wpływać na zachowanie aplikacji, ale nie zastępują modelu zgodności zapytań.

Sprawdzanie i kontrolowana zmiana ustawienia

Aktualny poziom można sprawdzić poleceniem SELECT name, compatibility_level FROM sys.databases;. Dla jednej bazy można użyć na przykład zapytania SELECT compatibility_level FROM sys.databases WHERE name = N'BazaDanych';. Takie sprawdzenie powinno poprzedzać analizę problemu, w którym po migracji zmienił się czas wykonania zapytania, pojawił się błąd składni albo aplikacja zaczęła zachowywać się inaczej.

Zmiana odbywa się instrukcją ALTER DATABASE [BazaDanych] SET COMPATIBILITY_LEVEL = 160;, przy czym wartość należy dobrać do wersji silnika i przyjętej strategii migracji. Samo wykonanie instrukcji nie jest dowodem, że aplikacja będzie działała poprawnie. Po zmianie należy sprawdzić zapytania używane przez aplikację, procedury składowane, widoki, funkcje oraz zadania, które korzystają z tej bazy. Szczególną uwagę zwraca się na zapytania o dużym czasie wykonania, operacje złożone na wielu tabelach i fragmenty zależne od estymacji liczby wierszy.

Jeżeli po podniesieniu poziomu pojawi się regresja wydajności, przyczyną może być nowy plan wykonania, a nie uszkodzenie danych. Do rozpoznania problemu porównuje się między innymi plan aktualny z planem wcześniejszym, statystyki, wartości parametrów i czas trwania zapytania. Przydatne są także mechanizmy Query Store, jeśli zostały skonfigurowane w danej bazie, ponieważ pozwalają analizować historię planów i wykonywania zapytań.

Znaczenie parametru podczas diagnostyki bazy

Diagnostyka problemu z zapytaniem powinna rozpocząć się od ustalenia wersji silnika, poziomu zgodności bazy i kontekstu, w którym zapytanie jest wykonywane. Ten sam kod może działać inaczej po przeniesieniu bazy między instancjami, gdy zmieni się wersja SQL Server albo poziom zgodności. Sam komunikat o błędzie nie zawsze wskazuje bezpośrednio na tę właściwość, dlatego należy zestawić go z tekstem zapytania, planem wykonania oraz informacjami o obiektach używanych przez zapytanie.

W przypadku komputera używanego do pracy z bazą istotne jest rozróżnienie problemu silnika od problemu systemu lokalnego. Błąd związany z połączeniem, sterownikiem, uprawnieniami lub konfiguracją aplikacji może wystąpić przed wykonaniem zapytania i wtedy zmiana poziomu zgodności niczego nie naprawi. Jeżeli zapytanie dociera do SQL Server, dopiero analiza planu, komunikatu parsera i ustawień konkretnej bazy pozwala ocenić, czy model zgodności ma związek z usterką.

Przed zmianą ustawienia należy udokumentować wartość początkową, wykonać testy na kopii lub środowisku testowym i zachować możliwość powrotu do poprzedniej konfiguracji. Pozwala to odróżnić skutki zmiany poziomu zgodności od równoczesnych zmian w danych, statystykach, indeksach lub kodzie aplikacji.