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


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

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

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

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

Загрузка

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

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

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

Вы также можете рассмотреть возможность обновления базы данных 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.

    При перемещении базы данных для приложения на другой экземпляр сервера необходимо повторно создать все метаданные зависимых сущностей и объектов в master msdb экземпляре целевого сервера. Например, если приложение базы данных использует триггеры уровня сервера, просто присоединение или восстановление базы данных в новой системе недостаточно. База данных не работает должным образом, если вы вручную не создадите метаданные для этих триггеров в 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.

Примечание.

Если у вас уже есть решение высокого уровня доступности или другое несколько сред SQL Serverinstance, перейдите к последовательному обновлению. Если у вас нет решения с высоким уровнем доступности, вы можете временно настроить зеркальное отображение базы данных для дальнейшего уменьшения простоя, чтобы упростить это обновление или воспользоваться этой возможностью, чтобы настроить группу доступности 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 2005 (9.x). Дополнительные сведения см. в статье Обновление с более ранней версии SQL Server.

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

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

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

  • Среда с хранилищем SAN. При наличии среды SQL Server, использующей хранилище SAN, ознакомьтесь со следующей схемой и ссылками на ней, которые описывают действия, необходимые для обновления путем новой установки Компонент Database Engine.

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

Последовательное обновление

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