Наскоро Microsoft пусна Service Pack 1 за SQL Server 2012 и те бързо последваха Кумулативна актуализация 1 за Service Pack 1. Причината за това е, че сервизният пакет – поради по-дълги цикли на разработка и регресионно тестване – не съдържа никакви на корекциите от RTM Кумулативни актуализации 3 и 4. Тъй като много хора чакаха – въз основа предимно на спекулативни пристрастия в този момент – дори да започнат да тестват SQL Server 2012, докато не бъде пуснат Service Pack 1, реших, че може да е полезно да покрия няколко от сценариите, които може да срещнете. Това не е строго свързана публикация, но част от информацията включва прекъсвания на услугите, които може да повлияят или да не повлияят на вашия бизнес, SLA и т.н.
АКТУАЛИЗИРАНЕ – SQL Server 2012 Service Pack 1 Кумулативна актуализация 2 (11.0.3339) беше пусната на 24.01.2013 г.
Ако SQL Server 2012 не е вече инсталиран...
Когато инсталирате нов екземпляр на SQL Server, искате да изпълните възможно най-малко стъпки. Настройката на SQL Server 2012 е много по-добра за прехвърляне на сервизни пакети и кумулативни актуализации от SQL Server 2008 / 2008 R2 (описано от Питър Садоу тук и тук). Този метод е отхвърлен, но все още се поддържа в SQL Server 2012. Така че докато все още можете да използвате стария метод, ако желаете:
D:\setup.exe /Action=Install /PCUSource=C:\SP1ExtractedFolder /CUSource=C:\CU1ExtractedFolder
Новият метод, който трябва да използвате, е много по-прост – и не изисква ръчно извличане на пакетите с помощта на /x аргумент първи:
D:\setup.exe /Action=Инсталиране /UpdateSource=C:\AllUpdatesFolder
Просто трябва да поставите всички съответни актуализации в една и съща папка. Имайте предвид, че всяка актуализация, която получавате с името на файла [...]_zip.exe , трябва да извлечете, за да получите основния изпълним файл. Например, когато за първи път изтеглите Service Pack 1 и Cumulative Update 1, папката за изтегляне ще изглежда така:
Трябва да извлечете 455715_intl_x64_zip.exe като щракнете двукратно върху него и изберете изходния път (с помощта на /x в командния ред е валиден, но игнориран). След като приключите, папката трябва да изглежда така. (В този момент можете да изтриете 455715... файл – макар че като се има предвид колко е „компресиран“, трябва да се чудя защо изобщо продължават да поставят този пакет в саморазархивиращ се архив.)
Сега, когато стартирате горния команден ред, когато стигнете до екрана за актуализации на продукта в настройката, трябва да видите, че той включва SP1 и CU1:
Боб Уорд се справя много добре с описанието на този сценарий много по-подробно тук:
CSS блог :Настройката на SQL Server 2012 току-що стана по-умна...
Имайте предвид, че можете да съхранявате всичките си сервизни пакети и кумулативни актуализации във времето в една и съща папка – ако използвате /UpdateSource аргумент, SQL Server Setup ще бъде достатъчно интелигентен, за да избере най-новия SP и неговия най-нов CU, независимо какво друго може да съществува в тази папка.
Ако SQL Server 2012 вече е инсталиран...
Отново, цялата тази информация е приложима, ако инсталирате нов екземпляр на SQL Server. Аз, от друга страна, имам куп екземпляри на SQL Server 2012 RTM, които исках да поправя – и тъй като не исках да загубя нито една от поправките от Кумулативни актуализации 3 и 4, исках да приложа и двата Service Pack 1 и кумулативна актуализация 1. Надявах се, че същите функции на slipstream ще бъдат вградени в изпълнимия файл за настройка на Service Pack 1, така че да може просто да включва актуализациите на CU1. Опитах логичното:
C:\AllUpdatesFolder\SQLServer2012-SP1-KB2674319-x64-ENU.exe /UpdateSource=C:\AllUpdatesFolder
Но това в крайна сметка доведе до следната грешка:
За добротата на търсачката:
Настройката „UpdateSource“ не е разрешена, когато стойността на настройката „ACTION“ е „Patch“. Код на грешка 0x84B40005.
(И да, опитах се да поставя извлечената папка за актуализация на CU1 на друго място.)
Потвърдих с Microsoft, че въпреки че SP1 очевидно съдържа част от кода и логиката от основния setup.exe, той не е създаден, за да позволи включване на кумулативни актуализации. С други думи, не можете да плъзгате поток, когато инсталирате сервизен пакет, само когато инсталирате основния продукт.
Това също означава, че ще трябва да извършите инсталацията на две стъпки . Отворих ново предложение за свързване, тъй като slipstreaming вероятно е *по-ценен* по време на обслужване, отколкото по време на първоначалната инсталация:
Свързване #774109 :Разрешаване на /UpdateSource за инсталатори на сервизен пакет
И така, продължих да правя това в две стъпки. Инсталирах сервизен пакет 1 и отбелязах, че не се използват файлове, които може да изискват рестартиране:
И след като SP1 беше завършен, стартирах инсталатора на SP1 CU1. Въпреки това попаднах на тази грешка:
Така че не само трябваше да направя две стъпки, за да приложа тези пачове, но и да рестартирам между тях. Прегледах регистрационните файлове за всяка инсталация (Detail.txt ) и виждам, че когато стартирах SP1, нямаше индикация, че Windows очаква рестартиране:
(07) 2012-12-12 06:46:38 Slp:Правило 'RebootRequiredCheck' резултати:IsRebootNotRequired=True
Но след това, когато стартирах CU1 и получих грешката, само няколко минути след завършването на SP1, видях в новия Detail.txt че сега Windows *е* очакваше рестартиране:
(07) 2012-12-12 06:53:38 Slp:Windows Update изисква рестартиране(07) 2012-12-12 06:53:38 Slp:Правило 'RebootRequiredCheck' резултати:IsRebootNotRequired=False>
Не съм сигурен какво се е случило, тъй като със сигурност не отидох да стартирам Windows Update между стъпките.АКТУАЛИЗАЦИЯ:Благодарение на Shau Phang от Microsoft, ние открихме в
%SystemRoot%\WindowsUpdate.logче автоматичната актуализация на Windows е започнала след стартиране на SP1 и е приключила преди да започна актуализацията на CU. Предполагам, че това е, защото събудих компютъра и веднага започнах инсталирането на сервизния пакет; проверката "трябва да рестартирате" трябва да е била задействана между тях. Бих поел пълната отговорност за това, ако току-що бях включил Windows Update и бях приел по подразбиране; но не го направих. Ето моите настройки:
Така че, бъдете внимателни.
Заключение
Моралът на историята е, че ако все още не сте инсталирали SQL Server 2012, slipstreaming, за да стигнете до най-новата актуализация с едно действие – независимо кога ще стигнете до нея и какви актуализации са налични в момента – ще бъдете прости и безболезнени.
Ако вече имате инсталиран екземпляр, в който случай прекъсването на услугата и времето на престой почти винаги ще бъдат по-критични проблеми, отколкото по време на нова инсталация, ще трябва внимателно да подхождате към методологията си за корекция и да сте сигурни, че вашият прозорец за поддръжка ще позволи за рестартиране на сървъра, ако е необходимо. Това също означава:имайте предвид настройките на Windows Update и дали са инсталирани някакви актуализации след последното рестартиране.
Ако смятате, че това е важен въпрос, моля, гласувайте за тези елементи на Connect и, което е по-важно, коментирайте как настоящият сценарий може да повлияе на бизнеса ви.
