Kompatybilność wersji SQL Server

Kompatybilność wersji SQL Server określa, które wydania mogą współpracować ze sobą przy replikacji i migracji danych.

Czym jest zgodność wersji SQL Server

Kompatybilność wersji SQL Server obejmuje kilka różnych zagadnień, których nie należy utożsamiać. Współpraca dwóch instancji może oznaczać możliwość połączenia klienta z serwerem, obsługę określonego poziomu zgodności bazy danych, wykonanie migracji albo działanie konkretnego mechanizmu replikacji. Każdy z tych obszarów ma własne wymagania. Sama zgodność numerów wersji nie gwarantuje więc, że dowolna baza lub konfiguracja replikacji będzie działała bez zmian.

SQL Server przechowuje w metadanych bazy danych poziom zgodności, na przykład 100, 110, 120, 130, 140, 150, 160 albo 170, zależnie od obsługiwanej wersji silnika. Poziom ten wpływa przede wszystkim na zachowanie optymalizatora zapytań i wybrane elementy języka T-SQL. Nie zmienia on fizycznego formatu plików danych ani nie oznacza, że starszy silnik potrafi uruchomić bazę utworzoną na nowszej wersji. Po migracji do nowszego SQL Server poziom zgodności można zwykle pozostawić na dotychczasowej wartości i zmienić go dopiero po testach.

Poziom zgodności bazy a wersja instancji

Wersję instancji SQL Server można sprawdzić między innymi zapytaniem SELECT @@VERSION;. Informację o poziomie zgodności konkretnej bazy zwraca zapytanie SELECT name, compatibility_level FROM sys.databases;. Są to dwa odrębne parametry. Instancja określa możliwości silnika i obsługiwany format, natomiast poziom zgodności steruje wybranymi regułami wykonywania zapytań w danej bazie.

Przy migracji do nowszego wydania SQL Server baza może przez pewien czas działać z wcześniejszym poziomem zgodności. Takie rozwiązanie ułatwia etapowe testowanie aplikacji, ponieważ ogranicza jednoczesną zmianę wersji silnika i zachowania optymalizatora. Po sprawdzeniu zapytań, procedur składowanych, widoków, funkcji oraz zadań aplikacyjnych poziom można podnieść poleceniem ALTER DATABASE, na przykład ALTER DATABASE [NazwaBazy] SET COMPATIBILITY_LEVEL = 160;, o ile dana instancja obsługuje wskazaną wartość.

Nie należy obniżać poziomu zgodności jako uniwersalnego sposobu naprawy błędów migracji. Starszy poziom nie przywraca funkcji usuniętych z silnika, nie cofa zmian w schemacie i nie zapewnia zgodności z aplikacją, która wymaga nowych typów danych lub nowych poleceń. Zmiana może również wpływać na plany wykonania zapytań, dlatego jej skutki trzeba oceniać na reprezentatywnych danych i przy rzeczywistym obciążeniu.

Replikacja między wydaniami SQL Server

W replikacji SQL Server zgodność zależy od rodzaju replikacji, roli instancji oraz kierunku przepływu danych. Replikacja transakcyjna wykorzystuje wydawcę, dystrybutora i subskrybenta, a replikacja scalona korzysta z mechanizmów synchronizacji zmian. Replikacja migawek przekazuje opublikowane dane i obiekty w postaci migawki. Nie można zakładać, że zasady dla jednego typu replikacji są identyczne dla pozostałych.

Ważne jest rozróżnienie wydawcy i subskrybenta. W wielu scenariuszach nowsza wersja SQL Server może publikować dane do starszego subskrybenta, ale tylko w granicach określonych przez dokumentację danego wydania i konfiguracji. Ograniczenia mogą dotyczyć użytej funkcji replikacji, wersji agenta, schematu artykułów, typów danych, filtrów oraz sposobu dostarczania poleceń. Przy planowaniu połączenia należy sprawdzić macierz obsługiwanych kombinacji, a nie wyciągać wniosku wyłącznie z faktu, że obie instancje używają SQL Server.

Przed uruchomieniem synchronizacji sprawdza się między innymi wersję instancji, rolę każdego serwera, wersję i konfigurację SQL Server Agent, ustawienia dystrybutora, uprawnienia, ścieżki plików migawek oraz zgodność schematu. Trzeba także ustalić, czy artykuły wykorzystują kolumny, typy danych lub funkcje dostępne po obu stronach. Błąd zgodności może wystąpić dopiero podczas generowania migawki, odtwarzania skryptu schematu albo zastosowania konkretnej transakcji u subskrybenta.

Migracja bazy i bezpieczne sprawdzenie środowiska

Migracja między wersjami SQL Server powinna zaczynać się od inwentaryzacji zależności. Oprócz samej bazy należy uwzględnić loginy, mapowania użytkowników, zadania SQL Server Agent, poświadczenia, linkowane serwery, certyfikaty, procedury składowane, rozszerzone procedury oraz aplikacje korzystające z bazy. Kopia zapasowa wykonana na nowszej wersji SQL Server nie jest przeznaczona do odtworzenia na starszej wersji silnika, dlatego kierunek migracji ma zasadnicze znaczenie.

Po odtworzeniu kopii na nowszej instancji należy zweryfikować stan bazy, integralność danych, działanie indeksów, procedur i zapytań oraz zachowanie aplikacji. Przydatne jest wykonanie DBCC CHECKDB w środowisku testowym, przejrzenie błędów konwersji typów i sprawdzenie planów wykonania zapytań, które są wrażliwe na zmianę optymalizatora. Dobrą praktyką jest porównanie wyników funkcjonalnych i czasów wykonania przed zmianą oraz po zmianie, zamiast uznawania samego pomyślnego odtworzenia kopii za zakończenie migracji.

Kompatybilność wersji SQL Server wymaga zatem osobnego potwierdzenia dla silnika, bazy, aplikacji i używanego mechanizmu replikacji. W przypadku problemów diagnostyka powinna objąć zarówno komunikat błędu, jak i faktyczną wersję instancji, poziom zgodności bazy, definicje obiektów oraz konfigurację przepływu danych. Pozwala to odróżnić błąd wynikający z nieobsługiwanej funkcji od problemu z uprawnieniami, schematem lub ustawieniami synchronizacji.