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

Статья
10/20/2023

Применяется только к: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) при использовании оптимизированных для памяти таблиц занимает некоторое время. Дополнительные сведения см. в разделе Составление и тестирование плана обновления ядра СУБД.

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

Diagram that shows a Database Engine Upgrade Non-HA In-Place Upgrade.

Дополнительные сведения см. в статье Обновление 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.

Примечание.

Если у вас уже есть решение высокого уровня доступности или другое несколько сред 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.

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

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

Группы доступности. Подробные инструкции по выполнению последовательного обновления в этой среде см. в разделе "Обновление экземпляров реплики группы доступности AlwaysOn"
Экземпляры отказоустойчивых кластеров. Подробное описание процедуры последовательного обновления в этой среде см. в разделе Обновление экземпляра отказоустойчивого кластера SQL Server.
Зеркальные экземпляры. Подробное описание процедуры последовательного обновления в этой среде см. в статье Обновление зеркальных экземпляров.
Экземпляры доставки журналов. Подробные инструкции по выполнению последовательного обновления в этой среде см. в статье Об обновлении доставки журналов для SQL Server (Transact-SQL)
Среда репликации. Подробное описание процедуры последовательного обновления в этой среде см. в разделе Upgrade Replicated Databases.
Масштабируемая среда SQL Server Reporting Services. Подробное описание процедуры последовательного обновления в этой среде см. в статье Обновление и перенос служб Reporting Services.