Риски, связанные с обновлением до SQL Server 2008 R2

У нас есть целый ряд SQL-серверов, которые необходимо обновить с версии 2005 до 2008 R2. Работа планируется до середины года, так как Microsoft прекращает свою поддержку.

Все SQL-серверы 2005 года - SP3 и SP4, работающие на Windows Server 2003 (поддержка которого уже прекращена, но у нас есть исключение для продления еще на один год), но при необходимости мы можем также перейти на обновление ОС сервера.

Эти серверы включают репликацию (транзакционную), доставку журналов, службы отчетов и сервер интеграции, на котором выполняются пакеты служб SSIS.

Мой вопрос здесь не в том, как, скорее, я бы хотел узнать о рисках или каких-либо предварительных проверках, которые можно выполнить перед планированием этого обновления?

Кроме того, будет ли обновление на месте лучше, чем параллельное выполнение этой миграции / обновления?

Это действительно большой вопрос, поэтому давайте разберем его немного.

Что я могу сделать заранее?

Начните с необходимого чтения .

• 2008 R2 обратная совместимость
• Обратная совместимость 2008

Эти ссылки имеют ссылки на дополнительную информацию, такую ​​как

• Устаревшие возможности SQL Server
• Прекращенные функции SQL Server
• Ломать перемены
• Изменения в поведении функций SQL Server

Прочитайте каждый из них, чтобы увидеть, что меняется. Обратите особое внимание на функции, которые вы используете.

Кроме того, вы должны использовать Советник по обновлению . Он проверяет наличие установленных компонентов и определяет те, которые вам нужно будет исправить до или после установки.

Много за и против здесь с обеих сторон.

На месте

Pros

• Намного легче. Например, все ваши конфигурации остаются неизменными. Также строки подключения для ваших приложений, вероятно, не нужно будет менять.
• Более дешевый. Второй комплект оборудования не требуется.

Cons

• Отступление трудно или невозможно. Если что-то пойдет не так, вам придется включить и завершить работу, потому что резервирование включает в себя создание нового сервера и переустановку SQL, а затем восстановление резервных копий ваших таблиц.

Бок о бок

В основном плюсы и минусы являются противоположностью на месте.

Pros

• Безопаснее - если что-то пойдет не так, вы убьете новую версию и просто продолжите работу со старой. Тогда вы можете попробовать позже.

Cons

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

Теперь вы можете сократить расходы на параллельное создание нового экземпляра на том же сервере, переместить все на него, а затем удалить старый экземпляр. Это работает и в зависимости от вашей ситуации может быть лучшей идеей.

Честно говоря, переход с 2005 - 2008 R2 не так уж и плох. Это ничто по сравнению с 2000 - 2005 или 2008 R2 - 2012 (в основном изменения SSIS). Я бы сказал, что при тщательном планировании и чтении вы должны быть в хорошей форме.

Так что мой вопрос здесь не в том, как, скорее, хотелось бы узнать о риске или каких-либо предварительных проверках, которые можно выполнить до планирования этого обновления?

Вам следует запустить советник по обновлению и решить проблемы, о которых он сообщил, перед миграцией.

Обратитесь к моему ответу для подробного списка шагов до и после обновления .

SQL-сервер, который необходимо обновить с версии 2005 до 2008R2

Вы выбираете путь, по которому вы вернетесь к квадрату 1 (поскольку в течение 3 лет вам придется обновляться снова). Смотрите таблицу ниже

Будет ли обновление Inplace лучшим планом или рядом для этой миграции / обновления?

Исходя из моего опыта, я бы посоветовал вам выполнить параллельную миграцию, поскольку вы получаете новую версию ОС и SQL. Это гораздо более чистый подход, так как ваши старые серверы будут работать на всякий случай, если вы захотите выполнить возврат. Обратитесь к разделу: Являются ли обновления на месте SQL Server такими плохими, как раньше? , Не поймите меня неправильно, когда я предлагаю параллельную миграцию, это более безопасная сторона, когда дело доходит до отката.

IMO, если вы собираетесь перейти на новую версию, то вам следует пройти весь путь до 2014 года, даже если вы запускаете его в режиме совместимости 10.0.

Вы все равно заплатите за лицензию. Также регрессионное тестирование и кривая обучения разработчика / DBA будут значительными в любом случае. Если вы остановитесь на 2008R2 сейчас, вам просто придется повторить упражнение через пару лет. 2008R2 уже видел свой последний Пакет обновления и через несколько месяцев (недель) будет 3 полные версии позади текущей версии.

Я рекомендую перевести мою организацию из 2008R2 непосредственно в 2016 по тем же причинам. Я ожидаю, что мы начнем тестирование, как только 2016 выйдет в RTM.

Кстати, я согласен, что параллельное обновление предпочтительнее. Когда я в последний раз выполнял это упражнение, мы запускали версию «Pre-Production» в среде разработчиков в течение месяца.