Накопительные обновления MS SQL Server - лучшие практики

Я пытаюсь понять, какие рекомендации рекомендуются для Накопительные обновления SQL Server .

В настоящее время мы убеждаемся в том, что «ничего не делайте, если проблема, зафиксированная CU, не та, которую мы испытываем». Это работает из подхода «если он не сломался, не исправляйте», но мне интересно, действительно ли это хорошая идея, так как многие из CU имеют улучшения производительности. Мы рассматриваем возможность добавления CU к исправлениям, применяемым во время наших периодических циклов обслуживания через месяц или два после выпуска CU.

Что делают другие, и почему?


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

  

По состоянию на январь выпуски CU эти предупреждения были обновлены,   теперь мы рекомендуем проводить постоянную, активную установку CU, поскольку они   становятся доступными. Вы должны планировать установку CU с тем же уровнем   что вы планируете устанавливать SP (Service Packs), поскольку они   выпущенный. Это потому, что CU сертифицированы и проверены на уровне   от SP. Кроме того, данные Microsoft CSS показывают, что значительная   процент проблем с клиентами часто ранее рассматривался в   выпущен CU, но не применяется проактивно. Более того, добавление CU добавлено   значение выше и выше. Они также могут содержать поддержку,   регистрации и обновлений надежности, улучшающих общий опыт.

     

В дополнение к обновлениям сообщений и руководств мы сделали обновления для   модель приобретения CU.

     

Изменения в приобретении:

     
  • CU, конечно, традиционно были доступны на сервере «Исправление» (в сопровождении «предостерегающего языка»   с «QFE» или «Исправление»). Несоответствие здесь состоит в том, что CU не   действительно простые быстрые исправления. Всеобъемлющие обновления   хорошо протестированные как на индивидуальном, так и на полном уровне системной интеграции   сегодня.
  •   
  • Таким образом, мы теперь размещаем последний CU на базовую линию, поддерживаемую основным потоком (2012 SP2 /SP3 и 2014 RTM /SP1 сегодня) на   microsoft.com/downloads, так же, как это делается для пакетов обновлений сегодня.
  •   
  • Кроме того, мы вскоре выпустим и сохраним все CU в каталоге Windows Update, чтобы облегчить сбор и распространение
  •   
  • Исправлены только временные исправления CU «On-Demand» на сервере исправлений, продвигающемся вперед
  •   
  • Чтобы уменьшить трение, загрузка CU с microsoft.com/downloads не потребует предоставления /получения электронной почты и URL-адреса
  •   
  • Мы также оцениваем предложение последнего CU в качестве необязательного обновления в Центре обновления Майкрософт, так же как и пакеты обновления сегодня
  •   
10 голосов | спросил Bacon Bits 30 J0000006Europe/Moscow 2014, 17:19:06

2 ответа


8

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

Собственная рекомендация Microsoft заключается в применении только тех блоков управления, которые исправляют проблемы, которые влияют на вас, , хотя они имеют недавно ослабил эту позицию . Проблема в том, что на вас может повлиять одна или несколько из этих проблем, и вы не знаете этого, или вы можете быть затронуты завтра, даже если он еще не ударил вас. Вы собираетесь пройти и попытаться воспроизвести проблему за каждым исправлением в каждом отдельном CU для своего филиала? Вы собираетесь делать это непрерывно, чтобы убедиться, что вы все еще не затронуты?

Я буду честным: у меня никогда не было проблемы с применением CU к моим экземплярам. И на самом деле процесс их выпуска CU был намного более надежным, чем цикл выпуска пакета обновления, и во многих случаях (включая в последнее время с SQL Server 2012 с пакетом обновления 2 (SP2) ), вы не хотите применять пакет обновления до тех пор, пока не будет выпущен первый CU для этой ветви. В этом случае есть временное исправление для решения проблемы, которая не была исправлена ​​вовремя, чтобы сделать код Service Pack, но это не всегда так.

ответил Aaron Bertrand 30 J0000006Europe/Moscow 2014, 17:54:16
5

Мы не отставали от CU. Примерно через 1 месяц после релиза мы применили бы их, будет ли у нас проблема, исправленная ими или нет.

Однако после того, как мы столкнулись с огромной проблемой, мы прекратили эту практику. В нашем случае пакет обновления, который мы установили, исправил проблему с полнотекстовым индексированием, которое мы испытывали. Несколько месяцев спустя один из CU откат назад сделал это конкретное исправление. Это вызвало у нас всевозможные проблемы, которые провели немало исследований, чтобы выяснить, что произошло. Мы закончили тем, что кодировали работу, которая позже была запутана, когда новый CU сломал что-то еще ... Чистый результат: сервер повторно установлен с нуля до определенного уровня SP /CU и заморожен.

Наша производительность приложения такова, что мы не связаны с новыми усовершенствованиями производительности SQL, которые могут возникнуть, поэтому это не проблема. Кроме того, отчеты и другие запросы постоянно выводят действительные результаты, поэтому любые новые настройки не нужны. Это означает, что он должен быть проблемой безопасности, прежде чем мы рассмотрим применение CU в настоящее время.

Я полностью согласен с Aaron: делать это только в том случае, если ваш тест /QA-цикл может правильно протестировать его. В противном случае я бы сказал, что это понятно, если только оно не исправляет проблему, с которой вы столкнулись. И даже тогда, испытайте каждую маленькую грань этого с реальными данными, чтобы убедиться, что они не сломали что-то, на что вы можете быть в зависимости.

ответил NotMe 30 J0000006Europe/Moscow 2014, 20:54:30

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132