Aktualizacja SQL Server

Aktualizacja SQL Server to proces instalacji poprawek lub nowej wersji tego systemu zarządzania bazami danych.

Na czym polega aktualizacja SQL Server

Aktualizacja SQL Server obejmuje instalację poprawek bezpieczeństwa, poprawek jakościowych, aktualizacji zbiorczych albo nowej wersji silnika bazy danych. W praktyce nie jest to wyłącznie podmiana plików programu. Instalator może zmienić składniki usługi Database Engine, SQL Server Agent, Integration Services, Analysis Services, Reporting Services, narzędzia administracyjne oraz biblioteki używane przez aplikacje klienckie. Zakres zmian zależy od tego, które funkcje zostały zainstalowane na danym komputerze i jaki pakiet aktualizacyjny jest przeznaczony dla konkretnej wersji SQL Server.

Wydania SQL Server są rozróżniane między innymi przez główną wersję, edycję, poziom aktualizacji oraz numer kompilacji. Po instalacji poprawki numer kompilacji można sprawdzić zapytaniem SELECT @@VERSION; albo przez właściwości serwera w SQL Server Management Studio. Sam fakt, że system operacyjny został zaktualizowany, nie oznacza aktualizacji silnika SQL Server. Również aktualizacja narzędzi klienckich nie musi zmieniać instancji, na której działają bazy danych.

Różnice między poprawką a zmianą wersji

Poprawki zabezpieczeń i aktualizacje zbiorcze zwykle pozostają w obrębie tej samej głównej wersji SQL Server. Ich celem jest usunięcie błędów, luk lub problemów ze stabilnością bez przeprowadzania pełnej migracji do nowszej generacji produktu. W zależności od ścieżki serwisowania aktualizacja może być dostarczana jako pakiet GDR, zawierający głównie poprawki związane z bezpieczeństwem i krytyczną niezawodnością, albo jako CU, czyli aktualizacja zbiorcza obejmująca większy zestaw napraw. Przed instalacją trzeba potwierdzić, że wybrany pakiet dotyczy właściwej gałęzi produktu i poziomu kompilacji.

Przejście do nowszej głównej wersji SQL Server jest odrębną operacją. Może wymagać sprawdzenia zgodności aplikacji, sterowników, narzędzi, rozszerzeń oraz procedur wdrożeniowych. Po migracji baza może nadal używać wcześniejszego poziomu kompatybilności, który wpływa na sposób optymalizacji zapytań i zachowanie wybranych funkcji języka T-SQL. Zmiana poziomu kompatybilności nie powinna być traktowana jako automatyczny etap każdej aktualizacji. Należy ją poprzedzić testami, ponieważ nowy optymalizator zapytań może wybrać inne plany wykonania niż w poprzedniej konfiguracji.

Przygotowanie instancji i baz danych

Przed rozpoczęciem aktualizacji należy ustalić nazwę instancji, zainstalowane funkcje, edycję produktu, bieżący numer kompilacji oraz sposób uruchamiania usług. Warto sprawdzić zależności między instancją a aplikacjami, zadaniami SQL Server Agent, połączeniami zewnętrznymi i mechanizmami wysokiej dostępności. Istotne jest również potwierdzenie wolnego miejsca na dysku, uprawnień konta wykonującego instalację oraz dostępności nośnika lub pakietu aktualizacyjnego. Instalator powinien zostać uruchomiony dla właściwego wystąpienia SQL Server, a nie tylko dla narzędzi zarządzających.

Przed zmianą trzeba wykonać i zweryfikować kopie zapasowe baz użytkownika, baz systemowych oraz elementów konfiguracyjnych wymaganych do odtworzenia instancji. Sama obecność pliku kopii zapasowej nie potwierdza jej przydatności; należy sprawdzić możliwość odczytu i, w środowisku testowym, przeprowadzić próbę odtworzenia. Należy także zapisać konfigurację połączeń, ustawienia usług, harmonogramy zadań, dane uwierzytelniające używane przez zadania oraz konfigurację certyfikatów, jeśli są wykorzystywane przez konkretną instancję. W przypadku grup dostępności lub innych mechanizmów rozłożenia ról aktualizację trzeba zaplanować zgodnie z kolejnością przewidzianą dla danego układu, aby ograniczyć przerwę w dostępie.

Po przygotowaniu należy przeprowadzić test na środowisku możliwie zbliżonym do produkcyjnego. Test powinien obejmować uruchomienie aplikacji, wykonanie reprezentatywnych zapytań, działanie zadań automatycznych, import i eksport danych oraz odczyt logów SQL Server. Szczególną uwagę trzeba zwrócić na błędy podczas startu usług, problemy z uprawnieniami, niezgodność sterowników i zmianę czasu wykonywania kluczowych zapytań. Plan wycofania powinien określać, jakie elementy można przywrócić, w jakiej kolejności i na podstawie jakich kopii.

Kontrola po instalacji aktualizacji

Po zakończeniu instalacji należy potwierdzić, że usługa SQL Server działa, a właściwa instancja przyjmuje połączenia. Numer kompilacji można ponownie sprawdzić zapytaniem SELECT @@VERSION;. Warto przejrzeć historię instalatora oraz dzienniki SQL Server pod kątem błędów, ostrzeżeń i komunikatów o pominiętych składnikach. Należy zweryfikować stan baz poleceniami administracyjnymi, sprawdzić zadania SQL Server Agent i upewnić się, że zaplanowane kopie zapasowe nadal wykonują się poprawnie.

Kontrola nie powinna ograniczać się do samego uruchomienia usługi. Trzeba sprawdzić połączenie aplikacji, działanie kont używanych przez aplikację, dostęp do baz, operacje odczytu i zapisu oraz zapytania o największym znaczeniu dla systemu. Po aktualizacji mogą ujawnić się problemy niezwiązane z samym instalatorem, na przykład zmiana planu wykonania, nieaktualne statystyki, błędna konfiguracja sterownika albo przerwane zadanie agenta. Jeżeli po zmianie wystąpi awaria, analiza powinna obejmować numer kompilacji, logi SQL Server, dziennik zdarzeń systemu Windows oraz dokładny moment pojawienia się problemu.

Aktualizacja SQL Server wymaga więc identyfikacji konkretnej instancji, dobrania właściwego pakietu, zabezpieczenia danych, testu zgodności i kontroli działania po instalacji. W przypadku rozbudowanych baz lub środowisk o wysokiej dostępności należy dodatkowo uwzględnić kolejność aktualizowania węzłów, tryb przełączenia oraz możliwość czasowego ograniczenia dostępu do usług zależnych od bazy.