Подготовка среды для миграции связей Managed Instance — миграция SQL Server в Azure Arc

Применимо к:SQL Server

Эта статья поможет подготовить вашу среду для миграции экземпляра SQL Server, развернутого с помощью Azure Arc, на Azure SQL Managed Instance в портале Azure.

С помощью ссылки можно перенести базы данных SQL Server в Azure SQL Managed Instance с помощью репликации в режиме реального времени с распределенной группой доступности (онлайн-миграция):

Диаграмма, показывающая миграцию ссылок Managed Instance.

Замечание

Вы можете предоставить отзывы о вашем опыте миграции непосредственно в группу продуктов.
Перенос до 10 баз данных за раз, начиная с расширения Azure для версии SQL Server 1.1.3348.364.

Предпосылки

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

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

Поддерживаемые версии SQL Server

Уровни служб "Общего назначения" и "Критически важный для бизнеса" Azure SQL Managed Instance поддерживают ссылку Managed Instance. Миграция с функцией ссылки работает с выпусками SQL Server enterprise, developer и Standard на Windows Server.

В следующей таблице перечислены минимальные поддерживаемые версии SQL Server для ссылки:

версия SQL Server	Минимальное требуемое обновление обслуживания
SQL Server 2025 (17.x)	SQL Server 2025 RTM (17.0.1000.7)
SQL Server 2022 (16.x)	SQL Server 2022 RTM (16.0.1000.6)
SQL Server 2019 (15.x)	SQL Server 2019 CU20 (15.0.4312.2)
SQL Server 2017 (14.x)	SQL Server 2017 CU31 (14.0.3456.2) или более поздней версии и соответствующий пакет сборки SQL Server 2017 Azure Connect (14.0.3490.10)
SQL Server 2016 (13.x)	SQL Server 2016 с пакетом обновления 3 (SP3) (13.0.6300.2) и соответствующий сборкой SQL Server 2016 Azure Connect Pack (13.0.7000.253)
SQL Server 2014 (12.x) и более ранних версий	Версии до SQL Server 2016 не поддерживаются.

Обратная миграция поддерживается только для SQL Server 2025 и SQL Server 2022 из управляемых экземпляров SQL с соответствующей политикой update. Вы можете вручную отменить миграцию с помощью других средств, таких как собственное резервное копирование и восстановление, или вручную настроить ссылку в SSMS.

Permissions

В этом разделе описываются разрешения, необходимые для переноса экземпляра SQL Server на SQL Managed Instance через портал Azure.

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

Если включить минимальные привилегии, необходимые разрешения, такие как sysadmin , предоставляются по мере необходимости во время процесса миграции базы данных.
Если вы не можете использовать минимальные привилегии, пользователь, выполняет миграцию, должен иметь sysadmin разрешение на экземпляре SQL Server. Кроме того, если необходимо отменить миграцию, также вручную назначьте разрешения sysadmin учетной NT AUTHORITY\SYSTEM записи.

Чтобы перенести ссылку Managed Instance, вам потребуется одно из следующих разрешений для целевого объекта SQL Managed Instance:

роль SQL Managed Instance участника
Роль участника уровня подписки или роль владельца

Минимальные разрешения см. в разделе "Пользовательские разрешения".

Замечание

Пользователи с SqlServerAvailabilityGroups_CreateManagedInstanceLink, SqlServerAvailabilityGroups_failoverMiLink, и SqlServerAvailabilityGroups_deleteMiLink разрешениями в Azure могут выполнять действия на панели миграции базы данных во время процесса миграции, повышая разрешения SQL Server учетной записи, используемой расширением, включая роль .

Сопоставление производительности между репликами

При использовании функции связи важно согласовать производительность между системами SQL Server и SQL Managed Instance. Это сопоставление помогает избежать снижения производительности, если вторичная реплика не может поддерживать репликацию из первичной реплики или после аварийного переключения. Емкость производительности включает ядра ЦП (или виртуальные ядра в Azure), память и пропускную способность ввода-вывода.

Подготовка экземпляра SQL Server

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

Убедитесь, что вы находитесь в поддерживаемой версии.
Создайте главный ключ базы данных в master базе данных.
Включите функцию групп доступности.
Добавьте правильные флаги трассировки при запуске.
Restart SQL Server и проверьте конфигурацию.
Задайте для базы данных полную модель восстановления.
Импорт ключей корневого центра сертификации, доверенных Azure, в SQL Server.
Включите ускоренное восстановление базы данных, если используете SQL Server версии 2019 или более поздней, и планируете его использовать в целевом управляемом экземпляре SQL.
Включите Service Broker , если планируете использовать его в целевом управляемом экземпляре SQL.

Чтобы эти изменения вступили в силу, необходимо restart SQL Server.

Установка обновлений службы

Убедитесь, что у SQL Server установлена соответствующая версия обновления обслуживания, как указано в таблице поддержки version supportability. Если необходимо установить обновления, необходимо перезапустить экземпляр SQL Server во время обновления.

Чтобы проверить версию SQL Server, выполните следующий скрипт Transact-SQL (T-SQL) в SQL Server:

-- Run on SQL Server
-- Shows the version and CU of the SQL Server
USE master;
GO
SELECT @@VERSION as 'SQL Server version';

Создайте главный ключ базы данных в базе данных master

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

Создайте главный ключ базы данных в master базе данных. Вставьте пароль вместо следующего скрипта <strong_password> и сохраните его в конфиденциальном и безопасном месте. Запустите этот скрипт T-SQL в SQL Server:

-- Run on SQL Server
-- Create a master key
USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<strong_password>';

Чтобы убедиться, что у вас есть главный ключ базы данных, используйте следующий скрипт T-SQL в SQL Server:

-- Run on SQL Server
USE master;
GO
SELECT * FROM sys.symmetric_keys WHERE name LIKE '%DatabaseMasterKey%';

Подготовка экземпляров SQL Server 2016

Для SQL Server 2016 (13.x) необходимо выполнить дополнительные действия, описанные в Prepare SQL Server 2016 предварительных условий для получения ссылки. Эти дополнительные шаги не требуются для SQL Server 2017 (14.x) и более поздних версий, поддерживаемых ссылкой.

Включение групп доступности

Функция ссылки использует функцию групп доступности AlwaysOn, которая по умолчанию отключена. Дополнительные сведения см. в разделе "Включить групп доступности AlwaysOn".

Чтобы убедиться, что функция групп доступности включена, выполните следующий скрипт T-SQL в SQL Server:

-- Run on SQL Server
-- Is the availability groups feature enabled on this SQL Server
DECLARE @IsHadrEnabled sql_variant = (select SERVERPROPERTY('IsHadrEnabled'))
SELECT
    @IsHadrEnabled as 'Is HADR enabled',
    CASE @IsHadrEnabled
        WHEN 0 THEN 'Availability groups DISABLED.'
        WHEN 1 THEN 'Availability groups ENABLED.'
        ELSE 'Unknown status.'
    END
    as 'HADR status'

Если функция групп доступности не включена, выполните следующие шаги, чтобы её включить:

Откройте SQL Server Configuration Manager.
Выберите SQL Server Services на левой панели.
Щелкните правой кнопкой мыши службу SQL Server, а затем выберите Properties:
Перейдите на вкладку Группы доступности Always On.
Установите флажок "Включить группы доступности AlwaysOn ", а затем нажмите кнопку "ОК".
- Если вы используете SQL Server 2016 (13.x), и параметр Enable Always On Availability Groups отключен с сообщением This computer is not a node in a failover cluster, выполните действия, описанные в разделе Подготовка предварительных условий для SQL Server 2016 для ссылки. После выполнения этих действий вернитесь к этому шагу и повторите попытку.
Нажмите кнопку "ОК " в диалоговом окне.
Перезапустите службу SQL Server.

Включите флаги трассировки запуска

Чтобы оптимизировать производительность ссылки, включите следующие флаги трассировки при запуске:

-T1800: этот флаг трассировки оптимизирует производительность, если файлы журнала для основных и вторичных реплик в группе доступности находятся на дисках с разными размерами сектора, такими как 512 байтов и 4 КБ. Если первичные и вторичные реплики используют размер сектора диска размером 4 КБ, этот флаг трассировки не нужен. Дополнительные сведения см. здесь: KB3009974.
-T9567. Этот флаг трассировки включает сжатие потока данных для групп доступности во время автоматического заполнения. Сжатие увеличивает нагрузку на процессор, но может значительно сократить время передачи во время посева.

Чтобы включить эти флаги трассировки при запуске, сделайте следующее:

Откройте SQL Server Configuration Manager.
Выберите SQL Server Services на левой панели.
Щелкните правой кнопкой мыши службу SQL Server, а затем выберите Properties.
Перейдите на вкладку Параметры запуска. В поле Укажите параметр запуска введите -T1800 и выберите Добавить, чтобы добавить параметр запуска. Затем введите -T9567 и выберите команду Добавить, чтобы добавить другой флаг трассировки. Щелкните Применить, чтобы сохранить изменения.
Щелкните OK, чтобы закрыть окно Свойства.

Для получения дополнительной информации см. синтаксис включения флагов трассировки.

Перезапустите SQL Server и проверьте конфигурацию

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

Убедившись, что вы используете поддерживаемую версию SQL Server, включите функцию групп доступности AlwaysOn и добавьте флаги трассировки запуска, перезапустите экземпляр SQL Server, чтобы применить все эти изменения:

Откройте SQL Server Configuration Manager.
Выберите SQL Server Services на левой панели.
Щелкните правой кнопкой мыши службу SQL Server, а затем выберите Restart.

После перезагрузки выполните следующий скрипт T-SQL в SQL Server, чтобы проверить конфигурацию экземпляра SQL Server:

-- Run on SQL Server
-- Shows the version and CU of SQL Server
USE master;
GO
SELECT @@VERSION as 'SQL Server version';
GO
-- Shows if the Always On availability groups feature is enabled
SELECT SERVERPROPERTY ('IsHadrEnabled') as 'Is Always On enabled? (1 true, 0 false)';
GO
-- Lists all trace flags enabled on SQL Server
DBCC TRACESTATUS;

Ваша SQL Server версия должна быть одной из поддерживаемых версий с соответствующими обновлениями службы. Функция групп доступности AlwaysOn должна быть включена, и флаги трассировки -T1800 и -T9567 также должны быть включены. На следующем снимок экрана показан пример ожидаемого результата для правильно настроенного экземпляра SQL Server:

Снимок экрана с ожидаемым результатом в S S M S.

Настройка модели полного восстановления базы данных

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

Выполните следующий код в SQL Server для всех баз данных, которые вы хотите перенести. Замените <DatabaseName> фактическим именем базы данных.

-- Run on SQL Server
-- Set full recovery model for all databases you want to migrate.
ALTER DATABASE [<DatabaseName>] SET RECOVERY FULL
GO

-- Execute backup for all databases you want to migrate.
BACKUP DATABASE [<DatabaseName>] TO DISK = N'<DiskPath>'
GO

Импорт ключей доверенного корневого центра сертификации Azure в SQL Server

Чтобы доверять сертификатам открытого ключа, выпущенным Azure для SQL Managed Instance, необходимо импортировать ключи доверенного корневого центра сертификации (ЦС) Azure в SQL Server.

Ключи корневого УЦ можно скачать из информация о центре сертификации Azure. По крайней мере скачайте DigiCert Global Root G2 и Microsoft корневой центр сертификации RSA 2017 и импортируйте их в экземпляр SQL Server.

Замечание

Корневой сертификат в цепочке сертификации для сертификата открытого ключа SQL Managed Instance выдан доверенным корневым центром сертификации (ЦС) Azure. Определенный корневой ЦС может измениться с течением времени, так как Azure обновляет список доверенных ЦС. Для упрощенной настройки установите все сертификаты корневого ЦС, перечисленные в Корневые центры сертификации Azure. Вы можете установить только необходимый ключ ЦС, установив издателя открытого ключа SQL Managed Instance, импортированного ранее.

Сохраните сертификаты локально в экземпляре SQL Server, например в примере пути C:\certs\<name of certificate>.crt, а затем импортируйте сертификаты из этого пути с помощью следующего скрипта Transact-SQL. Замените <name of certificate> фактическим именем сертификата: DigiCert Global Root G2 и Microsoft RSA Root Certificate Authority 2017, которые являются обязательными именами этих двух сертификатов.

-- Run on SQL Server-- Import <name of certificate> root-authority certificate (trusted by Azure), if not already present
CREATE CERTIFICATE [DigiCertPKI] FROM FILE = 'C:\certs\DigiCertGlobalRootG2.crt'
DECLARE @CERTID int
SELECT @CERTID = CERT_ID('DigiCertPKI')
EXEC sp_certificate_add_issuer @CERTID, N'*.database.windows.net';
GO
CREATE CERTIFICATE [MicrosoftPKI] FROM FILE = 'C:\certs\Microsoft RSA Root Certificate Authority 2017.crt'
DECLARE @CERTID int
SELECT @CERTID = CERT_ID('MicrosoftPKI')
EXEC sp_certificate_add_issuer @CERTID, N'*.database.windows.net';
GO

Подсказка

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

Наконец, проверьте все созданные сертификаты с помощью следующего динамического административного представления (DMV):

-- Run on SQL Server
USE master
SELECT * FROM sys.certificates

Включение ускоренного восстановления базы данных

Для SQL Server 2019 и более поздних версий включите функцию ускоренного восстановления базы данных и убедитесь, что для хранилища постоянных версий (PVS) задано значение . Если ускоренное восстановление базы данных не включено в исходной SQL Server базе данных, его нельзя включить в целевом управляемом экземпляре SQL после миграции базы данных. Если хранилище постоянных версий (PVS) не задано PRIMARY, возникают проблемы при выполнении операций восстановления в целевом управляемом экземпляре SQL.

Для SQL Server 2017 и более ранних версий ускорение восстановления базы данных не поддерживается, поэтому этот шаг не нужен.

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

Включите ускоренное восстановление базы данных, выполнив следующий скрипт Transact-SQL в SQL Server:
```
ALTER DATABASE [<database name>] SET ACCELERATED_DATABASE_RECOVERY = ON;
```
Хранилище постоянных версий (PVS) должно иметь PRIMARY значение в исходной базе данных, которая является конфигурацией по умолчанию. Если это было изменено ранее, перед началом миграции необходимо изменить его обратно на PRIMARY .

Включение компонента Service Broker

Service Broker включен по умолчанию для всех версий SQL Server. Если компонент Service Broker отключен и вы планируете использовать его в SQL Managed Instance, включите Service Broker в исходной базе данных SQL Server перед миграцией на SQL Managed Instance. Если компонент Service Broker не включен в исходной базе данных SQL Server, его нельзя использовать в целевом управляемом экземпляре SQL.

Чтобы проверить, включен ли Компонент Service Broker, выполните следующий скрипт Transact-SQL в экземпляре SQL Server:

SELECT name AS [Database Name], is_broker_enabled AS [Service Broker Enabled]
FROM sys.databases
WHERE name = '<database name>';

Если компонент Service Broker отключен, включите его, выполнив следующий скрипт Transact-SQL в исходной базе данных SQL Server:

USE master;
GO

ALTER DATABASE [<database name>]
    SET ENABLE_BROKER;
GO

Настройка сетевого подключения

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

SQL Server за пределами Azure

Если вы размещаете экземпляр SQL Server за пределами Azure, можно установить VPN-подключение между SQL Server и SQL Managed Instance с помощью одного из следующих вариантов:

Подсказка

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

SQL Server на виртуальных машинах Azure

Развертывание SQL Server на виртуальных машинах Azure в той же виртуальной сети Azure, где размещен SQL Managed Instance, является самым простым методом, так как сетевое подключение между двумя экземплярами устанавливается автоматически. Дополнительные сведения см. в разделе Quickstart: настройка виртуальной машины Azure для подключения к Azure SQL Managed Instance.

Если экземпляр SQL Server on Azure Virtual Machines находится в другой виртуальной сети из управляемого экземпляра SQL, необходимо подключить две виртуальные сети. Виртуальные сети не должны находиться в одной подписке, чтобы этот сценарий работал.

У вас есть два варианта подключения виртуальных сетей:

Пиринг виртуальных сетей Azure
VPN-шлюз VNet-to-VNet (портал Azure, PowerShell, Azure CLI)

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

Сетевые порты между средами

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

Правила группы безопасности сети (NSG) в подсети, в которую размещаются SQL Managed Instance, должны разрешать:

Входящий порт 5022 и диапазон портов 11000–11999 для получения трафика от исходного SQL Server IP-адреса
Исходящий порт 5022 для отправки трафика в целевой SQL Server IP-адрес

Порт 5022 нельзя изменить на SQL Managed Instance.

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

Входящий порт 5022 открыт для получения трафика из исходного диапазона IP-адресов подсети MI /24 (например, 10.0.0.0/24)
Исходящие порты 5022 и диапазон портов 11000-11999, открытый для отправки трафика в диапазон IP-адресов целевой подсети MI (например, 10.0.0.0/24)

Порт 5022 можно настроить на стороне SQL Server, но диапазон портов 11000-11999 должен быть открыт как есть.

В таблице ниже описаны действия портов для каждой среды.

Окружающая среда	Что следует делать
SQL Server (вне Azure)	Откройте входящий и исходящий трафик через порт 5022 для брандмауэра сети для всего диапазона IP-адресов подсети SQL Managed Instance. При необходимости выполните то же самое в брандмауэре Windows операционной системы хоста SQL Server.
SQL Server (в Azure)	Откройте входящий и исходящий трафик через порт 5022 для брандмауэра сети для всего диапазона IP-адресов подсети SQL Managed Instance. При необходимости выполните то же самое в брандмауэре Windows операционной системы хоста SQL Server. Чтобы разрешить обмен данными через порт 5022, создайте правило группы безопасности сети (NSG) в виртуальной сети, на котором размещена виртуальная машина.
SQL Managed Instance	Создайте правило NSG в портале Azure, чтобы разрешить входящий и исходящий трафик с IP-адреса и сети, в которой размещается SQL Server на порте 5022 и диапазоне портов 11000–11999.

Чтобы открыть порты в брандмауэре Windows, используйте следующий сценарий PowerShell в ОС узла Windows экземпляра SQL Server:

New-NetFirewallRule -DisplayName "Allow TCP port 5022 inbound" -Direction inbound -Profile Any -Action Allow -LocalPort 5022 -Protocol TCP
New-NetFirewallRule -DisplayName "Allow TCP port 5022 outbound" -Direction outbound -Profile Any -Action Allow -LocalPort 5022 -Protocol TCP

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

Это важно

Необходимо открыть порты в каждом брандмауэре в сетевой среде, включая сервер узла, а также любые корпоративные брандмауэры или шлюзы в сети. В корпоративных средах может потребоваться показать администратору сети сведения в этом разделе, чтобы открыть дополнительные порты на корпоративном сетевом уровне.
Хотя вы можете настроить конечную точку на стороне SQL Server, вы не можете изменить или настроить номера портов для SQL Managed Instance.
Диапазоны IP-адресов подсетей, в которые размещаются управляемые экземпляры, и SQL Server не должны перекрываться.

Добавление URL-адресов в список разрешённых

В зависимости от параметров безопасности сети может потребоваться добавить URL-адреса в список разрешений для полного доменного имени SQL Managed Instance и некоторых конечных точек управления ресурсами, используемых Azure.

Добавьте следующие ресурсы в список разрешений:

Полное доменное имя (FQDN) вашего управляемого экземпляра SQL. Например: managedinstance.a1b2c3d4e5f6.database.windows.net.
орган Microsoft Entra
Идентификатор ресурса конечной точки Microsoft Entra
Конечная точка диспетчера ресурсов
Конечная точка сервиса

Выполните действия, описанные в разделе Configure SSMS для облачных служб для государственных организаций, чтобы получить доступ к интерфейсу Tools в SQL Server Management Studio (SSMS) и определить конкретные URL-адреса ресурсов в облаке, которые необходимо добавить в список разрешений.

Перенос сертификата защищенной TDE базы данных (необязательно)

Если вы связываете базу данных SQL Server, защищенную Transparent Data Encryption (TDE) с управляемым экземпляром SQL, перед использованием ссылки необходимо перенести соответствующий сертификат шифрования из локального или Azure экземпляра виртуальной машины SQL Server в управляемый экземпляр SQL. Подробные инструкции см. в разделе Миграция сертификата базы данных, защищенной с помощью TDE, в Azure SQL Managed Instance.

SQL Managed Instance базы данных, зашифрованные с помощью ключей TDE, управляемых службой, не могут быть связаны с SQL Server. Вы можете связать зашифрованную базу данных только с SQL Server, если вы зашифровали его с помощью управляемого клиентом ключа, а целевой сервер имеет доступ к тому же ключу, который используется для шифрования базы данных. Дополнительные сведения см. в разделе Set up SQL Server TDE with Azure Key Vault.

Замечание

Azure Key Vault теперь поддерживается в SQL Server на Linux начиная с Cumulative Update 14 для SQL Server 2022.

Проверка сетевого подключения

Перед началом миграции проверьте сетевое подключение между экземпляром SQL Server и SQL Managed Instance. Вы можете проверить подключение непосредственно на портале Azure в рамках процесса миграции. Однако можно также проверить подключение вручную с помощью Transact-SQL и SQL Server Agent. Дополнительные сведения см. в разделе "Тестирование сетевого подключения".

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

Выберите Миграция данных на панели Миграция базы данных для ресурса экземпляра SQL Server.
Выберите опцию MI ссылка.
Выберите целевые базы данных, которые вы хотите перенести, а затем используйте Дальше: Параметры для перехода на следующую вкладку.
На вкладке "Параметры" укажите имя ссылки и исходную группу доступности. Затем используйте Test connection для проверки соединения между SQL Server и SQL Managed Instance.

Рассмотрим следующие моменты:

Чтобы избежать ложных отрицательных значений, все брандмауэры по сетевому пути должны разрешать трафик протокола ICMP.
Чтобы избежать ложных срабатываний, все брандмауэры по сетевому пути должны разрешать трафик по закрытому протоколу SQL Server UCS. Блокировка протокола может привести к успешному тестированию подключения, но соединение создать не удается.
Дополнительные настройки межсетевого экрана с ограничителями уровня пакетов должны быть правильно выполнены, чтобы разрешить трафик между SQL Server и SQL Managed Instance.

Ограничения

Необходимо учитывать следующие ограничения.

Ограничения ссылки Managed Instance применяются к миграциям через портал Azure.
расширение Azure для SQL Server версии 1.1.3238.349 и более ранних поддерживает миграцию только одной базы данных одновременно через ссылку. Чтобы перенести несколько баз данных одновременно, обновите расширение Azure для SQL Server версии 1.1.3348.364 или более поздней.
Для отмены миграции требуются разрешения sysadmin для исходного экземпляра SQL Server. Если экземпляр SQL Server не использует минимальные привилегии, вручную назначьте разрешения sysadmin для учетной записи NT AUTHORITY\SYSTEM.
Настройка ссылки с помощью портала Azure для миграции несовместима с ссылками, созданными вручную, с помощью SQL Server Management Studio (SSMS) или Transact-SQL (T-SQL). Ознакомьтесь с известной проблемой , чтобы узнать больше.
Мониторинг миграции с помощью портала Azure доступен только для SQL Server экземпляров, которые соответствуют требованиям мониторинга лицензирования.

Устранение распространенных неполадок

См. раздел устранение проблем при миграции для устранения распространенных проблем при миграции на Azure SQL Managed Instance.

Следующий шаг

Миграция в Azure SQL Managed Instance

Кері байланыс

Бет пайдалы болды ма?

Last updated on 2026-04-22

Подготовка среды для миграции связей Managed Instance — миграция SQL Server в Azure Arc

Предпосылки

Поддерживаемые версии SQL Server

Permissions

Сопоставление производительности между репликами

Подготовка экземпляра SQL Server

Установка обновлений службы

Создайте главный ключ базы данных в базе данных master

Подготовка экземпляров SQL Server 2016

Включение групп доступности

Включите флаги трассировки запуска

Перезапустите SQL Server и проверьте конфигурацию

Настройка модели полного восстановления базы данных

Импорт ключей доверенного корневого центра сертификации Azure в SQL Server

Включение ускоренного восстановления базы данных

Включение компонента Service Broker

Настройка сетевого подключения

SQL Server за пределами Azure

SQL Server на виртуальных машинах Azure

Сетевые порты между средами

Добавление URL-адресов в список разрешённых

Перенос сертификата защищенной TDE базы данных (необязательно)

Проверка сетевого подключения

Ограничения

Устранение распространенных неполадок

Следующий шаг

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

Кері байланыс

Қосымша ресурстар