Zbiorcze aktualizacje MS SQL Server - najlepsze praktyki

Próbuję dowiedzieć się, jakie zalecane najlepsze praktyki są dla zbiorczych aktualizacji programu SQL Server .

Obecnie przyświeca nam idea „nic nie rób, chyba że napotkamy problem rozwiązany przez CU”. Działa to z podejściem „jeśli to nie jest zepsute, nie naprawiaj”, ale zastanawiam się, czy to naprawdę dobry pomysł, ponieważ tak wiele CU ma ulepszenia wydajności. Rozważamy być może dodanie CU do łatek zastosowanych podczas naszych okresowych cykli konserwacji miesiąc lub dwa po wydaniu CU.

Co robią inni i dlaczego?

Jako aktualizację pytania, które ma wpływ na poniższe odpowiedzi, 24 marca 2016 r. Zespół Microsoft SQL Server ogłosił, że aktualizuje swój model obsługi . Microsoft zaleca wszystkim użytkownikom zainstalowanie wszystkich jednostek wydanych po styczniu 2016 r .:

W styczniowych wydaniach CU te ostrzeżenia zostały zaktualizowane, teraz zalecamy ciągłą, proaktywną instalację CU w miarę ich udostępniania. Powinieneś planować instalację CU z takim samym poziomem ufności, jak planujesz instalować SP (Service Packs) w momencie ich wydania. Wynika to z faktu, że jednostki certyfikacji są certyfikowane i testowane na poziomie SP. Ponadto dane Microsoft CSS wskazują, że znaczny procent problemów klientów jest często wcześniej rozwiązany w wydanym CU, ale nie jest stosowany proaktywnie. Co więcej, CU zawierają wartość dodaną ponad poprawkami. Mogą one również zawierać aktualizacje dotyczące obsługi, rejestrowania i niezawodności zwiększające ogólne wrażenia.

Oprócz aktualizacji komunikatów i wskazówek wprowadziliśmy aktualizacje modelu akwizycji CU.

Zmiany w akwizycji:

• CU oczywiście były tradycyjnie udostępniane na serwerze „Poprawka” (wraz z „językiem ostrzegawczym” związanym z „QFE” lub „Poprawka”). Niespójność polega na tym, że jednostki CU nie są już tak naprawdę szybkimi poprawkami. Objęte aktualizacje są dziś dobrze testowane na poziomie integracji indywidualnej, jak i pełnej.
• Dlatego umieszczamy teraz najnowszą jednostkę CU dla obsługiwanego głównego nurtu linii bazowej (dziś SP2 / SP3 2012 i RTM / SP1 2014) na microsoft.com/downloads, podobnie jak dzisiaj w przypadku dodatków Service Pack
• Ponadto wkrótce wydamy i utrzymamy wszystkie jednostki CU w katalogu Windows Update, aby ułatwić pozyskiwanie i dystrybucję
• Tylko przejściowe poprawki CU „na żądanie” zostaną umieszczone na serwerze poprawek, przesuwając się do przodu
• Aby zmniejszyć tarcie, pobieranie CU z microsoft.com/downloads nie będzie wymagało podania / otrzymania wiadomości e-mail i adresu URL
• Rozważamy również zaoferowanie najnowszej CU jako Opcjonalnej aktualizacji w witrynie Microsoft Update, podobnie jak w przypadku dzisiejszych dodatków Service Pack

Jestem wielkim zwolennikiem nadążania za najnowszą aktualizacją zbiorczą, ale tylko wtedy, gdy cykl testowania / kontroli jakości może zapewnić pełne i prawidłowe testy regresji w stosunku do niej. Glenn Berry z SQLskills jest również zwolennikiem tego podejścia .

Zaleceniem firmy Microsoft jest stosowanie tylko jednostek CU, które naprawiają problemy, które dotyczą ciebie, chociaż ostatnio poluzowały to stanowisko . Problem polega na tym, że może mieć na Ciebie wpływ jeden lub więcej z tych problemów i nie wiesz o tym, lub może to dotyczyć jutro, nawet jeśli jeszcze cię to nie dotknęło. Czy zamierzasz przejść przez ten problem i spróbować odtworzyć problem związany z każdą poprawką w każdej jednostce CU dla Twojego oddziału? Czy zamierzasz to robić w sposób ciągły, aby upewnić się, że nadal nie ma to wpływu?

Będę szczery: nigdy nie miałem problemu ze stosowaniem CU w moich instancjach. W rzeczywistości ich proces wydawania CU był o wiele bardziej niezawodny niż cykl wydawania dodatku Service Pack, aw wielu przypadkach (w tym ostatnio z SQL Server 2012 Service Pack 2 ), nie chcesz stosować dodatku Service Pack do pierwszego CU dla tego oddziału i tak zostało wydane. W takim przypadku istnieje tymczasowa poprawka rozwiązująca problem, który nie został naprawiony na czas, aby utworzyć kod dodatku Service Pack, ale nie zawsze jest to prawda.

Zawsze nadążaliśmy za CU. Około 1 miesiąc po wydaniu zastosowalibyśmy je niezależnie od tego, czy napotkamy problem przez nich naprawiony, czy nie.

Jednak po napotkaniu ogromnego problemu przestaliśmy tę praktykę. W naszym przypadku zainstalowany dodatek Service Pack naprawił problem z napotkanym indeksowaniem pełnotekstowym. Kilka miesięcy później jeden z CU wycofał tę konkretną poprawkę. Spowodowało to dla nas wiele problemów, które wymagały sporo badań, aby dowiedzieć się, co się stało. Zakończyliśmy kodowanie pracy, która później została zepsuta, gdy nowy CU złamał coś innego ... Wynik netto: serwer został ponownie zainstalowany od podstaw do określonego poziomu SP / CU i zamrożony.

Nasza wydajność aplikacji jest taka, że ​​nie jesteśmy zainteresowani żadnymi nowymi poprawkami wydajności SQL, które mogłyby się pojawić, więc nie stanowi to problemu. Ponadto raporty i inne zapytania konsekwentnie wycofują prawidłowe wyniki, więc wszelkie nowe poprawki są niepotrzebne. Co oznacza, że ​​musi to być kwestia bezpieczeństwa, zanim rozważymy zastosowanie CU w tym momencie.

Całkowicie zgadzam się z Aaronem: rób to tylko wtedy, gdy twój cykl testowania / kontroli jakości może go poprawnie przetestować. W przeciwnym razie powiedziałbym, żebyś był czysty, chyba że naprawi to problem, z którym się obecnie mierzysz. I nawet wtedy przetestuj każdy jego drobiazg z prawdziwymi danymi, aby upewnić się, że nie zepsuły czegoś, na czym możesz polegać.