Kompatybilność silnika bazy danych

Kompatybilność silnika bazy danych określa, które funkcje działają w zależności od wersji rdzenia SQL Server.

Rola wersji silnika i poziomu zgodności bazy

Kompatybilność silnika bazy danych w SQL Server opisuje zależność między wersją zainstalowanego aparatu bazodanowego a poziomem zgodności ustawionym dla konkretnej bazy. Wersja silnika wynika z wydania SQL Server uruchomionego na komputerze, natomiast poziom zgodności jest właściwością bazy danych. Nie są to dwa określenia tego samego parametru. Baza utworzona w starszej wersji SQL Server może zostać przeniesiona na nowszy silnik i nadal działać z wcześniejszym poziomem zgodności.

Poziom zgodności wpływa przede wszystkim na sposób interpretowania części składni języka Transact-SQL oraz na zachowanie optymalizatora zapytań. Przykładowe poziomy używane w kolejnych wydaniach to 100 dla SQL Server 2008, 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 i 160 dla SQL Server 2022. Wartość nie oznacza bezpośrednio numeru wersji wszystkich komponentów serwera, lecz określa zestaw reguł kompatybilności stosowanych przez daną bazę.

Jak SQL Server interpretuje poziom compatibility level

Poziom zgodności może zachować starsze zachowanie aplikacji po migracji bazy na nowszy silnik. Ma to znaczenie, gdy zapytania zależą od dawnej interpretacji składni, zmian w funkcjach albo od sposobu generowania planów wykonania. Jednocześnie ustawienie starszego poziomu nie cofa całego silnika do wcześniejszej wersji. Nowszy SQL Server nadal udostępnia własne mechanizmy administracyjne, format plików i funkcje systemowe, ale zapytania wykonywane w konkretnej bazie mogą podlegać regułom związanym z jej poziomem zgodności.

Zmiana poziomu zgodności może wpłynąć na wydajność, ponieważ nowsze poziomy mogą aktywować zmienione reguły optymalizatora zapytań. To nie oznacza automatycznej poprawy każdego zapytania. Ten sam kod może otrzymać inny plan wykonania, korzystać z innych indeksów albo zmienić kolejność operacji łączenia tabel. Dlatego po zmianie należy sprawdzić rzeczywiste zapytania aplikacji, czasy wykonania, blokady i obciążenie procesora, zamiast oceniać zgodność wyłącznie na podstawie pomyślnego uruchomienia usługi.

Sprawdzanie zgodności przed migracją bazy

Podstawową informację można odczytać z widoku katalogowego sys.databases. Zapytanie SELECT name, compatibility_level FROM sys.databases; pokazuje nazwy baz oraz przypisane im poziomy zgodności. Przed zmianą trzeba ustalić również wersję uruchomionego silnika, na przykład przez SELECT SERVERPROPERTY('ProductVersion'), SERVERPROPERTY('ProductMajorVersion');. Zestawienie tych danych pozwala sprawdzić, czy planowany poziom jest obsługiwany przez zainstalowane wydanie SQL Server.

Analiza zgodności powinna obejmować schemat bazy, procedury składowane, funkcje, widoki, wyzwalacze oraz zapytania generowane przez aplikację. Samo sprawdzenie, czy baza daje się przywrócić z kopii, nie potwierdza pełnej zgodności logicznej. Należy zweryfikować funkcje niedostępne w starszym silniku, zmienione zachowanie składni, zależności od ustawień sortowania oraz zapytania wykorzystujące niejawne konwersje typów. Przy migracji warto zachować kopię zapasową i wykonać testy na odtworzonej bazie, aby rozdzielić problemy wynikające z wersji silnika od problemów w danych lub konfiguracji aplikacji.

Zmiana ustawienia i ocena skutków

Poziom zgodności ustawia się dla konkretnej bazy poleceniem w rodzaju ALTER DATABASE [NazwaBazy] SET COMPATIBILITY_LEVEL = 150;, przy czym wartość musi odpowiadać poziomowi obsługiwanemu przez używany silnik SQL Server. Zmiana nie powinna być wykonywana bez wcześniejszego przeglądu procedur i testów. Najpierw należy zapisać aktualną wartość, ustalić plan powrotu oraz sprawdzić, czy aplikacja korzysta z funkcji zależnych od poprzednich reguł interpretacji.

Po zmianie trzeba porównać wykonanie najważniejszych operacji: wyszukiwania, raportów, zapisów transakcyjnych i zapytań korzystających z dużych tabel. Pomocne są rzeczywiste plany wykonania, statystyki wejścia-wyjścia oraz czas trwania zapytań. Jeżeli wystąpi regresja, można przeanalizować plan, statystyki i indeksy, a następnie zdecydować, czy problem wymaga modyfikacji zapytania, aktualizacji statystyk, korekty indeksu albo czasowego pozostawienia wcześniejszego poziomu zgodności.