SQL Server Release Cycle

Release Cycle SQL Server obejmuje wydania główne oraz regularne aktualizacje kumulatywne między nimi.

Na czym polega cykl wydań SQL Server

SQL Server Release Cycle opisuje sposób, w jaki Microsoft rozwija, poprawia i utrzymuje konkretną wersję silnika SQL Server. Cykl obejmuje kilka poziomów: wydanie główne produktu, początkową wersję RTM, późniejsze aktualizacje zbiorcze oraz wydania bezpieczeństwa i krytycznych poprawek. Wydanie główne zmienia numer generacji silnika i może wprowadzać nowe funkcje, zmiany optymalizatora zapytań, nowe możliwości administracyjne, obsługę nowszych systemów operacyjnych albo aktualizacje komponentów dodatkowych.

Wersje SQL Server są rozpoznawalne między innymi po numerze głównym: SQL Server 2019 używa oznaczenia 15.x, SQL Server 2022 oznaczenia 16.x, a SQL Server 2025 oznaczenia 17.x. W ramach jednej generacji zmienia się numer kompilacji, na przykład po zainstalowaniu kolejnego Cumulative Update. Aktualizacja CU nie jest nową wersją główną SQL Server, lecz kolejnym poziomem serwisowym tej samej generacji. Z tego powodu aplikacja może nadal pracować na SQL Server 2022, mimo że numer kompilacji silnika uległ zmianie.

RTM, Cumulative Update i GDR

RTM, czyli Release to Manufacturing, jest bazową kompilacją udostępnianą przy premierze danej wersji SQL Server. Począwszy od SQL Server 2017, Microsoft nie wydaje już klasycznych Service Packów dla nowych generacji produktu. Ich rolę w bieżącym utrzymaniu przejęły przede wszystkim aktualizacje kumulatywne, oznaczane skrótem CU. Każdy kolejny CU zawiera poprawki z poprzednich aktualizacji dla tej samej wersji SQL Server, dlatego instalowanie wszystkich wcześniejszych CU po kolei nie jest wymagane.

CU może obejmować poprawki błędów silnika Database Engine, usprawnienia niezawodności, zmiany dotyczące wydajności, korekty obsługi replikacji, modyfikacje komponentów integracyjnych oraz poprawki bezpieczeństwa. Microsoft publikuje dla każdego CU numer KB, datę wydania, numer kompilacji, listę naprawionych problemów i informacje o znanych ograniczeniach. Osobną ścieżkę stanowią GDR, czyli General Distribution Release. GDR-y są przeznaczone głównie dla poprawek bezpieczeństwa oraz problemów o szerokim wpływie. Instalacja pierwszego CU przenosi instancję na gałąź CU; późniejsze pakiety muszą odpowiadać aktualnej ścieżce serwisowej instancji.

Częstotliwość aktualizacji i okres utrzymania

Dla SQL Server 2017 i nowszych Microsoft stosuje przewidywalny model serwisowania. W pierwszym roku po premierze danej wersji CU były planowane co miesiąc, a w kolejnych latach pięcioletniego okresu wsparcia mainstream zwykle co dwa miesiące. Rzeczywista dostępność konkretnego pakietu zależy od zakresu zmian, testów oraz decyzji zespołu SQL Server. Po opublikowaniu aktualizacji należy sprawdzić jej dokumentację, ponieważ numer CU, data wydania i liczba poprawek różnią się między generacjami silnika.

Cykl produktu obejmuje wsparcie mainstream oraz późniejszy okres extended support. Wsparcie mainstream koncentruje się na regularnych poprawkach funkcjonalnych, niezawodności i bezpieczeństwie, natomiast w extended support zakres wydań jest węższy i obejmuje przede wszystkim aktualizacje zabezpieczeń oraz krytyczne poprawki zgodne z polityką cyklu życia produktu. SQL Server 2016 i starsze wersje miały dodatkowo Service Packi, które tworzyły bazę dla dalszych aktualizacji. Przy planowaniu migracji trzeba więc rozróżnić wersję silnika, edycję, system operacyjny, używane komponenty oraz datę zakończenia wsparcia dla konkretnej generacji.

Znaczenie cyklu wydań w diagnostyce instancji

Przy diagnozowaniu problemu z SQL Server nie wystarczy informacja, że zainstalowano „najnowszą wersję”. Trzeba ustalić dokładną edycję, numer generacji, poziom produktu i numer kompilacji. Można to sprawdzić zapytaniem SELECT SERVERPROPERTY('ProductVersion') AS ProductVersion, SERVERPROPERTY('ProductLevel') AS ProductLevel, SERVERPROPERTY('Edition') AS Edition;. Warto porównać otrzymany numer z oficjalną tabelą buildów Microsoftu i dokumentacją odpowiedniego CU. SQL Server 2025 ma numer generacji 17.x, ale sama informacja „17.x” nie wskazuje, czy instancja korzysta z RTM, CU1, CU2 czy nowszej kompilacji.

Aktualizacja CU powinna być poprzedzona kopią zapasową baz, sprawdzeniem miejsca na dysku, analizą wymagań restartu oraz testem aplikacji korzystających z serwera. Po instalacji należy zweryfikować stan usług, połączenia klientów, zadania SQL Server Agent, harmonogramy kopii zapasowych, działanie planów konserwacji i ewentualne zmiany w planach wykonania zapytań. Jeżeli po aktualizacji pojawi się problem, numer kompilacji z historii instalatora, dzienników SQL Server i wyników SERVERPROPERTY pozwala precyzyjnie powiązać objaw z konkretnym pakietem KB. Regularne śledzenie CU i GDR ogranicza ryzyko utrzymywania instancji na bazowej kompilacji RTM, w której znane błędy i luki nie zostały jeszcze usunięte.