W lipcu kończy się wsparcie techniczne dla Microsoft SQL Server 2008 oraz SQL Server 2008 R2, co teoretycznie wymusza migrację na nowszą wersje RDBMS tego dostawcy. Teoretycznie, ponieważ nie oznacza to, że nasza instancja SQL Server zatrzyma się dokładnie 9 lipca.

W takim razie, co oznacza zakończenie wsparcia dla produktu?

Nie pojawią się żadne nowe aktualizacje zabezpieczeń, aktualizacje niezwiązane z zabezpieczeniami, bezpłatne lub płatne opcje asystowanej pomocy technicznej ani aktualizacje zawartości technicznej online.

https://support.microsoft.com/pl-pl/help/4316957/products-reaching-end-of-support-for-2019

Dla jednych to wystarczające powody do podniesienie wersji dla inni nie do końca. Dlatego nie trudno znaleźć działające instancje SQL Server 2005 w niektórych firmach, choć dla uczciwości dodam, że powody też mogą być inne.

Niemniej jednak, niezależnie czy zmierzyłeś się z SQL Server 2008 lub jeszcze to przed Tobą chciałbym podzielić się 9 punktami, które warto przemyśleć, wykonać, spisać przed każdą migracją (niezależnie od wersji).

Migracja w punktach

  • Ustal z biznesem dopuszczalny czas niedostępności systemu, którego elementem jest SQL Server.
  • Jeśli to możliwe sprawdź w dokumentacji lub u dostawcy, dla jakiej wersji gwarantują wsparcie. To określi wersje SQL Server.
  • Rozważ odpowiedni sposób migracji:
    • in-place, czyli podniesienie istniejącej instancji na istniejącym serwerze,
    • side-by-side, czyli instalacja z boku nowej instancji na tym samym, istniejącym serwerze,
    • nowa instancja na nowym serwerze
MigracjaZaletyWadyInne
In-place– Krótki czas niedostępności
– Zachowana konfiguracja instancji, uprawnień, itd.
– Brak zmiany nazwy instancji, adresu, nazwy serwera,
– Brak potrzeb alokowania dodatkowych zasobów sprzętowych
– Trudny scenariusz wycofania,
– Niejawne podniesienie baz do nowszej wersji SQL Server
– Należy wziąć pod uwagę długość wsparcia
dla systemu operacyjnego.
Na przykład dla
Windows Server 2008 z SP2 wsparcie kończy się 14 stycznia 2020 r.

Side-by-Side– Prosty scenariusz wycofania (jeśli odtwarzamy bazy z kopii),
Brak zmiany nazwy instancji, adresu, nazwy serwera
– Nazwana instancja SQL Server,
– Potrzeba migracji ustawień, uprawnień, itd,
– Potrzeba alokowania dodatkowych zasobów dyskowych
– Dłuższy czas niedostępności
(przeniesienie baz danych, uprawnień, ustawień)



– Należy wziąć pod uwagę długość wsparcia
dla systemu operacyjnego.
Na przykład dla Windows Server 2008 z SP2 wsparcie kończy się 14 stycznia 2020 r.

Nowa instancja– Prosty scenariusz wycofania,
– Nowy system operacyjny,
– Domyślna nazwa instancji
– Potrzeba za alokowania dodatkowych zasobów,
– Konfiguracja systemu, aplikacji (nowa nazwa serwera, nowy IP)
– Dłuższy czas niedostępności

Jedna ważna rzecz, o której warto pamiętać, dołączenie bazy powoduję niejawną aktualizację bazy i powrót do starszej wersji nie będzie możliwe (bez przywrócenia bazy danych z kopii).

  • Przygotuj ewentualny plan wycofania w momencie niepowodzenia mając na uwadze wybrany sposób migracji.
  • Sprawdź listę niewspieranych funkcjonalności, z których korzystasz a które mogą nie być dostępne w nowszej wersji SQL Server.

Skorzystaj z zapytania aby zobaczyć, które przestarzałe funkcje są wykorzystywane, następnie sprawdź czy nie zostały wycofane w nowszej wersji.

  • Zbierz dane o obecnej instancji, między innymi ustawienia instancji, informacje o bazach danych, login, linked server, joby, alerty, ustawienia poczty, audyty, itd.
  • Zbierz metryki wydajnościowe obecnej instancji, aby móc porównać ten element przed i po migracji.
  • Sprawdź, z jakich jeszcze funkcje SQL Server korzystasz (Reporting Services, Integration Services, itd.). Może, to dziwne, ale sprawdź czy na pewno są potrzebne
  • Jeśli wykorzystujesz Transparent Data Encryption lub Backup Encryption to upewnij się, że posiadasz kopie zapasowe certyfikatu kluczy asymetrycznych. Bez certyfikatu lub klucza kopie bezpieczeństwa i bazy danych będą bezużyteczne. Naprawdę nic z tym nie zrobisz.

Pewnie to nie wszystko.

Jednak te 9 punktów jest dobrym wstępem do zaplanowania migracji pomiędzy wersjami SQL Server. Jeśli, myślisz, że warto byłoby coś dodać to zostaw komentarz.

Na sam koniec, może również rozważyć opcję migracji SQL Server do chmury publicznej, jeśli tak to zobacz mój wpis na temat migracji SQL Server do Microsoft Azure.

Mateusz Nadobnik

Z pasją poświęcam czas na zdobywanie wiedzy w zakresie szeroko rozumianej Data Platform. Zachwycony językiem skryptowym Windows PowerShell. Swoją wiedzę, doświadczenia i spostrzeżenia opisuję na blogu.

read more