Имаше известен спор в общността на SQL Server относно мъдростта на инсталирането на сервизни пакети (SP) и сборни актуализации (CU) за SQL Server. Има няколко различни основни позиции, които организациите обикновено са склонни да заемат по този въпрос, както е изброено по-долу:
- Организацията инсталира редовно сервизни пакети и сборни актуализации
- Организацията инсталира сервизни пакети, но не инсталира сборни актуализации
- Организацията не инсталира сервизни пакети или сборни актуализации
Първият случай е организация, която ще се опита да остане достатъчно актуална както със сервизните пакети на SQL Server, така и с кумулативните актуализации на SQL Server, използвайки задълбочено тестване и процедура за внедряване. Това е най-добрата политика според мен. Моята позиция е, че вашата организация се обслужва много по-добре, като поддържате актуални както сервизни пакети, така и кумулативни актуализации (стига да имате процедурите за тестване и внедряване и необходимата инфраструктура, за да поддържате тази политика).
Вторият случай е организация, която (може би след известно забавяне) ще инсталира SQL Server Service Packs, но няма да инсталира сборни актуализации на SQL Server по някаква причина. Това не е толкова добро като първия случай, но е много по-добре от третия случай.
В третия случай някои организации никога не инсталират никакви сервизни пакети на SQL Server или сборни актуализации на SQL Server по каквато и да е причина. В някои случаи те всъщност остават на оригиналната версия за производство (RTM) на основната версия на SQL Server, която изпълняват, за целия живот на екземпляра. Това е най-малко желаната политика по редица причини.
Microsoft има политика за оттегляне на клонове на кода (или RTM клон, или последващ клон на Service Pack) за определена версия на SQL Server, когато е на два клона. Например, когато SQL Server 2008 R2 Service Pack 2 беше пуснат, оригиналният RTM клон (независимо от нивото на CU) беше оттеглен и той стана „неподдържан сервизен пакет“. Това означава, че няма да има повече спешни корекции или кумулативни актуализации за този клон и че ще получавате само ограничена поддръжка за отстраняване на неизправности от Microsoft CSS по време на дело за поддръжка, докато не инсталирате поддържан сервизен пакет на вашия екземпляр.
Причини, поради които поддръжката на SQL Server е отложена
В някои случаи една организация може да не е наясно как SQL Server обикновено се обслужва с комбинация от сервизни пакети, сборни актуализации и спешни корекции. Много организации имат строги политики отгоре надолу за това как поддържат и обслужват продукти като SQL Server, които изключват редовното инсталиране на SP и/или CU от администраторите на бази данни. Те могат също да бъдат ограничени от обслужването на своите екземпляри на SQL Server поради факта, че използват бази данни на трети страни, които се поддържат само от производителя с определени нива на версия и сервизен пакет на SQL Server.
Много организации също имат разбираем страх от „счупване“ или на екземпляр на SQL Server, или на приложение, което зависи от този екземпляр. Освен това може да им липсват време и ресурси, за да направят подходящо ниво на тестване на приложения и системи след инсталиране на актуализирана сборка на SQL Server върху екземпляр в тестова среда. В някои случаи може да нямат специална тестова среда (което е отделен, основен проблем).
Някои организации може да нямат работещо решение за висока наличност (като традиционно клъстериране при отказ, огледално копиране на база данни или групи за наличност) на място в тяхната производствена среда, така че са много по-колебливи да направят какъвто и да е вид обслужване, което евентуално ще причини рестартиране на сървъра на базата данни и причиняват относително дълъг прекъсване. Те може действително да разполагат с решение с висока достъпност, но рядко го тестват с производствен отказ и може да имат по-малко доверие във функционирането и надеждността му.
Причини за редовна поддръжка на SQL Server
След като изброихме някои от често срещаните причини, поради които организациите може да изберат да не обслужват редовно SQL Server, е време да разгледаме някои от тези аргументи. Първо, невежеството за това как SQL Server обикновено се обслужва от Microsoft вече не е валидно извинение. Microsoft има блог за услуги за издаване на SQL, където обявяват както сервизни пакети, така и сборни актуализации за SQL Server. Матиас Бернт обясни общата стратегия за обслужване на SQL Server в публикацията си:Променен подход към сервизните пакети, с повече подробности за подхода на модела за постепенно обслужване на SQL Server, наличен в тази статия от базата знания на Micosoft.
Съкратената версия на модела за обслужване е, че отделните проблеми със SQL Server се коригират с актуални корекции. Трябва да се свържете с Microsoft CSS и да отворите заявка за поддръжка, за да получите достъп до отделна актуална корекция (освен ако не е свързана със сигурността актуална корекция, която се изтласква от Microsoft Update). В зависимост от вашето ниво на платена поддръжка с Microsoft, това може да бъде сравнително досаден и отнемащ време процес. Съществува и проблемът, че повечето клиенти на SQL Server е малко вероятно дори да знаят за съществуващи спешни корекции, които не са били пуснати като част от сборна актуализация на SQL Server. Това означава, че е малко вероятно повечето клиенти да получават и внедряват редовно отделни спешни корекции.
Кумулативните актуализации са сборни пакети от редица актуални корекции (обикновено от около 10-50 актуални корекции), които се пускат на всеки осем седмици. Тези Кумулативни актуализации всъщност са кумулативни (както подсказва името), така че ще получите всички пуснати по-рано спешни корекции за вашата версия и клон (RTM, SP1, SP2 и т.н.) на кода, когато инсталирате Кумулативна актуализация. Това означава, че общото твърдение за организациите „прилагащи само кумулативни актуализации за коригиране на специфични проблеми, които изпитват“ всъщност не е особено валидно в реалния живот.
Например, ако сте изпълнявали RTM версията на SQL Server 2012 Service Pack 1 (11.0.3000) и сте решили да инсталирате SQL Server 2012 Service Pack 1 Кумулативна актуализация 3 (11.0.3349), защото включваше актуална корекция за една конкретна проблем, с който всъщност се сблъскахте, всъщност ще получите всички актуални корекции за SP1 CU1, SP1 CU2 и SP1 CU3, което би представлявало доста над 100 актуални корекции.
Както Microsoft заявява за кумулативните актуализации:„Тъй като компилациите са кумулативни, всяка нова версия на корекцията съдържа всички спешни корекции и всички корекции на сигурността, които бяха включени в предишната версия на корекция на SQL Server 2012 SP 1. Препоръчваме ви да обмислите прилагането на най-новата версия на корекция, която съдържа тази актуална корекция.” По принцип това означава, че ако забележите конкретен релевантен проблем, който е бил отстранен в по-ранен CU, трябва да продължите и да разположите най-новия релевантен CU в системата (която също ще включва тази актуална корекция).
Един аргумент, който често чувам за това защо организациите не внедряват кумулативни актуализации е, че „те не са напълно регресионно тествани, както са сервизните пакети, така че ние не ги внедряваме“. Има известна валидност от тази гледна точка, но също така има често срещано погрешно схващане, че кумулативните актуализации са просто тествани с единици, без каквото и да е регресионно тестване. Това не е така.
Документацията на Microsoft относно кумулативните актуализации показва, че тъй като те „прилагат инкрементално регресионно тестване през целия цикъл на разработка, последвано от 2 седмици фокусирано тестване в рамките на 8-седмичния прозорец за пускане, процесите за осигуряване на качество, свързани с CU, надвишават тези на отделните спешни корекции“. Това означава, че всъщност поемате по-малък риск, като внедрите CU, който е бил постепенно тестван за регресия и също така е имал две седмици фокусирано тестване, отколкото ако внедрите една актуална корекция, която е тествана само на модул.
През последните шест до седем години аз лично внедрих много, много кумулативни актуализации и сервизни пакети на голям брой системи, работещи от SQL Server 2005 до SQL Server 2012, и все още не съм срещал сериозни проблеми. Също така не съм чувал за широко разпространени проблеми при извършване на този тип работа, които се съобщават в блогове, в Twitter и т.н. Може да се окаже, че аз (и всички, които познавам) просто съм имал късмет или може би кумулативните актуализации и сервизните пакети не са съвсем толкова рисковано, колкото някои хора смятат (стига да ги тествате и разгръщате правилно).
Значението на плана за тестване и внедряване
Освен ако никога не планирате да извършвате каквато и да е поддръжка на сървъра или актуализации на приложения през целия живот на вашата система (което изглежда малко вероятно предложение), наистина трябва да разработите някаква процедура за тестване и внедряване и план, който бихте следвали като част за извършване на каквато и да е промяна в сървъра.
Този план може да започне сравнително просто, но ще стане по-сложен и завършен, когато станете по-опитни с редовното обслужване на вашите SQL Server инстанции и прилагате уроците, които научавате при всяко внедряване. В идеалния случай бихте следвали този план всеки път, когато правите промяна в системата, но това може да не е възможно във всеки отделен случай.
Ето няколко начални стъпки и тестове, които трябва да бъдат включени в този вид план.
- Инсталирайте CU на тестова виртуална машина
- CU се инсталира ли без проблеми или грешки?
- Инсталацията на CU изисква ли рестартиране на системата?
- Всички съответни услуги на SQL Server рестартират ли се след инсталирането?
- Изглежда ли, че SQL Server работи правилно след инсталирането?
- Инсталирайте CU на няколко системи за разработка
- CU се инсталира ли без проблеми или грешки?
- Изглежда ли, че SQL Server работи правилно при нормална ежедневна употреба?
- Изглежда ли, че вашите приложения работят правилно по време на тестване на модул?
- Инсталирайте CU в споделена среда за качество или интеграция
- Спазвахте ли конкретен план за изпълнение и контролен списък за инсталацията?
- Всички приложения, които използват SQL Server, преминават ли тестове за дим?
- Всички приложения преминават ли някакво автоматизирано тестване, с което разполагате?
- Всички приложения преминават ли по-подробно ръчно функционално тестване?
- Инсталирайте CU във вашата производствена среда
- Използвайте стратегия за непрекъснато надграждане, където е възможно
- Използвайте подробен, стъпка по стъпка контролен списък по време на внедряването
- Актуализирайте контролния си списък с пропуснати елементи и научени уроци
Заключение
Това, което се надявам да постигна тук, е да накарам повече професионалисти в базата данни да започнат да се движат към мислене, при което всъщност искат редовно да поддържат своите копия на SQL Server, вместо да се колебаят или страхуват да го правят. Това може да включва значително количество допълнителна работа в началото, тъй като може да се наложи да убедите други хора във вашата организация да се присъединят към вашите планове. Може да се наложи да накарате други части на организацията да разработят по-добри планове за тестване и ще трябва да изградите контролен списък за изпълнение. Ще трябва също така да получите разрешение от бизнеса за прозорци за поддръжка (които трябва да са сравнително кратки при непрекъснати надстройки), така че всъщност можете да получавате актуализации, внедрени на вашите производствени системи редовно.
В замяна на тази допълнителна работа ще имате по-добре поддържана система, която е по-малко вероятно да срещнете проблеми в бъдеще. Ще бъдете в напълно поддържана конфигурация от Microsoft и ще имате повече доверие във вашите технологии с висока наличност, тъй като всъщност ще ги упражнявате редовно. Освен това ще придобиете ценен опит, докато правите планирането и изпълнението на всичко това, което ще подобри уменията ви за отстраняване на неизправности в бъдеще.
