Руководство по миграции из SQL Server в Управляемый экземпляр SQL Azure

Область применения: Управляемый экземпляр SQL Azure

Из этого руководства вы узнаете, как перенести пользовательские базы данных из SQL Server в Управляемый экземпляр SQL Azure.

Выполните действия перед миграцией , прежде чем продолжить.

Миграция

После выполнения действий на этапе предварительной миграции вы будете готовы выполнить схему и миграцию данных.

Миграция данных осуществляется с использованием выбранного вами метода миграции.

В этом разделе приведены общие шаги по миграции для следующих рекомендуемых вариантов миграции:

• Ссылка управляемого экземпляра
• Служба воспроизведения журналов (LRS)
• Расширение миграции Azure SQL для Azure Data Studio — миграция с почти нулевым временем простоя.
• Исходная RESTORE DATABASE FROM URL использует исходные резервные копии из SQL Server. Использование этого метода сопряжено с некоторым простоем.

Управляемый экземпляр SQL предназначен для пользовательских сценариев, требующих массового переноса баз данных из реализаций локальной базы данных или базы данных Azure. Это оптимальный выбор, когда необходимо поднять и переместить серверную часть приложений, которые регулярно используют уровень экземпляра и (или) межбазовые функции. В этом случае вы можете переместить весь экземпляр в соответствующую среду в Azure без необходимости изменять архитектуру приложений.

Чтобы переместить экземпляры SQL, необходимо тщательно спланировать следующее:

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

Управляемый экземпляр Azure — это управляемая служба, позволяющая выполнять некоторые из обычных действий администратора базы данных на платформе, так как они встроены. Поэтому некоторые данные уровня экземпляра не нужно переносить (например, задания обслуживания для регулярных резервных копий или конфигурацию Always On). Высокий уровень доступности обеспечивается по умолчанию.

Azure Data Studio

В этом разделе приведены общие шаги по миграции из SQL Server в Управляемый экземпляр SQL Azure с минимальным временем простоя с помощью расширения миграции SQL Azure в Azure Data Studio. Подробные инструкции см. в руководстве по миграции SQL Server на Управляемый экземпляр SQL Azure в Интернете в Azure Data Studio.

Чтобы выполнить миграцию с помощью Azure Data Studio, выполните следующие действия.

1. Скачайте и установите Azure Data Studio и расширение миграции SQL Azure для Azure Data Studio.
2. Запустите мастер миграции SQL Azure в расширении в Azure Data Studio.
3. Выберите базы данных для оценки и проверьте готовность к миграции или проблемы (при их наличии). Вы также можете собрать данные производительности и получить рекомендацию Azure по выбору подходящего размера.
4. Выберите свою учетную запись Azure и целевой управляемый экземпляр SQL Azure в подписке.
5. Выберите расположение резервных копий базы данных. Резервные копии базы данных могут находиться в локальной сетевой папке или в контейнере Хранилище BLOB-объектов Azure.
6. Создайте экземпляр Azure Database Migration Service с помощью мастера в Azure Data Studio. Если вы ранее создали Службу azure Database Migration Service с помощью Azure Data Studio, вы можете повторно использовать то же самое при необходимости.
7. Необязательно. Если резервные копии находятся в локальной сетевой папке, скачайте локальную среду выполнения интеграции и установите ее на компьютере, который может подключаться к исходному экземпляру SQL Server и расположению, содержащему файлы резервной копии.
8. Начните миграцию базы данных и отслеживайте ход выполнения в Azure Data Studio. Вы также можете отслеживать ход выполнения в разделе ресурса Azure Database Migration Service на портале Azure.
9. Выполните прямую миграцию.
   1. Остановите все входящие транзакции в исходной базе данных.
   2. Внесите изменения в конфигурацию приложения, указав целевую базу данных в управляемом экземпляре SQL Azure.
   3. Перенесите все конечные фрагменты резервных копий журнала исходной базы данных в указанное расположение резервной копии.
   4. Убедитесь, что все резервные копии базы данных имеют состояние Восстановлено на странице сведений о мониторинге.
   5. На странице сведений о мониторинге щелкните Выполнить переключение.

Функция связи в Управляемом экземпляре

В этом разделе приведены общие шаги по миграции из SQL Server в Управляемый экземпляр SQL Azure с минимальным временем простоя с помощью ссылки Управляемый экземпляр. Подробные инструкции см . в разделе "Миграция" со ссылкой.

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

1. Создайте целевую Управляемый экземпляр SQL: портал Azure, PowerShell, Azure CLI.
2. Подготовьте среду для ссылки.
3. Настройте ссылку с помощью SSMS или скриптов.
4. Остановите рабочую нагрузку.
5. Проверьте данные в целевом экземпляре.
6. Отработка отказа ссылки.

Служба воспроизведения журналов (LRS)

В этом разделе приведены общие шаги по миграции из SQL Server в Управляемый экземпляр SQL Azure с минимальным временем простоя с помощью службы воспроизведения журналов (LRS). Подробные инструкции см. в статье "Миграция баз данных из SQL Server" с помощью службы воспроизведения журналов.

Чтобы выполнить миграцию с помощью LRS, выполните следующие действия.

1. Создайте учетную запись хранения Azure с контейнером BLOB-объектов.
2. Проверка подлинности в учетной записи хранения BLOB-объектов с помощью маркера SAS или управляемого удостоверения и проверки доступа.
3. Не забудьте правильно настроить структуру папок, если планируется перенести несколько баз данных.
4. Отправьте резервные копии в учетную запись хранения путем копирования резервных копий или создания резервных копий непосредственно с помощью URL-адреса BACKUP TO.
5. Определите, нужно ли запускать LRS в автоматическом или непрерывном режиме.
6. Запустите LRS.
7. Отслеживайте ход миграции.
8. Завершите миграцию (если в непрерывном режиме).

Резервное копирование и восстановление

Одна из ключевых возможностей Управляемый экземпляр SQL Azure, которая обеспечивает быструю и простую миграцию базы данных, — это собственное восстановление в управляемом экземпляре резервного копирования базы данных SQL (.bak) файлов, хранящихся в служба хранилища Azure. Резервное копирование и восстановление — это асинхронные операции, которые зависят от размера базы данных.

На следующей схеме представлен общий обзор процесса:

Примечание.

Время, необходимое для резервного копирования, передачи в службу хранилища Azure и выполнения собственной операции восстановления в Управляемом экземпляре Azure SQL, зависит от размера базы данных. Запланируйте достаточное время простоя, если база данных большая.

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

Этап	Ядро и версия SQL	Метод резервного копирования и восстановления
Размещение резервного копирования в служба хранилища Azure	До 2012 с пакетом обновления 1 (SP1) CU2	Отправка .bak файла непосредственно в служба хранилища Azure
	От 2012 SP1 CU2 до 2016	Прямое резервное копирование с использованием устаревшего синтаксиса WITH CREDENTIAL
	Версии 2016 и более поздних версий	Прямое резервное копирование с использованием синтаксиса WITH SAS CREDENTIAL
Восстановление из служба хранилища Azure в управляемый экземпляр		Восстановление на основе URL-адреса с помощью учетных данных SAS

Внимание

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

Восстановление системных баз данных не поддерживается. Чтобы перенести объекты уровня экземпляра (хранящиеся в базах данных master или msdb), рекомендуется создать для них скрипт и запустить скрипты T-SQL в экземпляре среды назначения.

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

1. Резервное копирование базы данных в Хранилище BLOB-объектов Azure. Например, используйте резервное копирование на URL-адрес в SQL Server Management Studio. Используйте средство Microsoft Azure для поддержки баз данных до версии SQL Server 2012 SP1 CU2.

2. Подключитесь к Управляемому экземпляру SQL Azure через SQL Server Management Studio.

3. Создайте учетные данные, используя подписанный URL-адрес для доступа к учетной записи хранилища BLOB-объектов Azure с резервными копиями базы данных. Например:

   CREATE CREDENTIAL [https://mitutorials.blob.core.windows.net/databases]
       WITH IDENTITY = 'SHARED ACCESS SIGNATURE',
           SECRET = '<secret>'
   

4. Восстановите резервную копию из контейнера BLOB-объектов службы хранилища Azure. Например:

   RESTORE DATABASE [TargetDatabaseName]
   FROM URL = 'https://mitutorials.blob.core.windows.net/databases/WideWorldImporters-Standard.bak'
   

5. После восстановления просмотрите базу данных в обозревателе объектов в SQL Server Management Studio.

Дополнительные сведения об этом варианте миграции см. в кратком руководстве по восстановлению базы данных в Управляемый экземпляр SQL Azure с помощью SSMS.

Примечание.

Операция восстановления базы данных является асинхронной и повторяемой. В случае разрыва подключения или истечения времени ожидания в SQL Server Management Studio может возникнуть ошибка. База данных SQL Azure будет пытаться восстановить базу данных в фоновом режиме, и вы сможете отслеживать ход восстановления с помощью представлений sys.dm_exec_requests и sys.dm_operation_status.

Синхронизация данных и прямая миграция

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

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

Внимание

Подробнее о конкретных действиях, связанных с выполнением прямой миграции при использовании DMS, см. в статье "Выполнение прямой миграции".

После миграции

После успешного завершения этапа миграции выполните ряд задач после миграции, чтобы гарантировать, что все работает гладко и эффективно.

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

Мониторинг и исправление приложений

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

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

Выполнение тестов

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

1. Разработка проверочных тестов. Чтобы протестировать перенос базы данных, необходимо использовать SQL-запросы. Необходимо создать запросы проверки, которые будут выполняться как в исходной, так и в целевой базах данных. Запросы проверки должны охватывать определенную область.
2. Настройка тестовой среды. Тестовая среда должна содержать копию исходной и целевой баз данных. Не забудьте изолировать тестовую среду.
3. Выполнение проверочных тестов. Выполните проверочные тесты для источника и целевого объекта, а затем проанализируйте результаты.
4. Выполнение тестов производительности. Запустите тест производительности для источника и целевого объекта, а затем проанализируйте и сравните результаты.

Использование дополнительных функций

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

Аналитика SQL Azure позволяет централизованно отслеживать большой набор управляемых экземпляров.

Некоторые функции SQL Server доступны только после перевода базы данных на последний уровень совместимости (150).

Связанный контент

• Службы и средства, доступные для сценариев миграции данных
• Уровни служб в Управляемом экземпляре SQL Azure
• Различия T-SQL между SQL Server и Управляемый экземпляр SQL Azure
• Калькулятор совокупной стоимости владения Azure
• Перенос баз данных с помощью расширения миграции SQL Azure для Azure Data Studio
• Руководство по переносу SQL Server на Управляемый экземпляр SQL Azure с помощью DMS
• Cloud Adoption Framework для Azure
• Рекомендации по оценке затрат на рабочие нагрузки, перенесенные в Azure, и определению их размеров
• Набор средств миграции доступа к данным (предварительная версия)
• Общие сведения о Database Experimentation Assistant