Er is enige controverse geweest in de SQL Server-gemeenschap over de wijsheid van het installeren van Service Packs (SP) en Cumulatieve Updates (CU) voor SQL Server. Er zijn verschillende basisposities die organisaties doorgaans over dit onderwerp innemen, zoals hieronder vermeld:
- De organisatie installeert regelmatig servicepacks en cumulatieve updates
- De organisatie installeert servicepacks, maar installeert geen cumulatieve updates
- De organisatie installeert geen servicepacks of cumulatieve updates
Het eerste geval is een organisatie die zal proberen redelijk actueel te blijven met zowel SQL Server Service Packs als SQL Server Cumulatieve Updates door middel van een grondige test- en implementatieprocedure. Dit is naar mijn mening het beste beleid. Mijn stelling is dat uw organisatie veel beter gediend is door up-to-date te blijven met zowel Service Packs als Cumulatieve Updates (zolang u beschikt over de test- en implementatieprocedures en de vereiste infrastructuur om dat beleid te ondersteunen).
Het tweede geval is een organisatie die (misschien met enige vertraging) SQL Server Service Packs zal installeren, maar om welke reden dan ook geen SQL Server Cumulatieve Updates zal installeren. Dit is niet zo goed als het eerste geval, maar veel beter dan het derde geval.
In het derde geval installeren sommige organisaties nooit SQL Server Service Packs of SQL Server Cumulatieve Updates, om welke reden dan ook. In sommige gevallen blijven ze gedurende de hele levensduur van de instantie op de oorspronkelijke release to manufacturing (RTM) build van de hoofdversie van SQL Server die ze gebruiken. Dit is om een aantal redenen het minst wenselijke beleid.
Microsoft heeft een beleid waarbij codevertakkingen (ofwel de RTM-tak of een volgende Service Pack-tak) voor een bepaalde versie van SQL Server buiten gebruik worden gesteld wanneer deze twee takken oud is. Toen SQL Server 2008 R2 Service Pack 2 bijvoorbeeld werd uitgebracht, werd de oorspronkelijke RTM-tak (ongeacht het CU-niveau) buiten gebruik gesteld en werd het een "niet-ondersteund servicepack". Dit betekent dat er geen hotfixes of cumulatieve updates meer zullen zijn voor die branch, en dat u slechts beperkte ondersteuning voor probleemoplossing krijgt van Microsoft CSS tijdens een supportcase totdat u een ondersteund servicepack op uw instance installeert.
Redenen waarom het onderhoud van SQL Server wordt uitgesteld
In sommige gevallen weet een organisatie misschien niet hoe SQL Server normaal gesproken wordt onderhouden met een combinatie van Service Packs, Cumulatieve Updates en Hotfixes. Veel organisaties hebben een rigide top-downbeleid voor het onderhouden en onderhouden van producten zoals SQL Server, die de regelmatige installatie van SP's en/of CU's door databasebeheerders uitsluiten. Ze kunnen ook worden beperkt in het onderhoud van hun SQL Server-instanties door het feit dat ze databases van derden gebruiken die alleen door de leverancier worden ondersteund met bepaalde door de leverancier gespecificeerde versie en Service Pack-niveaus van SQL Server.
Veel organisaties hebben ook een begrijpelijke angst om een SQL Server-instantie of een applicatie die van die instantie afhankelijk is, te 'breken'. Het kan ook zijn dat ze niet de tijd en middelen hebben om een geschikt niveau van applicatie- en systeemtests uit te voeren na het installeren van een bijgewerkte SQL Server-build op een exemplaar in een testomgeving. In sommige gevallen hebben ze misschien geen speciale testomgeving (wat een apart, groot probleem is).
Sommige organisaties hebben mogelijk geen werkende high-availability-oplossing (zoals traditionele failover-clustering, database-mirroring of beschikbaarheidsgroepen) in hun productieomgeving, dus zijn ze veel terughoudender om elk type onderhoud uit te voeren dat mogelijk een databaseserver opnieuw opstarten en een relatief lange storing veroorzaken. Ze hebben misschien wel een oplossing met hoge beschikbaarheid, maar testen deze zelden met een productie-failover, en ze hebben mogelijk minder vertrouwen in de werking en betrouwbaarheid ervan.
Redenen om regelmatig SQL Server te onderhouden
Na een opsomming van enkele veelvoorkomende redenen waarom organisaties ervoor kiezen om SQL Server niet regelmatig te onderhouden, is het tijd om enkele van deze argumenten aan te pakken. Ten eerste is onwetendheid over hoe SQL Server normaal gesproken wordt onderhouden door Microsoft niet echt een geldig excuus meer. Microsoft heeft een blog over SQL Release Services, waar ze zowel Service Packs als Cumulatieve Updates voor SQL Server aankondigen. Matthias Bernt legde de algemene servicestrategie voor SQL Server uit in zijn post:Een gewijzigde benadering van servicepacks, met meer details over de incrementele servicemodelbenadering van SQL Server die beschikbaar zijn in dit Micosoft Knowledge Base-artikel.
De verkorte versie van het servicemodel is dat individuele SQL Server-problemen worden gecorrigeerd met hotfixes. U moet contact opnemen met Microsoft CSS en een ondersteuningsaanvraag openen om toegang te krijgen tot een individuele hotfix (tenzij het een beveiligingsgerelateerde hotfix is, die door Microsoft Update wordt gepusht). Afhankelijk van uw niveau van betaalde ondersteuning bij Microsoft, kan dit een relatief vervelend en tijdrovend proces zijn. Er is ook het probleem dat de meeste SQL Server-klanten waarschijnlijk niet eens op de hoogte zijn van bestaande hotfixes die niet zijn uitgebracht als onderdeel van een cumulatieve SQL Server-update. Dit betekent dat de meeste klanten waarschijnlijk niet regelmatig individuele hotfixes zullen verkrijgen en implementeren.
Cumulatieve updates zijn updatepakketten van een aantal hotfixes (meestal zo'n 10-50 hotfixes) die elke acht weken worden uitgebracht. Deze cumulatieve updates zijn eigenlijk cumulatief (zoals de naam al aangeeft), dus u krijgt alle eerder uitgebrachte hotfixes voor uw versie en branch (RTM, SP1, SP2, enz.) van de code wanneer u een cumulatieve update installeert. Dit betekent dat de algemene uitspraak over organisaties "alleen cumulatieve updates toepassen om specifieke problemen die ze ervaren te corrigeren" in het echte leven niet echt geldig is.
Als u bijvoorbeeld de RTM-build van SQL Server 2012 Service Pack 1 (11.0.3000) uitvoert en u hebt besloten om SQL Server 2012 Service Pack 1 cumulatieve update 3 (11.0.3349) te installeren omdat deze een hotfix bevat voor een specifieke probleem dat u daadwerkelijk tegenkwam, zou u eigenlijk alle hotfixes voor SP1 CU1, SP1 CU2 en SP1 CU3 krijgen, wat neerkomt op meer dan 100 hotfixes.
Zoals Microsoft zegt over cumulatieve updates:"Omdat de builds cumulatief zijn, bevat elke nieuwe fixrelease alle hotfixes en alle beveiligingsfixes die bij de vorige fixrelease van SQL Server 2012 SP 1 waren inbegrepen. We raden u aan om de meest recente fix-release toe te passen die deze hotfix bevat." Dit betekent in feite dat als u een bepaald relevant probleem opmerkt dat in een eerdere CU is opgelost, u door moet gaan en de nieuwste relevante CU op het systeem moet implementeren (waaronder ook die hotfix).
Een argument dat ik vaak hoor over waarom organisaties geen cumulatieve updates implementeren, is dat "ze niet volledig op regressie zijn getest zoals servicepacks, dus we implementeren ze niet." Er is enige validiteit in dit gezichtspunt, maar er is ook een algemene misvatting dat cumulatieve updates slechts unit-getest zijn, zonder enige regressietest. Dit is niet het geval.
Microsoft-documentatie over cumulatieve updates geeft aan dat, aangezien ze "incrementele regressietests toepassen gedurende de ontwikkelingscyclus gevolgd door 2 weken gerichte testen binnen de releaseperiode van 8 weken, de kwaliteitsborgingsprocessen die zijn gekoppeld aan CU's die van individuele hotfixes overtreffen." Dit betekent dat u in feite minder risico neemt door een CU te implementeren die incrementeel op regressie is getest en die ook twee weken gerichte tests heeft ondergaan, dan wanneer u een enkele hotfix zou implementeren die alleen per eenheid is getest.
In de afgelopen zes tot zeven jaar heb ik persoonlijk vele, vele cumulatieve updates en servicepacks geïmplementeerd op een groot aantal systemen met SQL Server 2005 tot en met SQL Server 2012, en ik ben nog geen grote problemen tegengekomen. Ik heb ook niet gehoord van wijdverbreide problemen met dit soort werk die worden gerapporteerd in blogs, op Twitter, enz. Het kan zijn dat ik (en iedereen die ik ken) gewoon geluk heb gehad, of misschien zijn cumulatieve updates en servicepacks niet helemaal zo riskant als sommige mensen denken (zolang je ze maar goed test en implementeert).
Het belang van een test- en implementatieplan
Tenzij u nooit van plan bent enige vorm van serveronderhoud of applicatie-updates uit te voeren voor de levensduur van uw systeem (wat een onwaarschijnlijk voorstel lijkt), moet u echt een soort test- en implementatieprocedure en een plan ontwikkelen dat u als onderdeel zou volgen om enige wijziging aan de server aan te brengen.
Dit plan kan relatief eenvoudig beginnen, maar het zal complexer en completer worden naarmate u meer ervaring krijgt met het regelmatig onderhouden van uw SQL Server-instanties en de lessen toepast die u bij elke implementatie leert. Idealiter zou u dit plan altijd volgen wanneer u een wijziging aan het systeem aanbrengt, maar dat is misschien niet in alle gevallen mogelijk.
Hier zijn een paar eerste stappen en tests die in dit soort plannen moeten worden opgenomen.
- Installeer de CU op een virtuele testmachine
- Installeert de CU zonder problemen of fouten?
- Vereist de CU-installatie een herstart van het systeem?
- Herstarten alle relevante SQL Server-services opnieuw na de installatie?
- Lijkt SQL Server correct te werken na de installatie?
- Installeer de CU op verschillende ontwikkelsystemen
- Installeert de CU zonder problemen of fouten?
- Lijkt SQL Server correct te werken tijdens normaal dagelijks gebruik?
- Lijken uw applicaties correct te werken tijdens het testen van eenheden?
- Installeer de CU in een gedeelde QA- of integratieomgeving
- Heb je een specifiek implementatieplan en checklist gevolgd voor de installatie?
- Kunnen alle applicaties die SQL Server gebruiken de rooktesten doorstaan?
- Kunnen alle toepassingen alle geautomatiseerde tests doorstaan die u beschikbaar heeft?
- Kunnen alle applicaties meer gedetailleerde handmatige functionele tests doorstaan?
- Installeer de CU in uw productieomgeving
- Gebruik waar mogelijk een voortschrijdende upgradestrategie
- Gebruik een gedetailleerde, stapsgewijze checklist tijdens de implementatie
- Update je checklist met gemiste items en geleerde lessen
Conclusie
Wat ik hier hoop te bereiken, is om meer databaseprofessionals ertoe aan te zetten zich in de richting van een mentaliteit te bewegen waarin ze hun SQL Server-instanties eigenlijk regelmatig willen onderhouden, in plaats van aarzelend of bang te zijn om het te doen. Dit kan in het begin behoorlijk wat extra werk met zich meebrengen, omdat u misschien andere mensen in uw organisatie moet overtuigen om met uw plannen mee te doen. Het kan zijn dat u andere delen van de organisatie moet pushen om betere testplannen te ontwikkelen, en u zult een implementatiechecklist moeten maken. U zult ook autorisatie van het bedrijf moeten krijgen voor onderhoudsvensters (die relatief kort zouden moeten zijn bij voortschrijdende upgrades), zodat u op regelmatige basis updates op uw productiesystemen kunt laten implementeren.
In ruil voor dit extra werk heb je een beter onderhouden systeem dat in de toekomst minder snel in de problemen komt. U bevindt zich in een volledig ondersteunde configuratie van Microsoft en u zult meer vertrouwen hebben in uw high-availability technologie(s), aangezien u deze regelmatig zult oefenen. Je zult ook waardevolle ervaring opdoen bij het plannen en implementeren van dit alles, wat je vaardigheden voor probleemoplossing in de toekomst zal verbeteren.