Wymagania wersji SQL Server (2014+)

Niektóre funkcje SQL Server, np. część mechanizmów Always On, wymagają wersji 2014 lub nowszej.

Wymagania wersji SQL Server (2014+) — znaczenie oznaczenia

Wymagania wersji SQL Server (2014+) określają minimalne wydanie silnika baz danych, na którym może zostać uruchomiona konkretna aplikacja, procedura, usługa albo mechanizm administracyjny. Zapis „2014+” nie oznacza, że każda instalacja musi korzystać dokładnie z wydania z 2014 roku. Wskazuje się w ten sposób na SQL Server 2014 lub dowolną późniejszą wersję, o ile pozostałe warunki zgodności zostaną spełnione. W praktyce znaczenie mają również edycja produktu, poziom aktualizacji, obsługiwany system operacyjny, architektura procesora, dostępna pamięć oraz sposób komunikacji z bazą.

Sam numer głównego wydania nie przesądza jeszcze o pełnej zgodności. Należy rozróżnić wersję silnika, poziom kompatybilności bazy, wersję narzędzi klienckich oraz wersję sterownika używanego przez aplikację. Baza utworzona w starszym wydaniu może działać na nowszym silniku, ale nie zawsze będzie od razu korzystać z nowych funkcji. Z kolei baza utworzona w nowszym wydaniu nie może zostać bezpośrednio przywrócona na starszym silniku bez zastosowania dodatkowych metod migracji.

Wymaganie „2014 lub nowszy” bywa stosowane w dokumentacji producenta programu, ponieważ od tego wydania dostępne są określone typy danych, funkcje języka T-SQL, mechanizmy indeksowania, narzędzia raportowe albo rozwiązania poprawiające ciągłość pracy. Przy interpretacji takiego zapisu powinno się ustalić, czy chodzi o minimalną wersję silnika, czy również o konkretną edycję, aktualizację zbiorczą i poziom kompatybilności. Bez tego sama informacja o numerze rocznika może prowadzić do błędnej oceny środowiska.

Wymagania wersji SQL Server a poziom kompatybilności bazy

Poziom kompatybilności jest ustawieniem zapisanym dla konkretnej bazy danych. Pozwala zachować część wcześniejszych zasad działania podczas przenoszenia bazy na nowszą wersję silnika. Nie jest jednak zamiennikiem zgodnego silnika. Ustawienie niższego poziomu nie sprawi, że funkcja dostępna dopiero w nowszej wersji zacznie działać na starszym wydaniu. Z tego powodu podczas planowania migracji sprawdza się równocześnie numer silnika i poziom kompatybilności każdej bazy.

Przykładowo baza przeniesiona z SQL Server 2012 na SQL Server 2019 może początkowo zachować niższy poziom kompatybilności, aby ograniczyć liczbę zmian wykonywanych jednocześnie. Następnie przeprowadza się testy zapytań, procedur, widoków, zadań oraz aplikacji korzystających z danych. Dopiero po potwierdzeniu poprawnego działania rozważa się zmianę poziomu kompatybilności. Taki etap przejściowy ułatwia wykrycie różnic w optymalizacji zapytań i zachowaniu funkcji, ale nie eliminuje potrzeby wykonania kopii zapasowej oraz planu wycofania zmian.

Ważna jest także zgodność narzędzi pomocniczych. Management Studio, sterowniki ODBC, dostawcy OLE DB, biblioteki .NET oraz konektory używane przez system finansowy lub magazynowy mogą mieć własne ograniczenia. Nowszy silnik nie zawsze oznacza, że stara aplikacja będzie działała bez modyfikacji. W drugą stronę, nowszy sterownik kliencki może wymagać ustawienia szyfrowania, zaufania do certyfikatu albo zmiany parametrów połączenia. Dlatego weryfikacja powinna obejmować cały łańcuch: aplikację, bibliotekę komunikacyjną, konto, sieć, silnik i bazę.

W środowiskach wykorzystujących replikację, kopie zapasowe, log shipping lub mechanizmy wysokiej dostępności wymagania wersji mogą dotyczyć więcej niż jednego serwera. Sprawdza się zgodność węzłów, trybów pracy, ról, agentów zadań i narzędzi monitorujących. Istotne bywają także zasady dotyczące aktualizacji, ponieważ różnica między wydaniami głównymi a poziomami poprawek może wpływać na możliwość dołączenia instancji, odtworzenia kopii albo przeprowadzenia kontrolowanego przełączenia.

Wymagania wersji SQL Server w porównaniu z edycją i aktualizacją

Wymagania wersji SQL Server należy odróżnić od wymagań edycji. Wersja określa generację produktu, natomiast edycja wpływa na dostępne funkcje, limity i model licencjonowania. Ta sama generacja może występować w kilku edycjach, które różnią się między innymi zakresem mechanizmów analitycznych, możliwościami wysokiej dostępności, ograniczeniami zasobów i obsługą określonych scenariuszy. Jeżeli dokumentacja wskazuje „SQL Server 2014+”, a w dalszej części wymienia funkcję właściwą tylko dla wybranej edycji, oba warunki muszą zostać potraktowane łącznie.

Osobną kwestią jest poziom aktualizacji. Instalacja SQL Server 2014 bez późniejszych poprawek może zachowywać się inaczej niż ta sama wersja po zastosowaniu odpowiednich aktualizacji zbiorczych. Poprawki mogą usuwać błędy, zmieniać obsługę protokołów, zwiększać bezpieczeństwo oraz wprowadzać korekty współpracy z systemem operacyjnym. Przy analizie zgodności należy więc odczytać pełny numer kompilacji, a nie tylko nazwę głównego wydania.

Porównanie środowiska powinno obejmować także system operacyjny i sposób wdrożenia. Wymagania dla instalacji lokalnej mogą różnić się od wymagań dla instancji uruchomionej w środowisku wirtualnym lub w usłudze zarządzanej. Znaczenie ma liczba rdzeni udostępnionych procesowi, rozmiar pamięci, rodzaj magazynu danych, system plików, dostępność portów, zasady zapory i uprawnienia konta usługi. Nie należy zakładać, że zgodność aplikacji z SQL Server 2014 automatycznie potwierdza poprawność całej konfiguracji.

W przypadku przenoszenia danych przydatne jest rozdzielenie kilku operacji: wykonania kopii zapasowej, odtworzenia jej na docelowym silniku, sprawdzenia integralności, aktualizacji statystyk, testu zapytań oraz testu aplikacji. Każdy etap może ujawnić inny rodzaj problemu. Błąd odtworzenia może wynikać z różnicy wersji, wolne zapytanie z planu wykonania, a niedostępna funkcja z edycji lub ustawień zabezpieczeń. Takie rozdzielenie ułatwia wskazanie rzeczywistej przyczyny zamiast przypisywania wszystkich problemów samemu numerowi wersji.

Typowe problemy związane z wymaganiami wersji SQL Server

Jednym z częstszych problemów jest odczytywanie symbolu „+” jako gwarancji pełnej zgodności z każdym nowszym wydaniem. W praktyce nowsze wydanie może zmieniać sposób optymalizacji zapytań, obsługi typów danych, szyfrowania, uprawnień albo połączeń. Aplikacja może uruchomić się poprawnie, lecz dopiero przy określonej funkcji ujawnić niezgodność. Szczególnej uwagi wymagają własne rozszerzenia, procedury tworzone przez producenta programu oraz zapytania zależne od nieudokumentowanego zachowania.

Inny problem występuje wtedy, gdy aplikacja sprawdza wersję po stronie klienta, a nie po stronie silnika. Aktualizacja samego sterownika może usunąć jeden błąd, lecz jednocześnie ujawnić konieczność zmiany parametrów bezpieczeństwa. Zdarza się również, że narzędzie instalacyjne rozpoznaje wyłącznie określone nazwy wersji i odmawia pracy z nowszym wydaniem, mimo że sama komunikacja z bazą byłaby technicznie możliwa. W takim przypadku potrzebna jest aktualizacja aplikacji albo zastosowanie zatwierdzonego wariantu sterownika.

Problemy mogą pojawić się przy odtwarzaniu kopii zapasowej, przenoszeniu logów i automatyzacji zadań. Należy zweryfikować właścicieli baz, konta wykonujące zadania, ścieżki plików, uprawnienia do katalogów, harmonogramy oraz dostęp do udziałów sieciowych. Po migracji sprawdza się również zadania agenta, alerty, operatorów, certyfikaty i połączenia zewnętrzne. Brak błędu podczas importu nie oznacza jeszcze, że wszystkie procesy działające wcześniej zostały odtworzone.

Wymagane jest także sprawdzenie wydajności po zmianie wersji. Ten sam tekst zapytania może otrzymać inny plan wykonania, szczególnie gdy zmieniły się statystyki, indeksy lub sposób szacowania liczby rekordów. Porównuje się czas odpowiedzi, obciążenie procesora, zużycie pamięci, operacje wejścia i wyjścia oraz blokady. Wnioski powinny być wyciągane z pomiarów wykonanych na reprezentatywnych danych, a nie wyłącznie z krótkiego testu pojedynczego formularza.

Praktyczne wskazówki dla wymagań wersji SQL Server (2014+)

Przed instalacją albo migracją warto sporządzić kartę środowiska. Powinny znaleźć się w niej: pełna wersja silnika, edycja, poziom kompatybilności baz, wersja systemu operacyjnego, używane sterowniki, lista aplikacji, harmonogram kopii zapasowych, wymagania dotyczące szyfrowania oraz zależności między bazami. Pomocne jest zapisanie również informacji o kodowaniu, sortowaniu, języku, ustawieniach strefy czasowej i kontach wykorzystywanych przez usługi.

Następnie przygotowuje się kopię zapasową i środowisko testowe możliwie podobne do docelowego. Test powinien obejmować logowanie, odczyt i zapis danych, wyszukiwanie, raporty, importy, eksporty, zadania cykliczne oraz procedury wykonywane w godzinach największego obciążenia. Jeżeli aplikacja jest używana przez kilka stanowisk, należy sprawdzić jednoczesne połączenia i blokady. W przypadku dużych baz przydatne staje się porównanie czasu odtworzenia, rozmiaru plików i zapotrzebowania na przestrzeń tymczasową.

Nie zaleca się zmiany kilku głównych elementów naraz bez możliwości ustalenia kolejności przyczyn. Bezpieczniejszy proces zakłada przygotowanie punktu powrotu, udokumentowanie stanu wyjściowego, wykonanie testu, wprowadzenie zmiany oraz ponowny pomiar. Przydatne jest zachowanie logów instalatora i wyników kontroli integralności. Należy również ustalić, kto podejmuje decyzję o przejściu na wyższy poziom kompatybilności i jakie kryteria uznaje się za wystarczające.

Jeżeli wymaganie pochodzi z instrukcji producenta oprogramowania, powinno się sprawdzić aktualną matrycę zgodności dla konkretnego wydania aplikacji. Warto ustalić, czy producent dopuszcza nowszy silnik, czy wymaga określonej edycji oraz czy potrzebna jest konkretna aktualizacja. W razie braku jednoznacznej informacji decyzję należy oprzeć na testach i dokumentacji, a nie na samym podobieństwie numerów.

Kiedy zgłosić się do serwisu przy wymaganiach wersji SQL Server

Wsparcie serwisowe jest zasadne, gdy instalacja zatrzymuje się na sprawdzaniu wymagań, aplikacja nie nawiązuje połączenia, kopia nie daje się odtworzyć, po migracji pojawiają się błędy logowania albo działanie programu wyraźnie zwalnia. Pomoc przydaje się również wtedy, gdy nie jest znana pełna wersja silnika, brakuje dokumentacji poprzedniej konfiguracji lub nie ma pewności, czy kopie zapasowe można bezpiecznie wykorzystać.

Warszawskie Pogotowie Komputerowe 24/7 zajmuje się wsparciem dotyczącym laptopów i komputerów PC, w tym analizą konfiguracji, przygotowaniem stanowiska do pracy oraz porządkowaniem problemów ujawnionych podczas instalacji oprogramowania. Przed przekazaniem sprzętu warto opisać objawy, podać nazwę programu, wskazać moment wystąpienia błędu i zachować dokładny komunikat. Takie informacje ułatwiają odtworzenie sytuacji oraz rozdzielenie problemu wersji, sterownika, uprawnień i konfiguracji systemu.

Przy zgłoszeniu należy poinformować, czy potrzebna jest sama ocena zgodności, czy także przygotowanie kopii zapasowej, przeniesienie danych, konfiguracja aplikacji i test po zakończeniu prac. W przypadku baz używanych przez firmowe programy ważne jest wcześniejsze ustalenie osoby uprawnionej do akceptacji zmian oraz terminu wykonania testów. Dzięki temu wymagania wersji SQL Server (2014+) mogą zostać przełożone na konkretną, sprawdzalną konfigurację zamiast pozostać ogólnym zapisem w dokumentacji.