Istnieją pewne kontrowersje w społeczności SQL Server dotyczące mądrości instalowania dodatków Service Pack (SP) i aktualizacji zbiorczych (CU) dla SQL Server. Istnieje kilka różnych podstawowych stanowisk, które organizacje zazwyczaj przyjmują w tym temacie, jak wymieniono poniżej:
- Organizacja regularnie instaluje dodatki Service Pack i aktualizacje zbiorcze
- Organizacja instaluje dodatki Service Pack, ale nie instaluje aktualizacji zbiorczych
- Organizacja nie instaluje dodatków Service Pack ani aktualizacji zbiorczych
Pierwszy przypadek dotyczy organizacji, która będzie starała się być na bieżąco z dodatkami Service Pack dla programu SQL Server i aktualizacjami zbiorczymi programu SQL Server, stosując szczegółowe procedury testowania i implementacji. Moim zdaniem to najlepsza polityka. Moje stanowisko jest takie, że Twoja organizacja jest znacznie lepiej obsługiwana, jeśli jest na bieżąco z dodatkami Service Pack i aktualizacjami zbiorczymi (o ile masz procedury testowania i wdrażania oraz wymaganą infrastrukturę, aby wspierać tę politykę).
Drugi przypadek dotyczy organizacji, która (być może z pewnym opóźnieniem) zainstaluje dodatki Service Pack dla programu SQL Server, ale z jakiegokolwiek powodu nie zainstaluje aktualizacji zbiorczych programu SQL Server. To nie jest tak dobre jak w pierwszym przypadku, ale jest znacznie lepsze niż w trzecim przypadku.
W trzecim przypadku niektóre organizacje nigdy nie instalują żadnych dodatków Service Pack ani aktualizacji zbiorczych programu SQL Server z jakiegokolwiek powodu. W niektórych przypadkach w rzeczywistości pozostają one w oryginalnej kompilacji wersji produkcyjnej (RTM) głównej wersji programu SQL Server, na której działają, przez cały okres istnienia wystąpienia. Jest to najmniej pożądana zasada z wielu powodów.
Firma Microsoft stosuje zasadę wycofywania gałęzi kodu (rozgałęzienia RTM lub kolejnej gałęzi dodatku Service Pack) dla określonej wersji programu SQL Server, gdy jest ona starsza o dwie gałęzie. Na przykład po wydaniu dodatku Service Pack 2 dla programu SQL Server 2008 R2 oryginalna gałąź RTM (niezależnie od poziomu CU) została wycofana i stała się „nieobsługiwanym dodatkiem Service Pack”. Oznacza to, że nie będzie więcej poprawek ani aktualizacji zbiorczych dla tej gałęzi, a wsparcie Microsoft CSS w zakresie rozwiązywania problemów będzie ograniczone tylko w trakcie zgłoszenia do pomocy technicznej, dopóki nie zainstalujesz obsługiwanego dodatku Service Pack w swoim wystąpieniu.
Powody, dla których konserwacja SQL Server jest odroczona
W niektórych przypadkach organizacja może nie wiedzieć, w jaki sposób SQL Server jest zwykle obsługiwany za pomocą kombinacji dodatków Service Pack, aktualizacji zbiorczych i poprawek. Wiele organizacji ma sztywne, odgórne zasady dotyczące sposobu konserwacji i obsługi produktów, takich jak SQL Server, które wykluczają regularną instalację SP i/lub CU przez administratorów baz danych. Mogą również być ograniczone do obsługi swoich instancji SQL Server ze względu na to, że korzystają z baz danych innych firm, które są obsługiwane tylko przez określone przez dostawcę wersje i poziomy Service Pack SQL Server.
Wiele organizacji ma również zrozumiałą obawę przed „złamaniem” instancji SQL Server lub aplikacji zależnej od tej instancji. Mogą również brakować czasu i zasobów, aby przeprowadzić odpowiedni poziom testowania aplikacji i systemu po zainstalowaniu zaktualizowanej kompilacji SQL Server na instancji w środowisku testowym. W niektórych przypadkach mogą nie mieć dedykowanego środowiska testowego (co stanowi osobny, poważny problem).
Niektóre organizacje mogą nie mieć działającego rozwiązania o wysokiej dostępności (takiego jak tradycyjne klastry awaryjne, dublowanie baz danych lub grupy dostępności) w swoim środowisku produkcyjnym, więc są znacznie bardziej niechętne do wykonywania wszelkiego rodzaju usług, które mogą spowodować ponowne uruchomienie serwera bazy danych i spowodowanie względnie długiej przerwy w działaniu. Mogą faktycznie mieć wdrożone rozwiązanie o wysokiej dostępności, ale rzadko testują je z awaryjnym przełączeniem produkcyjnym i mogą mieć mniejsze zaufanie do jego działania i niezawodności.
Powody, dla których warto regularnie utrzymywać SQL Server
Po wymienieniu niektórych typowych powodów, dla których organizacje mogą zrezygnować z regularnego serwisowania SQL Server, nadszedł czas, aby zająć się niektórymi z tych argumentów. Po pierwsze, niewiedza na temat tego, w jaki sposób SQL Server jest zwykle obsługiwany przez Microsoft, nie jest już uzasadnioną wymówką. Firma Microsoft prowadzi blog dotyczący usług wydań SQL, w którym ogłasza zarówno dodatki Service Pack, jak i aktualizacje zbiorcze dla programu SQL Server. Matthias Bernt wyjaśnił ogólną strategię obsługi SQL Server w swoim poście:Zmienione podejście do dodatków Service Pack, z bardziej szczegółowymi informacjami na temat podejścia opartego na przyrostowym modelu obsługi SQL Server dostępnym w tym artykule bazy wiedzy firmy Microsoft.
Skrócona wersja modelu obsługi polega na tym, że poszczególne problemy z programem SQL Server są naprawiane za pomocą poprawek. Aby uzyskać dostęp do pojedynczej poprawki, musisz skontaktować się z Microsoft CSS i otworzyć zgłoszenie do pomocy technicznej (chyba że jest to poprawka związana z zabezpieczeniami, która jest rozpowszechniana przez Microsoft Update). W zależności od poziomu płatnego wsparcia w firmie Microsoft może to być stosunkowo żmudny i czasochłonny proces. Istnieje również problem polegający na tym, że większość klientów korzystających z programu SQL Server prawdopodobnie nie będzie nawet świadoma istniejących poprawek, które nie zostały wydane w ramach aktualizacji zbiorczej programu SQL Server. Oznacza to, że jest mało prawdopodobne, aby większość klientów regularnie uzyskiwała i wdrażała indywidualne poprawki.
Aktualizacje zbiorcze to pakiety zbiorcze wielu poprawek (zazwyczaj od około 10 do 50 poprawek), które są publikowane co osiem tygodni. Te aktualizacje zbiorcze są w rzeczywistości zbiorcze (jak sama nazwa wskazuje), więc po zainstalowaniu aktualizacji zbiorczej otrzymasz wszystkie wcześniej wydane poprawki dla Twojej wersji i gałęzi (RTM, SP1, SP2 itd.) kodu. Oznacza to, że powszechne stwierdzenie, że organizacje „stosują aktualizacje zbiorcze tylko w celu naprawienia określonych problemów, których doświadczają” nie jest szczególnie ważne w prawdziwym życiu.
Na przykład, jeśli korzystasz z kompilacji RTM programu SQL Server 2012 z dodatkiem Service Pack 1 (11.0.3000) i zdecydowano się zainstalować zbiorczą aktualizację 3 programu SQL Server 2012 z dodatkiem Service Pack 1 (11.0.3349), ponieważ zawiera ona poprawkę dla jednego określonego Problem, który faktycznie napotkałeś, w rzeczywistości otrzymywałbyś wszystkie poprawki dla SP1 CU1, SP1 CU2 i SP1 CU3, co oznaczałoby ponad 100 poprawek.
Jak stwierdza firma Microsoft na temat aktualizacji zbiorczych:„Ponieważ kompilacje kumulują się, każda nowa wersja poprawki zawiera wszystkie poprawki i wszystkie poprawki zabezpieczeń, które zostały uwzględnione w poprzedniej wersji poprawki SQL Server 2012 SP1. Zalecamy rozważenie zastosowania najnowszej wersji poprawki, która zawiera tę poprawkę”. Zasadniczo oznacza to, że jeśli zauważysz konkretny, istotny problem, który został naprawiony we wcześniejszej CU, powinieneś kontynuować i wdrożyć najnowszą odpowiednią CU w systemie (która będzie zawierała również tę poprawkę).
Jednym z argumentów, które często słyszę o tym, dlaczego organizacje nie wdrażają aktualizacji zbiorczych, jest to, że „nie są one w pełni testowane pod kątem regresji, jak dodatki Service Pack, więc ich nie wdrażamy”. Z tego punktu widzenia jest pewna słuszność, ale istnieje również powszechne błędne przekonanie, że aktualizacje zbiorcze są testowane tylko jednostkowo, bez jakichkolwiek testów regresji. Tak nie jest.
Dokumentacja firmy Microsoft dotycząca aktualizacji zbiorczych wskazuje, że ponieważ „stosują one przyrostowe testy regresji w całym cyklu rozwoju, po których następują 2 tygodnie ukierunkowanych testów w ramach 8-tygodniowego okna wydania, procesy zapewniania jakości związane z CU przewyższają procesy w przypadku poszczególnych poprawek”. Oznacza to, że w rzeczywistości podejmujesz mniejsze ryzyko, wdrażając jednostkę CU, która została poddana stopniowemu testowaniu regresji i miała również dwa tygodnie ukierunkowanych testów, niż gdybyś miał wdrożyć pojedynczą poprawkę, która została przetestowana tylko jednostkowo.
W ciągu ostatnich sześciu do siedmiu lat osobiście wdrożyłem wiele, wiele aktualizacji zbiorczych i dodatków Service Pack na dużej liczbie systemów z systemem SQL Server 2005 do SQL Server 2012 i nie napotkałem jeszcze żadnych poważnych problemów. Nie słyszałem również o żadnych powszechnych problemach związanych z tego typu pracą, które były zgłaszane na blogach, na Twitterze itp. Możliwe, że ja (i wszyscy, których znam) po prostu miałem szczęście, a może Aktualizacje zbiorcze i dodatki Service Pack nie są do końca tak ryzykowne, jak niektórzy sądzą (o ile odpowiednio je przetestujesz i wdrożysz).
Znaczenie planu testów i implementacji
O ile nigdy nie planujesz wykonywania jakiejkolwiek konserwacji serwera lub aktualizacji aplikacji przez cały okres użytkowania systemu (co wydaje się mało prawdopodobną propozycją), naprawdę musisz opracować jakąś procedurę testowania i implementacji oraz plan, którego będziesz przestrzegać jako część dokonywania jakichkolwiek zmian na serwerze.
Ten plan może zacząć się stosunkowo prosto, ale stanie się bardziej złożony i kompletny w miarę nabywania doświadczenia w regularnym serwisowaniu wystąpień programu SQL Server i stosowania wyciągniętych wniosków przy każdym wdrożeniu. Najlepiej byłoby postępować zgodnie z tym planem za każdym razem, gdy wprowadzasz zmiany w systemie, ale może to nie być możliwe w każdym przypadku.
Oto kilka wstępnych kroków i testów, które należy uwzględnić w tego rodzaju planie.
- Zainstaluj CU na testowej maszynie wirtualnej
- Czy CU instaluje się bez żadnych problemów lub błędów?
- Czy instalacja CU wymaga ponownego uruchomienia systemu?
- Czy wszystkie odpowiednie usługi SQL Server uruchamiają się ponownie po instalacji?
- Czy SQL Server wydaje się działać poprawnie po instalacji?
- Zainstaluj CU na kilku systemach programistycznych
- Czy CU instaluje się bez żadnych problemów lub błędów?
- Czy SQL Server wydaje się działać poprawnie podczas normalnego codziennego użytkowania?
- Czy Twoje aplikacje działają poprawnie podczas testów jednostkowych?
- Zainstaluj CU we wspólnym środowisku kontroli jakości lub integracji
- Czy postępowałeś zgodnie z konkretnym planem wdrożenia i listą kontrolną instalacji?
- Czy wszystkie aplikacje korzystające z SQL Server przechodzą testy dymu?
- Czy wszystkie aplikacje przechodzą jakiekolwiek automatyczne testy, które masz dostępne?
- Czy wszystkie aplikacje przechodzą bardziej szczegółowe ręczne testy funkcjonalne?
- Zainstaluj CU w swoim środowisku produkcyjnym
- W miarę możliwości stosuj strategię stopniowego uaktualniania
- Użyj szczegółowej listy kontrolnej krok po kroku podczas wdrażania
- Zaktualizuj swoją listę kontrolną o pominięte elementy i wyciągnięte wnioski
Wniosek
To, co mam nadzieję osiągnąć, to sprawić, by więcej specjalistów od baz danych zaczęło dążyć do nastawienia, w którym faktycznie chcą regularnie utrzymywać swoje instancje SQL Server, zamiast wahać się lub bać się tego robić. Na początku może to wiązać się ze znaczną ilością dodatkowej pracy, ponieważ być może będziesz musiał przekonać inne osoby w Twojej organizacji, aby przystąpiły do realizacji Twoich planów. Być może będziesz musiał naciskać na inne części organizacji, aby opracować lepsze plany testów, i będziesz musiał zbudować listę kontrolną wdrożenia. Będziesz także musiał uzyskać autoryzację firmy na okresy konserwacji (które powinny być stosunkowo krótkie w przypadku uaktualnień stopniowych), dzięki czemu będziesz mógł regularnie otrzymywać aktualizacje w swoich systemach produkcyjnych.
W zamian za tę dodatkową pracę będziesz mieć lepiej utrzymany system, który jest mniej podatny na problemy w przyszłości. Będziesz korzystać z w pełni obsługiwanej konfiguracji firmy Microsoft i będziesz mieć większe zaufanie do swoich technologii wysokiej dostępności, ponieważ będziesz z nich faktycznie korzystać regularnie. Zdobędziesz również cenne doświadczenie podczas planowania i wdrażania tego wszystkiego, co poprawi Twoje umiejętności rozwiązywania problemów w przyszłości.
