V komunitě SQL Serveru probíhá určitá kontroverze o moudrosti instalace aktualizací Service Pack (SP) a kumulativních aktualizací (CU) pro SQL Server. Existuje několik různých základních postojů, které organizace k tomuto tématu obvykle zaujímají, jak je uvedeno níže:
- Organizace pravidelně instaluje aktualizace Service Pack a Kumulativní aktualizace
- Organizace nainstaluje aktualizace Service Pack, ale nenainstaluje kumulativní aktualizace
- Organizace neinstaluje aktualizace Service Pack ani Kumulativní aktualizace
Prvním případem je organizace, která se bude snažit zůstat přiměřeně aktuální s aktualizacemi SQL Server Service Pack a kumulativními aktualizacemi SQL Server pomocí důkladného testování a implementace. To je podle mého názoru nejlepší politika. Můj postoj je, že vaší organizaci mnohem lépe poslouží, když budete mít aktuální aktualizace Service Pack i Kumulativní aktualizace (pokud máte testovací a implementační postupy a požadovanou infrastrukturu na podporu této politiky).
Druhým případem je organizace, která (možná po určité prodlevě) nainstaluje aktualizace SQL Server Service Pack, ale z jakéhokoli důvodu nenainstaluje kumulativní aktualizace SQL Server. Toto není tak dobré jako první případ, ale je mnohem lepší než třetí případ.
Ve třetím případě některé organizace nikdy neinstalují žádné aktualizace SQL Server Service Pack nebo kumulativní aktualizace SQL Server, a to z jakéhokoli důvodu. V některých případech ve skutečnosti zůstávají na původním sestavení pro výrobu (RTM) hlavní verze SQL Server, kterou používají, po dobu životnosti instance. Toto je nejméně žádoucí politika z mnoha důvodů.
Společnost Microsoft má politiku zrušení větví kódu (buď větve RTM nebo následné větve Service Pack) pro konkrétní verzi SQL Server, pokud jsou dvě větve staré. Když byl například vydán SQL Server 2008 R2 Service Pack 2, byla původní větev RTM (bez ohledu na úroveň CU) vyřazena a stala se „nepodporovanou aktualizací Service Pack“. To znamená, že pro danou větev nebudou k dispozici žádné další opravy hotfix ani kumulativní aktualizace a že během případu podpory získáte od Microsoft CSS pouze omezenou podporu při odstraňování problémů, dokud si do své instance nenainstalujete podporovaný balíček service pack.
Důvody, proč je údržba SQL Server odložena
V některých případech si organizace nemusí být vědoma toho, jak je SQL Server běžně obsluhován kombinací aktualizací Service Pack, kumulativních aktualizací a oprav Hotfix. Mnoho organizací má zavedené přísné, shora dolů zásady týkající se způsobu údržby a servisu produktů, jako je SQL Server, což znemožňuje pravidelnou instalaci SP a/nebo CU správci databází. Mohou jim být také omezeny služby jejich instancí SQL Server tím, že používají databáze třetích stran, které jsou podporovány pouze dodavatelem s určitými verzemi a úrovněmi aktualizace Service Pack SQL Serveru specifikovanými dodavatelem.
Mnoho organizací má také pochopitelný strach z „rozbití“ instance SQL Serveru nebo aplikace, která na této instanci závisí. Také jim může chybět čas a prostředky k provedení příslušné úrovně testování aplikací a systému po instalaci aktualizovaného SQL Server buildu na instanci v testovacím prostředí. V některých případech nemusí mít vyhrazené testovací prostředí (což je samostatný, hlavní problém).
Některé organizace nemusí mít ve svém produkčním prostředí funkční řešení s vysokou dostupností (jako je tradiční klastrování při selhání, zrcadlení databáze nebo skupiny dostupnosti), takže mnohem více váhají s jakýmkoli typem servisu, který by mohl způsobit restartování databázového serveru a způsobit relativně dlouhý výpadek. Ve skutečnosti mohou mít zavedené řešení s vysokou dostupností, ale jen zřídka je testují pomocí produkčního selhání a mohou mít menší důvěru v jeho fungování a spolehlivost.
Důvody, proč pravidelně udržovat SQL Server
Po výčtu některých běžných důvodů, proč se organizace mohou rozhodnout, že nebudou pravidelně servisovat SQL Server, je na čase zabývat se některými z těchto argumentů. Za prvé, nevědomost o tom, jak je SQL Server normálně obsluhován společností Microsoft, již není ve skutečnosti platnou omluvou. Microsoft má SQL Release Services Blog, kde oznamuje jak aktualizace Service Pack, tak kumulativní aktualizace pro SQL Server. Matthias Bernt vysvětlil obecnou servisní strategii pro SQL Server ve svém příspěvku:Změněný přístup k aktualizacím Service Pack, přičemž podrobnější informace o přístupu modelu inkrementálního servisu SQL Serveru jsou k dispozici v tomto článku znalostní báze společnosti Micosoft.
Zhuštěná verze modelu servisu spočívá v tom, že jednotlivé problémy se serverem SQL jsou opraveny pomocí oprav hotfix. Chcete-li získat přístup k jednotlivé opravě hotfix (pokud se nejedná o opravu hotfix související se zabezpečením, kterou vydává služba Microsoft Update), musíte kontaktovat Microsoft CSS a otevřít případ podpory. V závislosti na vaší úrovni placené podpory u společnosti Microsoft to může být poměrně zdlouhavý a časově náročný proces. Existuje také problém, že většina zákazníků SQL Server je velmi nepravděpodobné, že by si byli vědomi existujících oprav hotfix, které nebyly vydány jako součást kumulativní aktualizace SQL Server. To znamená, že většina zákazníků pravděpodobně nebude získávat a nasazovat jednotlivé opravy hotfix pravidelně.
Kumulativní aktualizace jsou souhrny řady oprav hotfix (obvykle kdekoli od 10 do 50 oprav hotfix), které jsou vydávány každých osm týdnů. Tyto kumulativní aktualizace jsou ve skutečnosti kumulativní (jak název napovídá), takže při instalaci kumulativní aktualizace získáte všechny dříve vydané opravy hotfix pro vaši verzi a větev (RTM, SP1, SP2 atd.) kódu. To znamená, že běžné prohlášení o organizacích, že „pouze kumulativní aktualizace používají k nápravě konkrétních problémů, se kterými se setkávají“, ve skutečnosti v reálném životě příliš neplatí.
Pokud jste například spouštěli RTM sestavení SQL Server 2012 Service Pack 1 (11.0.3000) a rozhodli jste se nainstalovat SQL Server 2012 Service Pack 1 kumulativní aktualizaci 3 (11.0.3349), protože obsahovala opravu hotfix pro jeden konkrétní problém, se kterým jste se ve skutečnosti setkali, ve skutečnosti byste dostávali všechny opravy hotfix pro SP1 CU1, SP1 CU2 a SP1 CU3, což by znamenalo více než 100 oprav hotfix.
Jak společnost Microsoft uvádí o kumulativních aktualizacích:„Protože jsou sestavení kumulativní, každé nové vydání opravy obsahuje všechny opravy hotfix a všechny opravy zabezpečení, které byly součástí předchozího vydání opravy SQL Server 2012 SP 1. Doporučujeme zvážit použití nejnovější verze opravy, která tuto opravu hotfix obsahuje.“ V zásadě to znamená, že pokud zaznamenáte konkrétní relevantní problém, který byl opraven v dřívější CU, měli byste pokračovat a nasadit nejnovější relevantní CU do systému (což bude také zahrnovat tuto opravu hotfix).
Jeden argument, který často slyším o tom, proč organizace nenasazují kumulativní aktualizace, je ten, že „nejsou plně regresně testovány jako aktualizace Service Pack, takže je nenasazujeme“. Z tohoto hlediska existuje určitá validita, ale existuje také běžná mylná představa, že kumulativní aktualizace jsou pouze testovány na jednotku, bez jakéhokoli regresního testování. Není tomu tak.
Dokumentace společnosti Microsoft o Kumulativních aktualizacích uvádí, že vzhledem k tomu, že „aplikují přírůstkové regresní testování v průběhu vývojového cyklu, po kterém následují 2 týdny cíleného testování v rámci 8týdenního okna vydání, procesy zajištění kvality spojené s CU převyšují procesy jednotlivých oprav hotfix“. To znamená, že ve skutečnosti podstupujete menší riziko nasazením CU, která byla postupně regresně testována a měla také dva týdny cíleného testování, než kdybyste nasadili jedinou opravu hotfix, která byla testována pouze na jednotku.
Během posledních šesti až sedmi let jsem osobně nasadil mnoho, mnoho kumulativních aktualizací a aktualizací Service Pack na velkém počtu systémů se systémem SQL Server 2005 až SQL Server 2012 a dosud jsem nenarazil na žádné větší problémy. Také jsem neslyšel o tom, že by na blozích, na Twitteru atd. byly hlášeny nějaké rozšířené problémy s tímto typem práce. Je možné, že jsem měl (a všichni, koho znám) právě štěstí, nebo možná nejsou kumulativní aktualizace a aktualizace Service Pack tak docela tak riskantní, jak si někteří lidé myslí (pokud je správně otestujete a nasadíte).
Význam plánu testování a implementace
Pokud nikdy neplánujete provádět jakoukoli údržbu serveru nebo aktualizace aplikací po dobu životnosti vašeho systému (což se zdá jako nepravděpodobný návrh), musíte skutečně vyvinout nějaký způsob testování a implementace a plán, který byste jako součást dodržovali. provádění jakýchkoli změn na serveru.
Tento plán může začít relativně jednoduše, ale bude složitější a kompletnější, až budete mít větší zkušenosti s pravidelným servisem instancí SQL Serveru a budete aplikovat lekce, které jste se naučili při každém nasazení. V ideálním případě byste se tímto plánem řídili při každé změně systému, ale to nemusí být možné v každém jednotlivém případě.
Zde je několik úvodních kroků a testů, které by měly být součástí tohoto druhu plánu.
- Nainstalujte CU na testovací virtuální počítač
- Instaluje se CU bez problémů nebo chyb?
- Vyžaduje instalace CU restart systému?
- Restartují se po instalaci všechny relevantní služby SQL Server?
- Zdá se, že SQL Server po instalaci funguje správně?
- Nainstalujte CU na několik vývojových systémů
- Instaluje se CU bez problémů nebo chyb?
- Zdá se, že SQL Server funguje správně při běžném každodenním používání?
- Zdá se, že vaše aplikace během testování jednotky fungují správně?
- Nainstalujte CU do sdíleného QA nebo integračního prostředí
- Postupovali jste podle konkrétního plánu implementace a kontrolního seznamu pro instalaci?
- Procházejí všechny aplikace, které používají SQL Server, testováním kouře?
- Procházejí všechny aplikace nějakým automatizovaným testováním, které máte k dispozici?
- Procházejí všechny aplikace podrobnějším ručním funkčním testováním?
- Nainstalujte CU do produkčního prostředí
- Pokud je to možné, použijte strategii průběžného upgradu
- Během nasazení použijte podrobný kontrolní seznam krok za krokem
- Aktualizujte svůj kontrolní seznam o zmeškané položky a získané poznatky
Závěr
Doufám, že zde dosáhnu toho, že přiměju více databázových profesionálů, aby se začali posouvat směrem k myšlení, kde skutečně chtějí pravidelně udržovat své instance SQL Serveru, než aby s tím váhali nebo se báli. Na začátku to může znamenat značné množství práce navíc, protože možná budete muset přesvědčit ostatní lidi ve vaší organizaci, aby se zapojili do vašich plánů. Možná budete muset přimět ostatní části organizace, aby vyvinuly lepší plány testování, a budete muset vytvořit kontrolní seznam implementace. Budete také muset získat povolení od firmy pro období údržby (která by měla být relativně krátká s postupnými upgrady), takže můžete skutečně pravidelně dostávat aktualizace nasazené na vaše produkční systémy.
Na oplátku za tuto práci navíc budete mít lépe udržovaný systém, u kterého je méně pravděpodobné, že se v budoucnu dostane do problémů. Budete v plně podporované konfiguraci od společnosti Microsoft a budete mít větší důvěru ve své technologie s vysokou dostupností, protože je budete skutečně pravidelně používat. Při plánování a implementaci toho všeho také získáte cenné zkušenosti, které v budoucnu zlepší vaše dovednosti při odstraňování problémů.