Dokumentacja Microsoft dot. zgodności wersji

Dokumentacja Microsoft dotycząca zgodności wersji opisuje, które funkcje są dostępne w poszczególnych wydaniach SQL Server.

Zakres dokumentacji zgodności wersji SQL Server

Dokumentacja Microsoft dotycząca zgodności wersji SQL Server porządkuje zależności między wersją silnika, poziomem zgodności bazy danych oraz dostępnymi funkcjami. Wersja silnika wynika z zainstalowanego wydania produktu, na przykład SQL Server 2016, SQL Server 2019 albo SQL Server 2022. Poziom zgodności jest natomiast właściwością konkretnej bazy danych i określa między innymi zachowanie optymalizatora zapytań oraz wybrane reguły interpretacji języka T-SQL.

Te pojęcia nie są równoważne. Zainstalowanie nowszego SQL Server nie oznacza automatycznie, że każda baza zacznie działać według najnowszych reguł. Po przywróceniu lub podłączeniu bazy utworzonej w starszej wersji poziom zgodności może pozostać niższy, aby ograniczyć ryzyko zmiany wyników zapytań i planów wykonania. Z drugiej strony ustawienie wyższego poziomu zgodności nie dodaje funkcji, których nie zawiera sam silnik albo konkretna edycja produktu.

W dokumentacji należy więc sprawdzać nie tylko nazwę funkcji, lecz także wersję SQL Server, minimalny poziom zgodności, obsługiwane edycje oraz ewentualne ograniczenia dotyczące systemu operacyjnego, konfiguracji instancji i typu obiektu. Taki sposób czytania dokumentacji jest istotny przy planowaniu migracji, aktualizacji aplikacji oraz analizie błędu zgłaszanego po zmianie środowiska bazodanowego.

Wersja silnika a poziom zgodności bazy danych

SQL Server przechowuje poziom zgodności bazy w metadanych. Można go odczytać zapytaniem SELECT name, compatibility_level FROM sys.databases;. W SQL Server 2022 poziom 160 odpowiada bieżącemu poziomowi zgodności tego wydania, natomiast niższe poziomy, takie jak 150, 140, 130, 120, 110 i 100, służą do zachowania określonych zachowań znanych ze starszych wersji. Dostępność konkretnego poziomu zależy od wersji uruchomionego silnika; nie można ustawić poziomu wyższego niż obsługiwany przez daną instancję.

Wersję zainstalowanego produktu można sprawdzić między innymi za pomocą SELECT SERVERPROPERTY('ProductVersion'), SERVERPROPERTY('ProductMajorVersion'), SERVERPROPERTY('Edition');. Informacje te należy analizować razem z poziomem zgodności bazy, ponieważ dwa środowiska mogą mieć ten sam poziom zgodności, ale różnić się poprawkami, edycją lub możliwościami wynikającymi z wersji silnika.

Zmiana poziomu zgodności odbywa się poleceniem ALTER DATABASE [NazwaBazy] SET COMPATIBILITY_LEVEL = 160;, o ile używana instancja obsługuje ten poziom. Operacja wpływa na zachowanie bazy, ale nie jest pełną konwersją wszystkich obiektów ani gwarancją zgodności aplikacji. Przed zmianą trzeba przeanalizować zapytania, procedury składowane, funkcje, widoki i zależności aplikacyjne, a następnie porównać ich wyniki oraz czasy wykonania.

Jak dokumentacja opisuje dostępność funkcji

Przy każdej funkcji SQL Server należy odróżnić dostępność składni od dostępności mechanizmu wykonawczego. Nowa składnia może wymagać określonej wersji silnika, określonego poziomu zgodności albo obu tych warunków. Sam fakt, że parser akceptuje polecenie, nie zawsze oznacza, że wszystkie warianty funkcji są dostępne w każdej edycji lub konfiguracji.

Przykładowo funkcje związane z przetwarzaniem zapytań, optymalizatorem, indeksami, partycjonowaniem, bezpieczeństwem lub typami danych mogą mieć osobne wymagania wersyjne. Dokumentacja może wskazywać minimalne wydanie, obsługiwane poziomy zgodności, ograniczenia edycji oraz zmiany zachowania pomiędzy wersjami. W przypadku migracji nie wystarcza zatem wyszukanie nazwy funkcji. Trzeba sprawdzić stronę opisującą tę funkcję, tabelę zmian breaking changes, informacje o wycofaniu elementów oraz dokumentację aktualizacji z używanej wersji.

Poziom zgodności wpływa szczególnie na optymalizację zapytań i sposób wyboru planu wykonania. Po jego podniesieniu to samo zapytanie może otrzymać inny plan, użyć innego operatora albo zmienić szacowanie liczby wierszy. Nie musi to oznaczać błędu w danych, ale może ujawnić niejawne założenia aplikacji, niejednoznaczne konwersje typów, zależność od kolejności sortowania lub zapytania wrażliwe na zmianę estymacji. Dlatego dokumentacja zgodności powinna być używana razem z testami regresji i analizą planów wykonania.

Praktyczna weryfikacja przed zmianą środowiska

Pierwszym krokiem jest zebranie danych o instancji i bazach: wersji produktu, edycji, poziomie zgodności oraz stanie aktualizacji. Przydatne są widoki sys.databases, właściwość DATABASEPROPERTYEX i funkcja SERVERPROPERTY. Warto również sprawdzić, czy aplikacja korzysta z funkcji dostępnych dopiero w nowszym wydaniu oraz czy nie używa elementów oznaczonych w dokumentacji jako przestarzałe.

Podczas aktualizacji należy wykonać kopię zapasową, przygotować środowisko testowe i porównać reprezentatywne zapytania przed oraz po zmianie poziomu zgodności. Analiza powinna obejmować poprawność wyników, błędy konwersji, procedury składowane, zapytania raportowe i operacje modyfikujące dane. W przypadku problemów można czasowo pozostawić niższy poziom zgodności, ale nie zastępuje to ustalenia przyczyny różnicy ani aktualizacji kodu aplikacji.

Problemy wynikające z niezgodności wersji mogą objawiać się jako błąd składni, brak obiektu, nieobsługiwana funkcja, zmieniony wynik zapytania albo pogorszenie wydajności bez komunikatu o błędzie. Rzetelna diagnostyka wymaga wtedy porównania dokumentacji Microsoft z rzeczywistą wersją instancji, poziomem zgodności bazy, definicją obiektów i planem wykonania. W przypadku typowego laptopa lub komputera PC analiza może obejmować także sprawdzenie instalacji narzędzi klienckich, sterowników oraz konfiguracji aplikacji łączącej się z SQL Server.