Det har förekommit en del pågående kontroverser i SQL Server-gemenskapen om klokheten i att installera Service Pack (SP) och kumulativa uppdateringar (CU) för SQL Server. Det finns flera olika grundläggande ståndpunkter som organisationer vanligtvis tenderar att inta i detta ämne, enligt listan nedan:
- Organisationen installerar Service Pack och kumulativa uppdateringar regelbundet
- Organisationen installerar Service Pack, men installerar inte kumulativa uppdateringar
- Organisationen installerar inte Service Pack eller kumulativa uppdateringar
Det första fallet är en organisation som kommer att försöka hålla sig någorlunda uppdaterad med både SQL Server Service Packs och SQL Server Kumulativa uppdateringar med hjälp av en noggrann test- och implementeringsprocedur. Detta är den bästa politiken enligt min mening. Min ståndpunkt är att din organisation är mycket bättre betjänt av att hålla dig uppdaterad med både Service Pack och kumulativa uppdateringar (så länge du har testnings- och implementeringsprocedurerna och den nödvändiga infrastrukturen på plats för att stödja den policyn).
Det andra fallet är en organisation som (kanske efter en viss fördröjning) kommer att installera SQL Server Service Packs, men de kommer inte att installera SQL Server Cumulative Updates av någon anledning. Detta är inte lika bra som det första fallet, men är mycket bättre än det tredje fallet.
I det tredje fallet installerar vissa organisationer aldrig några SQL Server Service Packs eller SQL Server Cumulative Updates, av någon anledning. I vissa fall stannar de faktiskt kvar på den ursprungliga versionen till tillverkning (RTM) av huvudversionen av SQL Server som de kör, under instansens livstid. Detta är den minst önskvärda policyn, av ett antal skäl.
Microsoft har en policy att ta bort kodgrenar (antingen RTM-grenen eller en efterföljande Service Pack-gren) för en viss version av SQL Server när den är två grenar gammal. Till exempel, när SQL Server 2008 R2 Service Pack 2 släpptes, togs den ursprungliga RTM-grenen (oavsett CU-nivå) tillbaka, och det blev ett "unsupported service pack". Det betyder att det inte kommer att finnas fler snabbkorrigeringar eller kumulativa uppdateringar för den grenen, och att du endast kommer att få begränsad felsökningssupport från Microsoft CSS under ett supportärende tills du installerar ett servicepack som stöds på din instans.
Skäl till att underhåll av SQL Server skjuts upp
I vissa fall kanske en organisation inte är medveten om hur SQL Server normalt betjänas med en kombination av Service Pack, kumulativa uppdateringar och snabbkorrigeringar. Många organisationer har stela, uppifrån-och-ned-policyer på plats om hur de underhåller och servar produkter som SQL Server, som utesluter regelbunden installation av SP:er och/eller CU:er av databasadministratörer. De kan också vara begränsade från att betjäna sina SQL Server-instanser av det faktum att de använder tredjepartsdatabaser som endast stöds av leverantörer med vissa leverantörsspecificerade versioner och Service Pack-nivåer av SQL Server.
Många organisationer har också en förståelig rädsla för att "bryta" antingen en SQL Server-instans eller en applikation som beror på den instansen. De kan också sakna tid och resurser för att göra en lämplig nivå av applikations- och systemtestning efter att ha installerat en uppdaterad SQL Server-build på en instans i en testmiljö. I vissa fall kanske de inte har en dedikerad testmiljö (vilket är ett separat, stort problem).
Vissa organisationer kanske inte har en fungerande högtillgänglighetslösning (såsom traditionell fail-over-klustring, databasspegling eller tillgänglighetsgrupper) på plats i sin produktionsmiljö, så de är mycket mer tveksamma till att göra någon typ av service som kan orsaka en omstart av databasservern och orsaka ett relativt långt avbrott. De kanske faktiskt har en lösning med hög tillgänglighet på plats, men de testar den sällan med ett produktionsfel och de kan ha mindre förtroende för dess funktion och tillförlitlighet.
Skäl till att regelbundet underhålla SQL Server
Efter att ha listat några av de vanligaste anledningarna till att organisationer väljer att inte regelbundet betjäna SQL Server, är det dags att ta upp några av dessa argument. För det första är okunnighet om hur SQL Server normalt betjänas av Microsoft inte riktigt en giltig ursäkt längre. Microsoft har en SQL Release Services-blogg, där de tillkännager både Service Pack och kumulativa uppdateringar för SQL Server. Matthias Bernt förklarade den allmänna servicestrategin för SQL Server i sitt inlägg:A changeed approach to Service Packs, med mer detaljer om SQL Server incremental service model approach tillgänglig i denna Micosoft kunskapsbasartikel.
Den komprimerade versionen av servicemodellen är att enskilda SQL Server-problem korrigeras med snabbkorrigeringar. Du måste kontakta Microsoft CSS och öppna ett supportärende för att få tillgång till en enskild snabbkorrigering (såvida det inte är en säkerhetsrelaterad snabbkorrigering, som skjuts ut av Microsoft Update). Beroende på din nivå av betald support med Microsoft kan detta vara en relativt tråkig och tidskrävande process. Det finns också problemet att de flesta SQL Server-kunder är mycket osannolikt att ens vara medvetna om befintliga snabbkorrigeringar som inte har släppts som en del av en SQL Server Cumulative Update. Detta innebär att de flesta kunder sannolikt inte kommer att skaffa och distribuera individuella snabbkorrigeringar på en regelbunden basis.
Kumulativa uppdateringar är samlingar av ett antal snabbkorrigeringar (vanligtvis allt från cirka 10-50 snabbkorrigeringar) som släpps var åttonde vecka. Dessa kumulativa uppdateringar är faktiskt kumulativa (som namnet antyder), så du kommer att få alla tidigare släppta snabbkorrigeringar för din version och gren (RTM, SP1, SP2, etc.) av koden när du installerar en kumulativ uppdatering. Detta betyder att det vanliga uttalandet om att organisationer "endast använder kumulativa uppdateringar för att korrigera specifika problem som de upplever" faktiskt inte är särskilt giltigt i verkligheten.
Till exempel, om du körde RTM-bygget av SQL Server 2012 Service Pack 1 (11.0.3000) och du bestämde dig för att installera SQL Server 2012 Service Pack 1 Cumulative Update 3 (11.0.3349) eftersom det inkluderade en snabbkorrigering för en specifik problem som du faktiskt stötte på, skulle du faktiskt få alla snabbkorrigeringar för SP1 CU1, SP1 CU2 och SP1 CU3, vilket skulle uppgå till långt över 100 snabbkorrigeringar.
Som Microsoft säger om kumulativa uppdateringar:"Eftersom byggen är kumulativa innehåller varje ny fixutgåva alla snabbkorrigeringar och alla säkerhetskorrigeringar som inkluderades i den tidigare SQL Server 2012 SP 1-fixutgåvan. Vi rekommenderar att du överväger att tillämpa den senaste korrigeringsversionen som innehåller den här snabbkorrigeringen." I grund och botten betyder detta att om du upptäcker ett visst, relevant problem som fixades i en tidigare CU, bör du gå vidare och distribuera den senaste relevanta CU på systemet (som även kommer att inkludera den snabbkorrigeringen).
Ett argument som jag ofta hör om varför organisationer inte distribuerar kumulativa uppdateringar är att "de är inte helt regressionstestade som Service Pack är, så vi distribuerar dem inte." Det finns en viss giltighet i denna synvinkel, men det finns också en vanlig missuppfattning att kumulativa uppdateringar bara är enhetstestade, utan någon som helst regressionstestning. Så är inte fallet.
Microsofts dokumentation om kumulativa uppdateringar indikerar att eftersom de "tillämpar inkrementell regressionstestning under hela utvecklingscykeln följt av 2 veckors fokuserad testning inom 8 veckors releasefönster, överstiger kvalitetssäkringsprocesserna förknippade med CU:er de för individuella snabbkorrigeringar." Detta innebär att du faktiskt tar mindre risk genom att distribuera en CU som har stegvis regressionstestats och som också har haft två veckors fokuserad testning än om du skulle distribuera en enstaka snabbkorrigering som bara har enhetstestats.
Under de senaste sex till sju åren har jag personligen distribuerat många, många kumulativa uppdateringar och servicepaket på ett stort antal system som kör SQL Server 2005 till och med SQL Server 2012, och jag har ännu inte stött på några större problem. Jag har inte heller hört talas om att några utbredda problem med den här typen av arbete har rapporterats i bloggar, på Twitter, etc. Det kan vara så att jag (och alla jag känner) bara har haft tur, eller så är kumulativa uppdateringar och servicepaket inte riktigt så riskabelt som vissa tror (så länge du testar och använder dem på rätt sätt).
Vikten av en test- och implementeringsplan
Såvida du inte planerar att göra någon form av serverunderhåll eller programuppdateringar under hela ditt system (vilket verkar vara ett osannolikt förslag), behöver du verkligen utveckla någon form av test- och implementeringsprocedur och plan som du skulle följa som en del att göra någon form av förändring på servern.
Den här planen kan börja relativt enkel, men den kommer att bli mer komplex och komplett när du blir mer erfaren med att regelbundet serva dina SQL Server-instanser och tillämpa de lärdomar du lär dig med varje distribution. Helst skulle du följa denna plan när du gör en förändring i systemet, men det kanske inte är möjligt i varje enskilt fall.
Här är några inledande steg och tester som bör inkluderas i den här typen av plan.
- Installera CU på en virtuell testmaskin
- Installeras CU utan några problem eller fel?
- Kräver CU-installationen en omstart av systemet?
- Startar alla relevanta SQL Server-tjänster om efter installationen?
- Tycker SQL Server fungera korrekt efter installationen?
- Installera CU på flera utvecklingssystem
- Installeras CU utan några problem eller fel?
- Fungerar SQL Server korrekt under normal daglig användning?
- Tycker dina applikationer fungera korrekt under enhetstestning?
- Installera CU i en delad QA- eller integrationsmiljö
- Följde du en specifik implementeringsplan och checklista för installationen?
- Står alla applikationer som använder SQL Server röktestning?
- Står alla applikationer några automatiska tester som du har tillgängliga?
- Står alla applikationer mer detaljerade manuella funktionstestningar?
- Installera CU i din produktionsmiljö
- Använd en rullande uppgraderingsstrategi där det är möjligt
- Använd en detaljerad, steg-för-steg checklista under implementeringen
- Uppdatera din checklista med missade objekt och lärdomar
Slutsats
Vad jag hoppas kunna åstadkomma här är att få fler databasproffs att börja röra sig mot ett tankesätt där de faktiskt vill underhålla sina SQL Server-instanser regelbundet, snarare än att vara tveksamma eller rädda för att göra det. Detta kan innebära en betydande mängd extraarbete i början, eftersom du kanske måste övertyga andra personer i din organisation att komma med på dina planer. Du kan behöva driva andra delar av organisationen för att utveckla bättre testplaner, och du kommer att behöva bygga en implementeringschecklista. Du måste också få tillstånd från företaget för underhållsfönster (som bör vara relativt korta med rullande uppgraderingar), så att du faktiskt kan få uppdateringar distribuerade på dina produktionssystem på en regelbunden basis.
I utbyte mot detta extraarbete får du ett bättre underhållet system som är mindre benägna att stöta på problem i framtiden. Du kommer att ha en fullt stödd konfiguration från Microsoft, och du kommer att ha mer förtroende för dina högtillgängliga teknologier, eftersom du faktiskt kommer att utöva dem regelbundet. Du kommer också att få värdefull erfarenhet när du planerar och implementerar allt detta som kommer att förbättra dina felsökningsfärdigheter i framtiden.