Поделиться через

Выбор метода обновления ядро СУБД

  • Статья

Область применения: SQL Server — только Для Windows

Существует несколько подходов, которые следует учитывать при планировании обновления ядро СУБД с предыдущего выпуска SQL Server, чтобы свести к минимуму время простоя и риск. Можно выполнить обновление на месте, миграцию в новую установку или последовательное обновление. На следующей схеме вы можете выбрать один из этих подходов. Каждый подход на схеме также рассматривается в статье. Чтобы помочь вам с ключевыми точками принятия решений на схеме, также просмотрите, и протестируйте план обновления ядра СУБД.

Схема: дерево выбора метода обновления ядра СУБД.

Загрузка

  • Чтобы скачать SQL Server, посетите Центр оценки.

  • Есть учетная запись Azure? Затем перейдите в Azure Marketplace , чтобы развернуть виртуальную машину с уже установленным выпуском SQL Server Developer.

Параметры обновления Azure SQL

Вы также можете рассмотреть возможность обновления базы данных SQL Azure, управляемого экземпляра SQL Azure или виртуализации среды SQL Server в рамках плана обновления. Дополнительные сведения об этих параметрах см. в следующих ссылках:

Обновление на месте

При таком подходе программа установки SQL Server обновляет существующую установку SQL Server, заменив существующие биты SQL Server новыми битами SQL Server, а затем обновляет каждую из системных и пользовательских баз данных.

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

Этот подход часто используется в следующих сценариях:

  • Среда разработки без конфигурации для обеспечения высокой доступности.

  • рабочая среда без критически важных нагрузок, которая допускает некоторое время простоя и в которой используется новое оборудование и программное обеспечение. Время простоя зависит от размера базы данных и быстродействия подсистемы ввода-вывода. Обновление SQL Server 2014 (12.x) при использовании оптимизированных для памяти таблиц занимает некоторое время. Дополнительные сведения см. в разделе Составление и тестирование плана обновления ядра СУБД.

На высоком уровне шаги, необходимые для обновления ядро СУБД на месте, приведены ниже.

Схема, показывающая локальное обновление движка базы данных без высокой доступности.

Дополнительные сведения см. в статье Обновление SQL Server с помощью мастера установки (программа установки).

Рекомендации

Программа установки SQL Server останавливает и перезапускает экземпляр SQL Server в рамках проверок перед обновлением.

При обновлении SQL Server предыдущий экземпляр SQL Server перезаписывается и больше не будет существовать на компьютере. Перед обновлением создайте резервную копию баз данных SQL Server и других объектов, связанных с экземпляром предыдущей версии SQL Server.

Миграция в новую установку

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

  • Системные объекты . Некоторые приложения зависят от информации, сущностей или объектов, которые находятся вне области однопользовательской базы данных. Как правило, приложение зависит от баз данных master и msdb пользовательской базы данных. Что-либо сохраненное вне пользовательской базы данных, которая требуется для правильного функционирования другой базы данных, должно быть доступно на экземпляре целевого сервера. Например, имена входа для приложений сохраняются как метаданные в базе данных master и должны быть созданы заново на целевом сервере. Если приложение или план обслуживания базы данных зависит от заданий агента SQL Server, чьи метаданные сохранены в базе данных msdb, необходимо заново создать эти задания в экземпляре целевого сервера. Точно так же метаданные для триггера уровня сервера сохраняются в базе данных master.

    При перемещении базы данных для приложения на другой экземпляр сервера необходимо повторно создать все метаданные зависимых сущностей и объектов в mastermsdb экземпляре целевого сервера. Например, если приложение базы данных использует триггеры уровня сервера, просто присоединение или восстановление базы данных в новой системе недостаточно. База данных не работает должным образом, если вы вручную не создадите метаданные для этих триггеров в master базе данных. Дополнительные сведения см. в разделе Управление метаданными при обеспечении доступности базы данных на другом экземпляре сервера (SQL Server).

  • Пакеты служб Integration Services, хранящиеся в msdb: если вы храните пакеты в msdb, необходимо либо заскриптовать эти пакеты с помощью утилиты dtutil, либо перенести их на новый сервер. Перед использованием пакетов на новом сервере необходимо обновить пакеты до SQL Server. Дополнительные сведения см. в разделе Upgrade Integration Services Packages.

  • Ключи шифрования служб Reporting Services . Одним из важных аспектов настройки сервера отчетов является создание резервной копии симметричного ключа, используемого для шифрования конфиденциальных данных. Резервная копия ключа требуется для выполнения многих распространенных операций и позволяет повторно использовать базу данных существующего сервера отчетов в новом сервере. Дополнительные сведения см. в разделах Резервное копирование и восстановление ключей шифрования служб Reporting Services и Upgrade и Migrate Reporting Services

После того как новая среда SQL Server имеет те же системные объекты, что и существующая среда, затем переносите пользовательские базы данных из существующей системы в экземпляр SQL Server таким образом, чтобы свести к минимуму время простоя в существующей системе. Вы выполняете миграцию базы данных, используя резервное копирование и восстановление или перенаправляя LUN, если вы работаете в среде SAN. Шаги для обоих методов указываются на следующих схемах.

Внимание

Время простоя зависит от размера базы данных и быстродействия подсистемы ввода-вывода. Обновление SQL Server 2014 (12.x) при использовании оптимизированных для памяти таблиц займет некоторое время. Дополнительные сведения см. в разделе Составление и тестирование плана обновления ядра СУБД.

После переноса пользовательских баз данных вы указываете новым пользователям новый экземпляр SQL Server с помощью одного из нескольких методов (например, переименование сервера, использование записи DNS и изменение строка подключения). Новый подход к установке снижает риск и простой по сравнению с обновлением на месте, а также упрощает обновление оборудования и операционной системы с обновлением до SQL Server.

Примечание.

Если у вас уже есть решение высокой доступности (HA) или другое окружение с несколькими экземплярами SQL Server, используйте поочередное обновление. Если у вас нет решения с высоким уровнем доступности, вы можете временно настроить зеркальное отображение базы данных для дальнейшего уменьшения простоя, чтобы упростить это обновление или воспользоваться этой возможностью, чтобы настроить группу доступности AlwaysOn в качестве постоянного решения высокой доступности.

Например, этот подход можно использовать для обновления:

  • Установка SQL Server в неподдерживаемой операционной системе.
  • Установка SQL Server x86 (32-разрядная версия), так как SQL Server 2016 (13.x) и более поздних версий не поддерживают установку x86.
  • SQL Server на новое оборудование и (или) новую версию операционной системы.
  • SQL Server с консолидацией сервера.
  • SQL Server 2005 (9.x) не поддерживает обновление на месте, как и SQL Server 2016 (13.x) и более поздние версии. Дополнительные сведения см. в статье Обновление с более ранней версии SQL Server.

Действия, необходимые для нового обновления установки, немного зависят от того, используется ли подключенное хранилище или хранилище SAN.

  • Подключенная среда хранения: Если у вас есть среда SQL Server с присоединенным хранилищем, следующая схема и ссылки на ней направят вас через шаги, необходимые для установки обновления ядра СУБД.

    Схема: новый метод обновления установки с использованием резервного копирования и восстановления для подключенного хранилища.

  • Среда с хранилищем SAN: Если у вас есть среда SQL Server, использующая хранилище SAN, ознакомьтесь со следующей схемой и ссылками на ней, которые помогут пройти все шаги, необходимые для обновления За счет новой установки ядра базы данных.

    Схема: новый метод обновления установки с использованием отсоединения и присоединения для хранилища сети SAN.

Пошаговое обновление

Последовательное обновление требуется в средах решения SQL Server с несколькими экземплярами SQL Server, которые должны быть обновлены в определенном порядке, чтобы максимально увеличить время простоя, свести к минимуму риск и сохранить функциональные возможности. Последовательное обновление по сути является обновлением нескольких экземпляров SQL Server в определенном порядке. Вы либо выполняете обновление на месте на каждом существующем экземпляре SQL Server, либо новое обновление установки для упрощения обновления оборудования и (или) операционной системы в рамках проекта обновления. Существует несколько сценариев, в которых необходимо использовать подход к последовательному обновлению. Все они описаны в следующих статьях: