Nyligen pushade Microsoft ut Service Pack 1 för SQL Server 2012 och man följde snabbt upp med Cumulative Update 1 för Service Pack 1. Anledningen till detta är att Service Pack – på grund av längre utvecklings- och regressionstestcykler – inte innehöll några av korrigeringarna från RTM Cumulative Updates 3 &4. Eftersom många människor har väntat – baserat på mestadels spekulativ fördom vid det här laget – med att ens börja testa SQL Server 2012 tills Service Pack 1 släpptes, tänkte jag att det kunde vara användbart att täcka ett par av de scenarier du kan stöta på. Det här är inte strikt ett prestationsrelaterat inlägg, men en del av informationen involverar tjänstavbrott, vilket kan eller kanske inte påverkar ditt företag, SLA, etc.
UPPDATERA – SQL Server 2012 Service Pack 1 Cumulative Update 2 (11.0.3339) släpptes 2013-01-24.
Om SQL Server 2012 inte redan är installerat...
När du installerar en ny instans av SQL Server vill du utföra så få steg som möjligt. SQL Server 2012-installationen är mycket bättre när det gäller slipstreaming av både service pack och kumulativa uppdateringar än SQL Server 2008 / 2008 R2 (beskrivs av Peter Saddow här och här). Denna metod är föråldrad, men den stöds fortfarande i SQL Server 2012. Så även om du fortfarande kan använda den gamla metoden om du vill:
D:\setup.exe /Action=Install /PCUSource=C:\SP1ExtractedFolder /CUSource=C:\CU1ExtractedFolder
Den nya metoden, som du borde använda, är mycket enklare – och kräver inte att du manuellt extraherar paketen med /x argument först:
D:\setup.exe /Action=Install /UpdateSource=C:\AllUpdatesFolder
Du behöver bara lägga alla relevanta uppdateringar i samma mapp. Observera att alla uppdateringar du får med filnamnet [...]_zip.exe måste du extrahera för att få den körbara kärnan. Till exempel, när du först laddar ner Service Pack 1 och Cumulative Update 1, kommer nedladdningsmappen att se ut så här:
Du måste extrahera 455715_intl_x64_zip.exe genom att dubbelklicka på den och välja utdatasökväg (med /x på kommandoraden är giltig, men ignoreras). När det är klart bör mappen se ut så här. (Då kan du ta bort 455715... fil – med tanke på hur "komprimerad" den är, måste jag undra varför de fortsätter att placera det här paketet i ett självextraherande arkiv i första hand.)
När du nu kör kommandoraden ovan, när du kommer till skärmen Produktuppdateringar i installationen, bör du se att den har inkluderat både SP1 och CU1:
Bob Ward gör ett mycket bra jobb med att beskriva detta scenario i mycket mer detalj här:
CSS-blogg:SQL Server 2012-installationen blev precis smartare...
Observera att du kan behålla alla dina Service Pack och kumulativa uppdateringar över tiden i samma mapp – om du använder /UpdateSource argument, SQL Server Setup kommer att vara smart nog att välja den senaste SP och dess senaste CU, oavsett vad mer som kan finnas i den mappen.
Om SQL Server 2012 redan är installerad...
Återigen, all den informationen gäller om du installerar en ny instans av SQL Server. Jag, å andra sidan, har ett gäng SQL Server 2012 RTM-instanser som jag ville korrigera – och eftersom jag inte ville förlora någon av korrigeringarna från kumulativa uppdateringar 3 och 4, ville jag använda både Service Pack 1 och kumulativ uppdatering 1. Jag hoppades att samma slipstream-smarts skulle byggas in i installationsprogrammet för Service Pack 1, så att det helt enkelt kunde inkludera CU1-uppdateringarna. Jag försökte det logiska:
C:\AllUpdatesFolder\SQLServer2012-SP1-KB2674319-x64-ENU.exe /UpdateSource=C:\AllUpdatesFolder
Men detta gav så småningom följande fel:
För sökmotorer:
The setting 'UpdateSource' is not allowed when the value of setting 'ACTION' is 'Patch'. Error code 0x84B40005.
(Och ja, jag försökte placera den extraherade CU1-uppdateringsmappen på en annan plats.)
Jag har bekräftat med Microsoft att även om SP1 uppenbarligen innehåller en del av koden och logiken från core setup.exe, har den inte byggts för att möjliggöra inkorporering av kumulativa uppdateringar. Med andra ord, du kan inte slipstream när du installerar ett service pack, bara när du installerar kärnprodukten.
Detta betyder också att du måste utföra installationen i två steg . Jag öppnade ett nytt Connect-förslag, eftersom slipstreaming utan tvekan är *mer* värdefullt under service än under den första installationen:
Anslut #774109 :Tillåt /UpdateSource för Service Pack-installatörer
Så jag fortsatte med att göra detta i två steg. Jag installerade Service Pack 1 och noterade att inga filer användes som kan kräva en omstart:
Och sedan när SP1 var klar, startade jag installationsprogrammet för SP1 CU1. Men jag stötte på det här felet:
Så jag var inte bara tvungen att ta två steg för att applicera dessa plåster, jag var också tvungen att starta om emellan. Jag tittade i loggfilerna för varje installation (Detail.txt ) och jag kan se att när jag körde SP1, fanns det ingen indikation på att Windows förväntade sig en omstart:
(07) 2012-12-12 06:46:38 Slp: Rule 'RebootRequiredCheck' results: IsRebootNotRequired=True
Men när jag sedan körde CU1 och fick felet, bara några minuter efter att SP1 var klar, såg jag i den nya Detail.txt att Windows nu *väntade* en omstart:
(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
Jag är inte säker på vad som har hänt, eftersom jag verkligen inte gick och körde Windows Update mellan stegen.
UPPDATERING:Tack vare Shau Phang på Microsoft upptäckte vi i %SystemRoot%\WindowsUpdate.log att en automatisk Windows Update hade startat efter att SP1 hade startat, och avslutades innan jag startade CU-uppdateringen. Jag antar att detta beror på att jag väckte datorn och började omedelbart att starta service pack-installationen; "måste starta om"-kontrollen måste ha utlösts däremellan. Jag skulle ta fullt ansvar för detta om jag precis hade aktiverat Windows Update och accepterat standarden; men jag gjorde inte. Här är mina inställningar:
Så var försiktig där ute.
Slutsats
Moralen i berättelsen är, om du ännu inte har installerat SQL Server 2012, slipstreaming för att komma till den senaste uppdateringen i en åtgärd – oavsett när du kommer runt till det och vilka uppdateringar som är tillgängliga vid tillfället – kommer att vara enkel och smärtfri.
Om du redan har en instans installerad, i vilket fall tjänstavbrott och driftstopp nästan alltid kommer att vara ett mer kritiskt problem än under en ny installation, måste du närma dig din patchmetod noggrant och vara säker på att ditt underhållsfönster tillåter för en omstart av servern, om det skulle behövas. Detta innebär också:var medveten om dina Windows Update-inställningar och om några uppdateringar har installerats sedan den senaste omstarten.
Om du tycker att detta är en viktig fråga, vänligen rösta på dessa Connect-objekt och, ännu viktigare, kommentera hur det aktuella scenariot kan påverka ditt företag.