Накопичені оновлення MS SQL Server - найкращі практики

Я намагаюся отримати уявлення про те, які рекомендовані найкращі практики для накопичувальних оновлень SQL Server .

В даний час ми працюємо на ідеї "робити нічого, якщо ми не відчуваємо проблеми, вирішеної КС". Це працює за підходу "якщо він не зламався, не виправляй", але мені цікаво, чи справді це гарна ідея, оскільки у багатьох МС є підвищення продуктивності. Ми розглядаємо, можливо, додавання КС до патчів, застосованих під час наших періодичних циклів технічного обслуговування через місяць-два після звільнення КС.

Що роблять інші, і чому?

Як оновлення до питання, яке впливає на відповіді нижче, 24 березня 2016 року команда SQL Server Microsoft оголосила, що оновлює свою модель обслуговування . Microsoft рекомендує всім користувачам встановити всі CU, випущені після січня 2016 року:

Станом на січень випуски МС ці повідомлення про застереження оновлювались, ми рекомендуємо продовжувати активну установку КС, коли вони стають доступними. Ви повинні планувати встановити CU з тим самим рівнем впевненості, що ви плануєте встановити SP (пакети послуг), як вони випускаються. Це відбувається тому, що КС сертифіковані та перевірені на рівень SP. Також дані CSS Microsoft вказують на те, що значний відсоток проблем із клієнтами раніше раніше вирішується у звільненому МС, але не застосовується проактивно. Тим більше, що CU містить додану вартість над та виправленнями. Вони також можуть містити підтримку, реєстрацію та оновлення надійності, що покращує загальний досвід.

Окрім оновлень повідомлень та вказівок, ми внесли оновлення до моделі придбання МС.

Зміни придбання:

• Звичайно, CU традиційно були доступні на сервері "Виправлення" (супроводжуючись "попереджувальною мовою", пов'язаною з "QFE" або "Виправленням"). Невідповідність тут полягає в тому, що CU вже не є простими швидкими виправленнями. Охоплені оновлення сьогодні добре перевірені як на індивідуальному, так і на повному рівні системної інтеграції.
• Тому зараз ми розміщуємо останню плату за кожний базовий рівень, що підтримується (2012 р. SP2 / SP3 та 2014 р. RTM / SP1 сьогодні) на microsoft.com/downloads, як це робиться для пакетів послуг сьогодні
• Крім того, ми незабаром випустимо та збережемо всі МС у Каталог оновлень Windows, щоб полегшити придбання та розповсюдження
• Лише тимчасові виправлення "У відповідь на вимогу" будуть розміщені на сервері виправлень, який рухається вперед
• Щоб зменшити тертя, для завантаження CU з microsoft.com/downloads не знадобиться надання / отримання електронної пошти та URL-адреси
• Ми також оцінюємо пропозицію останнього CU як необов'язкове оновлення Microsoft Update, як і пакети оновлень сьогодні

Я великий прихильник того, щоб бути в курсі останніх накопичувальних оновлень, але лише в тому випадку, якщо ваш цикл тестування / КЯ може забезпечити повне і правильне регресійне тестування проти нього. Глен Беррі з SQLskills також є прихильником такого підходу .

Власна рекомендація Майкрософт - застосовувати лише ті КС, які виправляють проблеми, які стосуються вас, хоча останнім часом вони ослабили цю позицію . Проблема полягає в тому, що на вас може вплинути одне чи більше із цих питань, і ви цього не знаєте, або можете завтра вплинути, навіть якщо він вас ще не зачепив. Чи збираєтесь ви пройти та спробувати відтворити проблему, що стоїть за кожним виправленням у кожному МС для вашої філії? Чи збираєтесь ви робити це постійно, щоб переконатися, що ви все ще не постраждали?

Буду чесно кажучи: у мене ніколи не виникало проблем із застосуванням жодного МС до моїх примірників. Насправді процес їх випуску в CU був набагато надійнішим, ніж цикл випуску сервісного пакету, і в багатьох випадках (в тому числі останнім часом із пакетом оновлень 2 для SQL Server 2012 ) ви не хочете застосовувати пакет оновлень до першого МС для цієї галузі все одно було звільнено. У цьому випадку існує тимчасове виправлення, яке дозволяє вирішити проблему, яка не була виправлена ​​вчасно для введення коду пакета послуг, але це не завжди відповідає дійсності.

Ми звикли йти в ногу з МС. Приблизно через 1 місяць після випуску ми застосуємо їх, чи не виникли проблеми, виправлені ними чи ні.

Однак після того, як ми зіткнулися з величезною проблемою, ми припинили цю практику. У нашому випадку ми встановили пакет оновлень, який вирішив проблему повнотекстової індексації. Через кілька місяців один із МС відмовив від цього конкретного виправлення. Це спричинило всілякі проблеми для нас, які зайняли досить багато досліджень, щоб з’ясувати, що сталося. Ми закінчили кодування роботи, навколо якої потім пізніше викрутили, коли новий CU зламав щось інше ... Чистий результат: сервер перевстановлювався з нуля на певний рівень SP / CU і заморожувався.

Продуктивність нашої програми така, що ми не переймаємось будь-якими новими підвищеннями продуктивності SQL, які можуть з’явитися, тому це не проблема. Крім того, звітний та інші запити послідовно відкликають дійсні результати, тому будь-які нові зміни не потрібні. Що означає, що перед тим, як ми розглянемо застосування КС, це має бути проблемою безпеки.

Я повністю згоден з Аароном: робіть це лише в тому випадку, якщо ваш цикл тестування / КЯ зможе правильно його перевірити . І навіть тоді випробовуйте кожну її частину з реальними даними, щоб переконатися, що вони не зламали щось, від чого ви можете залежати.