Kompatybilność między wersjami

Kompatybilność między wersjami określa, czy baza utworzona w nowszym SQL Server otworzy się w starszym wydaniu — zwykle nie.

Na czym polega kompatybilność między wersjami SQL Server

Kompatybilność między wersjami SQL Server określa, czy baza danych utworzona albo zmodyfikowana przez nowszą wersję silnika może zostać uruchomiona w starszej wersji. W przypadku natywnego formatu bazy danych jest to przede wszystkim zgodność jednokierunkowa: starszą bazę można zwykle przenieść do nowszego wydania SQL Server, natomiast bezpośrednie otwarcie bazy zapisanej przez nowsze wydanie w starszym silniku nie jest obsługiwanym scenariuszem. Dotyczy to między innymi plików danych MDF i NDF oraz pliku dziennika transakcji LDF.

Podczas aktualizacji baza może zostać poddana wewnętrznej konwersji. Po takim procesie nie należy zakładać, że jej pliki zachowają możliwość ponownego podłączenia do poprzedniej wersji silnika. Sama zgodność aplikacji z bazą to osobne zagadnienie. Program może poprawnie łączyć się z dwiema wersjami SQL Server, ale zapytania, procedury składowane, sterowniki lub funkcje używane przez aplikację mogą zachowywać się odmiennie po zmianie środowiska.

Różnica między wersją silnika a poziomem zgodności bazy

SQL Server udostępnia poziom zgodności bazy danych, czyli ustawienie określające wybrane zachowania języka Transact-SQL oraz optymalizatora zapytań. Poziom zgodności można zmienić dla bazy działającej na nowszym silniku, aby ułatwić kontrolowane przejście aplikacji do nowego wydania. Nie jest to jednak konwerter plików i nie zapewnia uruchomienia bazy z nowszej wersji na starszym serwerze. Nowszy silnik może obsługiwać starszy poziom zgodności, ale starszy silnik nie uzyskuje w ten sposób obsługi późniejszego formatu bazy.

Poziom zgodności wpływa na interpretację określonych konstrukcji zapytań, wybór planów wykonania oraz działanie części funkcji. Z tego powodu po migracji mogą pojawić się zmiany wydajności bez widocznego błędu składni. Prawidłowa kontrola obejmuje sprawdzenie zapytań aplikacji, procedur składowanych, widoków, funkcji, wyzwalaczy i zadań uruchamianych cyklicznie. Warto również rozdzielić problem niezgodności silnika od problemu niezgodności klienta: starszy sterownik może nie rozumieć nowych typów danych lub metod uwierzytelniania, nawet gdy sama baza działa prawidłowo.

Przenoszenie bazy do starszego wydania

Operacja przywrócenia kopii zapasowej nie działa w dowolnym kierunku. Kopia zapasowa bazy wykonana w nowszej wersji SQL Server może zostać przywrócona w odpowiednim nowszym wydaniu, ale nie można traktować jej jako sposobu na cofnięcie bazy do starszego silnika. Podobne ograniczenie dotyczy bezpośredniego odłączania i ponownego podłączania plików bazy. Polecenia ATTACH nie omijają różnic formatu zapisanych w plikach.

Jeżeli wymagane jest przeniesienie danych do starszej wersji, trzeba użyć migracji logicznej, a nie kopiowania plików. Stosuje się wtedy między innymi skrypty tworzące obiekty i dane, eksport tabel, import do wcześniej utworzonej bazy albo narzędzia transferu danych zgodne z zakresem obsługiwanych wersji. Konieczne jest osobne odtworzenie schematu, indeksów, ograniczeń, uprawnień oraz elementów zależnych od instancji. Nie wszystkie obiekty mają prosty odpowiednik w starszym wydaniu, dlatego przed migracją należy wykryć użycie funkcji wprowadzonych dopiero w nowszej wersji. Po imporcie trzeba sprawdzić integralność danych oraz wykonać testy aplikacji.

Jak rozpoznać problem zgodności przed migracją

Przed zmianą serwera należy ustalić dokładną wersję instancji SQL Server, wersję bazy źródłowej, ustawiony poziom zgodności oraz sposób przenoszenia danych. Sam numer poziomu zgodności nie wystarcza do oceny możliwości migracji. Trzeba także sprawdzić funkcje używane przez kod bazy, typy danych, składnię zapytań, ustawienia sortowania, zależności między bazami i wymagania sterownika po stronie aplikacji. Osobnej kontroli wymagają zadania SQL Server Agent, poświadczenia, certyfikaty, linkowane serwery oraz inne obiekty zapisane poza podstawowym schematem użytkowników.

Diagnostyka powinna rozpocząć się od kopii zapasowej i odtworzenia jej w środowisku testowym, bez ingerowania w bazę produkcyjną. Następnie należy uruchomić reprezentatywne operacje aplikacji: odczyt, zapis, transakcje, raporty i procedury modyfikujące dane. Błędy „feature not supported”, problemy z konwersją typów, nieznane obiekty lub różnice w planach wykonania wskazują na konkretne obszary do sprawdzenia. Jeżeli baza pochodząca z nowszego wydania ma działać na starszym SQL Server, konieczne jest zaplanowanie migracji logicznej i weryfikacja każdego elementu, którego starszy silnik może nie obsługiwać. W przypadku uszkodzeń plików, błędów odczytu lub nieudanej konwersji potrzebna jest diagnostyka nośnika, systemu plików oraz samej bazy, a nie przypadkowa zmiana poziomu zgodności.