Накопительные обновления 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, чтобы облегчить приобретение и распространение
• Только промежуточные исправления CU 'On-Demand' будут размещены на сервере исправлений в будущем.
• Чтобы уменьшить трения, загрузка CU с сайта microsoft.com/downloads не потребует предоставления / получения электронной почты и URL-адреса.
• Мы также оцениваем предложение последней CU в качестве дополнительного обновления в Центре обновления Майкрософт, как и сегодня пакеты обновления

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

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

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

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

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

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

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