For nylig skubbede Microsoft Service Pack 1 til SQL Server 2012 ud, og de fulgte hurtigt op med Kumulativ opdatering 1 til Service Pack 1. Årsagen til dette er, at servicepakken – grundet længere udviklings- og regressionstestcyklusser – ikke indeholdt evt. af rettelserne fra RTM Cumulative Updates 3 &4. Da mange mennesker har ventet – baseret på overvejende spekulativ bias på dette tidspunkt – med overhovedet at begynde at teste SQL Server 2012, indtil Service Pack 1 blev frigivet, tænkte jeg, at det kunne være nyttigt at dække et par af de scenarier, du kan støde på. Dette er ikke udelukkende et præstationsrelateret indlæg, men nogle af oplysningerne involverer serviceforstyrrelser, som måske eller måske ikke påvirker din virksomhed, SLA'er osv.
OPDATERING – SQL Server 2012 Service Pack 1 kumulativ opdatering 2 (11.0.3339) blev udgivet 2013-01-24.
Hvis SQL Server 2012 ikke allerede er installeret...
Når du installerer en ny forekomst af SQL Server, ønsker du at udføre så få trin som muligt. SQL Server 2012-opsætning er meget bedre til slipstreaming af både servicepakker og kumulative opdateringer end SQL Server 2008 / 2008 R2 (beskrevet af Peter Saddow her og her). Denne metode er forældet, men den understøttes stadig i SQL Server 2012. Så selvom du stadig kan bruge den gamle metode, hvis du vil:
D:\setup.exe /Action=Install /PCUSource=C:\SP1ExtractedFolder /CUSource=C:\CU1ExtractedFolder
Den nye metode, som du burde bruge, er meget enklere – og kræver ikke, at du manuelt udpakker pakkerne ved hjælp af /x argument først:
D:\setup.exe /Action=Install /UpdateSource=C:\AllUpdatesFolder
Du skal blot lægge alle de relevante opdateringer i samme mappe. Bemærk, at enhver opdatering du får med filnavnet [...]_zip.exe , skal du udpakke for at få den eksekverbare kerne. For eksempel, når du først downloader Service Pack 1 og Kumulativ opdatering 1, vil downloadmappen se sådan ud:
Du skal udpakke 455715_intl_x64_zip.exe ved at dobbeltklikke på den og vælge outputstien (ved at bruge /x på kommandolinjen er gyldig, men ignoreret). Når det er gjort, skulle mappen ende med at se sådan ud. (På hvilket tidspunkt kan du slette 455715... fil – selvom givet hvor "komprimeret" den er, må jeg undre mig over, hvorfor de fortsætter med at placere denne pakke i et selvudpakkende arkiv i første omgang.)
Når du nu kører ovenstående kommandolinje, når du kommer til skærmbilledet Produktopdateringer i opsætningen, skulle du se, at den har inkluderet både SP1 og CU1:
Bob Ward gør et meget godt stykke arbejde med at beskrive dette scenarie meget mere detaljeret her:
CSS-blog:SQL Server 2012-opsætning er lige blevet smartere...
Bemærk, at du kan opbevare alle dine servicepakker og kumulative opdateringer over tid i den samme mappe – hvis du bruger /UpdateSource argument, vil SQL Server Setup være smart nok til at vælge den seneste SP og dens seneste CU, uanset hvad der ellers måtte findes i den mappe.
Hvis SQL Server 2012 allerede er installeret...
Igen gælder alle disse oplysninger, hvis du installerer en ny forekomst af SQL Server. Jeg har på den anden side en masse SQL Server 2012 RTM-instanser, som jeg ønskede at patche – og da jeg ikke ønskede at miste nogen af rettelserne fra kumulative opdateringer 3 &4, ville jeg anvende både Service Pack 1 og kumulativ opdatering 1. Jeg håbede, at de samme slipstream-smarts ville være indbygget i den eksekverbare Service Pack 1-opsætning, så den blot kunne inkludere CU1-opdateringerne. Jeg prøvede det logiske:
C:\AllUpdatesFolder\SQLServer2012-SP1-KB2674319-x64-ENU.exe /UpdateSource=C:\AllUpdatesFolder
Men dette gav til sidst følgende fejl:
For søgemaskinens godhed:
The setting 'UpdateSource' is not allowed when the value of setting 'ACTION' is 'Patch'. Error code 0x84B40005.
(Og ja, jeg prøvede at placere den udpakkede CU1-opdateringsmappe et andet sted.)
Jeg har bekræftet med Microsoft, at selvom SP1 åbenbart indeholder noget af koden og logikken fra core setup.exe, er den ikke bygget til at tillade inkorporering af kumulative opdateringer. Med andre ord, du kan ikke slipstreame, når du installerer en servicepakke, kun når du installerer kerneproduktet.
Dette betyder også, at du skal udføre installationen i to trin . Jeg åbnede et nyt Connect-forslag, da slipstreaming uden tvivl er *mere* værdifuldt under servicering end under den første installation:
Connect #774109 :Tillad /UpdateSource for Service Pack-installatører
Så jeg fortsatte med at gøre dette i to trin. Jeg installerede Service Pack 1 og bemærkede, at der ikke var nogen filer i brug, som muligvis kræver en genstart:
Og når SP1 var færdig, lancerede jeg SP1 CU1-installationsprogrammet. Jeg stødte dog på denne fejl:
Så ikke nok med at jeg skulle tage to trin for at anvende disse patches, jeg var også nødt til at genstarte ind imellem. Jeg kiggede i logfilerne for hver installation (Detail.txt ), og jeg kan se, at da jeg kørte SP1, var der ingen indikation af, at Windows forventede en genstart:
(07) 2012-12-12 06:46:38 Slp: Rule 'RebootRequiredCheck' results: IsRebootNotRequired=True
Men da jeg kørte CU1 og fik fejlen, kun et par minutter efter SP1 var færdig, så jeg i den nye Detail.txt at Windows nu *forventede* en genstart:
(07) 2012-12-12 06:53:38 Slp: Windows Update requires a reboot (07) 2012-12-12 06:53:38 Slp: Rule 'RebootRequiredCheck' results: IsRebootNotRequired=False
Jeg er ikke sikker på, hvad der er sket, da jeg bestemt ikke kørte Windows Update mellem trinene.
OPDATERING:Takket være Shau Phang hos Microsoft opdagede vi i %SystemRoot%\WindowsUpdate.log at en automatisk Windows Update var startet efter SP1 var startet, og afsluttet før jeg startede CU opdateringen. Jeg formoder, at dette skyldes, at jeg vækkede computeren og begyndte straks at starte installationen af servicepakken; "skal genstarte"-kontrollen skal være blevet udløst ind imellem. Jeg ville acceptere det fulde ansvar for dette, hvis jeg lige havde slået Windows Update til og accepteret standarden; men det gjorde jeg ikke. Her er mine indstillinger:
Så vær forsigtig derude.
Konklusion
Moralen i historien er, at hvis du endnu ikke har installeret SQL Server 2012, vil slipstreaming for at komme til den seneste opdatering i én handling – uanset hvornår du kommer rundt til det, og hvilke opdateringer der er tilgængelige på det tidspunkt – til at være enkel og smertefri.
Hvis du allerede har en instans installeret, i hvilket tilfælde serviceafbrydelse og nedetid næsten altid vil være et mere kritisk problem end under en ny installation, skal du forholde dig omhyggeligt til din patching-metodologi og være sikker på, at dit vedligeholdelsesvindue vil tillade for en genstart af serveren, hvis det skulle være nødvendigt. Dette betyder også:Vær opmærksom på dine Windows Update-indstillinger, og om der er installeret nogen opdateringer siden sidste genstart.
Hvis du mener, at dette er et vigtigt spørgsmål, bedes du stemme på disse Connect-emner og, endnu vigtigere, kommentere, hvordan det aktuelle scenario kan påvirke din virksomhed.