Kompatybilność funkcji

Kompatybilność funkcji określa, które elementy programistyczne są dostępne w danej wersji i edycji SQL Server.

Zakres pojęcia kompatybilności funkcji

Kompatybilność funkcji w SQL Server oznacza zgodność konkretnego elementu języka T-SQL, mechanizmu silnika albo obiektu programistycznego z używaną wersją SQL Server, edycją produktu i ustawieniami bazy danych. Funkcją może być zarówno funkcja systemowa, na przykład STRING_AGG, STRING_SPLIT lub TRY_CONVERT, jak i funkcja użytkownika utworzona w bazie. Sam fakt, że składnia jest znana z dokumentacji SQL Server, nie oznacza jeszcze, że będzie dostępna w każdej wcześniejszej wersji.

Podczas oceny zgodności trzeba rozróżnić trzy kwestie: obecność funkcji w danej wersji silnika, wymagany poziom kompatybilności bazy danych oraz ograniczenia wynikające z edycji lub środowiska uruchomieniowego. Wersja silnika określa, jakie możliwości zostały zaimplementowane. Poziom kompatybilności bazy danych, ustawiany właściwością compatibility_level, wpływa między innymi na interpretację części składni, zachowanie optymalizatora zapytań i dostępność niektórych zachowań zgodności. Nie zastępuje on jednak aktualizacji silnika. Ustawienie wyższego poziomu kompatybilności nie doda funkcji, której dany silnik SQL Server w ogóle nie zawiera.

Wersja silnika a poziom kompatybilności bazy

Informacje o wersji można sprawdzić zapytaniem SELECT @@VERSION; albo za pomocą SERVERPROPERTY, na przykład SELECT SERVERPROPERTY('ProductVersion'), SERVERPROPERTY('ProductLevel'), SERVERPROPERTY('Edition');. Poziom kompatybilności konkretnej bazy odczytuje się z widoku katalogowego sys.databases: SELECT name, compatibility_level FROM sys.databases;. Te dane należy analizować razem. Baza przywrócona z wcześniejszego środowiska może zachować niższy poziom kompatybilności po przeniesieniu na nowszą wersję SQL Server.

Niższy poziom kompatybilności bywa używany jako etap przejściowy podczas migracji, ponieważ pozwala ograniczyć zmianę zachowania zapytań po aktualizacji silnika. Nie gwarantuje jednak pełnej zgodności aplikacji. Zapytanie może nadal odwoływać się do funkcji niedostępnej w starej wersji albo korzystać ze składni, której parser nie rozpoznaje. Z drugiej strony podniesienie poziomu kompatybilności może zmienić plan wykonania i ujawnić problemy z niejednoznaczną konwersją typów, kolejnością ewaluacji lub poleganiem na dawnym zachowaniu optymalizatora. Zmianę warto poprzedzić testami zapytań, procedur, widoków, funkcji i wyzwalaczy używanych przez aplikację.

Rozpoznawanie niezgodności w kodzie T-SQL

Typowym objawem braku kompatybilności jest błąd składni zgłaszany podczas tworzenia albo wykonywania obiektu. W takim przypadku trzeba ustalić, czy problem dotyczy parsera, dostępności funkcji, typu danych, uprawnień czy ustawienia bazy. Przykładowo użycie STRING_AGG wymaga środowiska, które obsługuje tę funkcję, natomiast wynik zależy także od typów argumentów i zastosowanego porządku w klauzuli WITHIN GROUP. Samo zastąpienie nazwy funkcji inną funkcją nie zawsze zachowuje identyczne wyniki dla wartości NULL, konwersji znaków i sortowania.

Przydatne jest wyszukiwanie zależności w definicjach obiektów oraz przegląd ostrzeżeń dotyczących funkcji przestarzałych. Definicję procedury, widoku lub funkcji można odczytać z katalogu systemowego, między innymi przez sys.sql_modules, a listę obiektów i ich typów z sys.objects. Należy sprawdzić również typy danych przekazywanych do funkcji, ponieważ zgodność nazwy nie oznacza zgodności parametrów. Funkcja może istnieć, ale odrzucać argument używany przez starszy kod. W aplikacji wielobazowej konieczne jest dodatkowo potwierdzenie, że wszystkie połączenia kierują zapytania do tej samej wersji silnika i właściwej bazy, a nie do różnych instancji o odmiennych możliwościach.

Kompatybilność funkcji podczas migracji SQL Server

Przed migracją należy sporządzić listę funkcji i konstrukcji T-SQL używanych przez aplikację oraz przypisać je do minimalnej wersji SQL Server wymaganej przez kod. Oprócz zapytań wykonywanych bezpośrednio trzeba uwzględnić procedury składowane, widoki, funkcje użytkownika, wyzwalacze, skrypty wdrożeniowe i zapytania generowane przez biblioteki aplikacyjne. Szczególną uwagę wymagają elementy oznaczone w dokumentacji jako przestarzałe, ponieważ mogą działać w obecnej wersji, lecz zostać usunięte albo zmienić zachowanie w przyszłej wersji.

Diagnoza problemu powinna obejmować odtworzenie zapytania na docelowej wersji SQL Server, sprawdzenie poziomu kompatybilności bazy oraz porównanie rezultatów, a nie tylko sprawdzenie, czy zapytanie się kompiluje. Test należy wykonać dla typowych danych, wartości pustych i NULL, różnych kolacji oraz obciążeń, przy których zmieniają się plany wykonania. Gdy aplikacja przestaje działać po zmianie wersji, pomocne jest rozdzielenie problemu na zgodność składni, zgodność semantyki wyniku i zgodność wydajności. Takie rozróżnienie pozwala ustalić, czy potrzebna jest zmiana zapytania, korekta poziomu kompatybilności, aktualizacja biblioteki aplikacyjnej czy kontrolowana migracja obiektów bazy.