Der har været en del igangværende kontroverser i SQL Server-fællesskabet om det fornuftige i at installere Service Packs (SP) og Cumulative Updates (CU) til SQL Server. Der er flere forskellige grundlæggende holdninger, som organisationer typisk har en tendens til at indtage om dette emne, som angivet nedenfor:
- Organisationen installerer servicepakker og kumulative opdateringer regelmæssigt
- Organisationen installerer Service Packs, men installerer ikke kumulative opdateringer
- Organisationen installerer ikke servicepakker eller kumulative opdateringer
Det første tilfælde er en organisation, der vil forsøge at holde sig nogenlunde opdateret med både SQL Server Service Packs og SQL Server Cumulative Updates ved hjælp af en grundig test- og implementeringsprocedure. Dette er den bedste politik efter min mening. Min holdning er, at din organisation er meget bedre tjent med at holde sig ajour med både servicepakker og kumulative opdateringer (så længe du har test- og implementeringsprocedurerne og den nødvendige infrastruktur på plads til at understøtte denne politik).
Det andet tilfælde er en organisation, der (måske efter en vis forsinkelse) vil installere SQL Server Service Packs, men de vil ikke installere SQL Server kumulative opdateringer af nogen grund. Dette er ikke så godt som det første tilfælde, men er meget bedre end det tredje tilfælde.
I det tredje tilfælde installerer nogle organisationer aldrig nogen SQL Server Service Packs eller SQL Server Cumulative Updates, uanset årsagen. I nogle tilfælde forbliver de faktisk på den originale version til fremstilling (RTM) build af den større version af SQL Server, som de kører, i hele instansens levetid. Dette er den mindst ønskværdige politik af en række årsager.
Microsoft har en politik om at trække kodegrene tilbage (enten RTM-grenen eller en efterfølgende Service Pack-gren) for en bestemt version af SQL Server, når den er to filialer gammel. For eksempel, da SQL Server 2008 R2 Service Pack 2 blev frigivet, blev den originale RTM-gren (uanset CU-niveau) trukket tilbage, og den blev en "ikke-understøttet servicepakke". Det betyder, at der ikke vil være flere hotfixes eller kumulative opdateringer til den gren, og at du kun vil få begrænset fejlfindingssupport fra Microsoft CSS under en supportsag, indtil du installerer en understøttet service pack på din instans.
Årsager til, at SQL Server-vedligeholdelse udsættes
I nogle tilfælde er en organisation muligvis ikke klar over, hvordan SQL Server normalt betjenes med en kombination af Service Packs, Kumulative opdateringer og Hotfixes. Mange organisationer har stive, top-down-politikker på plads om, hvordan de vedligeholder og servicerer produkter som SQL Server, som udelukker regelmæssig installation af SP'er og/eller CU'er af databaseadministratorer. De kan også være begrænset til at betjene deres SQL Server-instanser af det faktum, at de bruger tredjepartsdatabaser, der kun er leverandørunderstøttet med visse leverandørspecificerede versioner og Service Pack-niveauer af SQL Server.
Mange organisationer har også en forståelig frygt for at "bryde" enten en SQL Server-instans eller en applikation, der afhænger af den instans. De mangler muligvis også tid og ressourcer til at udføre et passende niveau af applikations- og systemtestning efter installation af en opdateret SQL Server-build på en instans i et testmiljø. I nogle tilfælde har de muligvis ikke et dedikeret testmiljø (hvilket er et separat, stort problem).
Nogle organisationer har muligvis ikke en fungerende højtilgængelighedsløsning (såsom traditionel fail-over clustering, databasespejling eller tilgængelighedsgrupper) på plads i deres produktionsmiljø, så de er meget mere tøvende med at udføre enhver form for service, der muligvis vil forårsage en databaseserver genstarter og forårsager et relativt langt udfald. De kan faktisk have en løsning med høj tilgængelighed på plads, men de tester den sjældent med en produktionsfejl, og de kan have mindre tillid til dens funktion og pålidelighed.
Grunde til regelmæssig vedligeholdelse af SQL Server
Efter at have nævnt nogle af de almindelige årsager til, at organisationer måske vælger ikke at servicere SQL Server regelmæssigt, er det tid til at tage fat på nogle af disse argumenter. For det første er uvidenhed om, hvordan SQL Server normalt betjenes af Microsoft, ikke rigtig en gyldig undskyldning længere. Microsoft har en SQL Release Services Blog, hvor de annoncerer både servicepakker og kumulative opdateringer til SQL Server. Matthias Bernt forklarede den generelle servicestrategi for SQL Server i sit indlæg:En ændret tilgang til Service Packs, med flere detaljer om tilgangen til SQL Server inkrementel servicemodel, der er tilgængelig i denne Micosoft videnbaseartikel.
Den komprimerede version af servicemodellen er, at individuelle SQL Server-problemer rettes med hotfixes. Du skal kontakte Microsoft CSS og åbne en supportsag for at få adgang til et individuelt hotfix (medmindre det er et sikkerhedsrelateret hotfix, som skubbes ud af Microsoft Update). Afhængigt af dit niveau af betalt support hos Microsoft, kan dette være en relativt kedelig og tidskrævende proces. Der er også det problem, at det er meget usandsynligt, at de fleste SQL Server-kunder overhovedet er opmærksomme på eksisterende hotfixes, der ikke er blevet frigivet som en del af en SQL Server kumulativ opdatering. Dette betyder, at det er usandsynligt, at de fleste kunder får og implementerer individuelle hotfixes på en regelmæssig basis.
Kumulative opdateringer er samlinger af en række hotfixes (typisk alt fra omkring 10-50 hotfixes), der udgives hver ottende uge. Disse kumulative opdateringer er faktisk kumulative (som navnet antyder), så du får alle de tidligere udgivne hotfixes til din version og gren (RTM, SP1, SP2 osv.) af koden, når du installerer en kumulativ opdatering. Det betyder, at den almindelige erklæring om, at organisationer "kun anvender kumulative opdateringer til at rette specifikke problemer, som de oplever", faktisk ikke er særlig gyldig i det virkelige liv.
For eksempel, hvis du kørte RTM-builden af SQL Server 2012 Service Pack 1 (11.0.3000), og du besluttede at installere SQL Server 2012 Service Pack 1 Cumulative Update 3 (11.0.3349), fordi den indeholdt et hotfix til én specifik problem, som du rent faktisk stødte på, ville du faktisk få alle hotfixes til SP1 CU1, SP1 CU2 og SP1 CU3, hvilket ville svare til langt over 100 hotfixes.
Som Microsoft udtaler om kumulative opdateringer:"Fordi builds er kumulative, indeholder hver ny rettelsesudgivelse alle hotfixes og alle sikkerhedsrettelser, der var inkluderet i den tidligere SQL Server 2012 SP 1 rettelsesudgivelse. Vi anbefaler, at du overvejer at anvende den seneste rettelsesudgivelse, der indeholder dette hotfix." Dybest set betyder dette, at hvis du opdager et bestemt, relevant problem, der blev rettet i en tidligere CU, skal du gå videre og implementere den seneste relevante CU på systemet (som også vil inkludere det hotfix).
Et argument, som jeg ofte hører om, hvorfor organisationer ikke implementerer kumulative opdateringer, er, at "de er ikke fuldt regressionstestede, som Service Packs er, så vi implementerer dem ikke." Der er en vis gyldighed i dette synspunkt, men der er også en almindelig misforståelse om, at kumulative opdateringer blot er enhedstestet, uden nogen som helst regressionstest. Dette er ikke tilfældet.
Microsofts dokumentation om kumulative opdateringer indikerer, at da de "anvender inkrementel regressionstest gennem hele udviklingscyklussen efterfulgt af 2 ugers fokuseret test inden for 8 ugers udgivelsesvindue, overstiger kvalitetssikringsprocesserne forbundet med CU'er processerne for individuelle hotfixes." Det betyder, at du faktisk tager mindre risiko ved at implementere en CU, der er blevet trinvist regressionstestet og også har haft to ugers fokuseret test, end hvis du skulle implementere et enkelt hotfix, der kun er blevet enhedstestet.
I løbet af de sidste seks til syv år har jeg personligt implementeret mange, mange kumulative opdateringer og servicepakker på et stort antal systemer, der kører SQL Server 2005 til SQL Server 2012, og jeg har endnu ikke stødt på nogen større problemer. Jeg har heller ikke hørt om udbredte problemer med denne type arbejde, der er rapporteret i blogs, på Twitter osv. Det kan være, at jeg (og alle jeg kender) bare har været heldig, eller måske er kumulative opdateringer og servicepakker ikke helt så risikabelt, som nogle mennesker tror (så længe du tester og implementerer dem korrekt).
Vigtigheden af en test- og implementeringsplan
Medmindre du aldrig planlægger at lave nogen form for servervedligeholdelse eller applikationsopdateringer i hele dit systems levetid (hvilket virker som et usandsynligt forslag), skal du virkelig udvikle en form for test- og implementeringsprocedure og -plan, som du vil følge som en del at foretage enhver form for ændring af serveren.
Denne plan starter muligvis relativt enkel, men den bliver mere kompleks og komplet, efterhånden som du bliver mere erfaren med regelmæssig servicering af dine SQL Server-instanser og anvender de erfaringer, du lærer med hver implementering. Ideelt set ville du følge denne plan, når som helst du foretager en ændring af systemet, men det er måske ikke muligt i hvert enkelt tilfælde.
Her er et par indledende trin og test, der bør inkluderes i denne form for plan.
- Installer CU'en på en virtuel testmaskine
- Installeres CU'en uden problemer eller fejl?
- Kræver CU-installationen en systemgenstart?
- Genstarter alle de relevante SQL Server-tjenester efter installationen?
- Ser det ud til, at SQL Server fungerer korrekt efter installationen?
- Installer CU'en på flere udviklingssystemer
- Installeres CU'en uden problemer eller fejl?
- Ser det ud til, at SQL Server virker korrekt under normal daglig brug?
- Ser det ud til, at dine applikationer fungerer korrekt under enhedstestning?
- Installer CU'en i et delt QA- eller integrationsmiljø
- Følgte du en specifik implementeringsplan og tjekliste for installationen?
- Består alle de applikationer, der bruger SQL Server, røgtest?
- Består alle applikationerne nogen automatisk test, som du har til rådighed?
- Består alle applikationerne mere detaljerede manuelle funktionstests?
- Installer CU'en i dit produktionsmiljø
- Brug en rullende opgraderingsstrategi, hvor det er muligt
- Brug en detaljeret, trin-for-trin tjekliste under implementeringen
- Opdater din tjekliste med glemte emner og erfaringer
Konklusion
Det, jeg håber at opnå her, er at få flere databaseprofessionelle til at begynde at bevæge sig i retning af en tankegang, hvor de faktisk ønsker at vedligeholde deres SQL Server-instanser regelmæssigt i stedet for at være tøvende eller bange for at gøre det. Dette kan indebære en betydelig mængde ekstra arbejde i starten, da du måske skal overbevise andre mennesker i din organisation om at komme med på dine planer. Du skal muligvis presse andre dele af organisationen til at udvikle bedre testplaner, og du bliver nødt til at opbygge en implementeringstjekliste. Du skal også få autorisation fra virksomheden til vedligeholdelsesvinduer (som burde være relativt korte med rullende opgraderinger), så du rent faktisk kan få opdateringer implementeret på dine produktionssystemer med jævne mellemrum.
Til gengæld for dette ekstra arbejde vil du have et bedre vedligeholdt system, der er mindre tilbøjelige til at løbe ind i problemer i fremtiden. Du vil være i en fuldt understøttet konfiguration fra Microsoft, og du vil have mere tillid til din(e) højtilgængelige teknologi(er), da du faktisk vil udøve dem regelmæssigt. Du vil også få værdifuld erfaring, når du planlægger og implementerer alt dette, hvilket vil forbedre dine fejlfindingsevner i fremtiden.