Подготовка среды к ссылке — Azure SQL Managed Instance

Применимо к:Azure SQL Managed Instance

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

Примечание.

Вы можете автоматизировать подготовку среды для ссылки Managed Instance с помощью скачиваемого скрипта. Дополнительные сведения см. в блоге об автоматизации настройки ссылок.

Требования

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

• Активная подписка Azure. Если ее нет, создайте бесплатную учетную запись.
• Версия поддерживаемого SQL Server с требуемым обновлением службы.
• Azure SQL Managed Instance с соответствующей политикой обновления. Начните если у вас его нет.
• Сервер, который вы планируете использовать как основной в начальной конфигурации. Этот выбор определяет, откуда следует создать ссылку.
  • Настройка ссылки от основного экземпляра SQL Managed Instance к вторичному экземпляру SQL Server 2025 поддерживается только с управляемыми экземплярами SQL, которые настроены с политикой обновления SQL Server 2025.
  • Настройка ссылки от основного экземпляра SQL Managed Instance к вторичному серверу SQL Server 2022 поддерживается только начиная с SQL Server 2022 CU10 и для управляемых экземпляров SQL, настроенных в соответствии с политикой обновления SQL Server 2022.

Внимание

При создании управляемого экземпляра SQL для использования с функцией связывания учитывайте требования к памяти для любых функций In-Memory OLTP (онлайн-обработка транзакций), используемых в SQL Server. Дополнительную информацию см. в разделе Обзор ограничений ресурсов Azure SQL Managed Instance.

Разрешения

Для SQL Server необходимо иметь разрешения sysadmin.

Для Azure SQL Managed Instance вы должны быть членом SQL Managed Instance Contributor или иметь следующие разрешения для создания пользовательской роли:

Microsoft.Sql/resource	Необходимые разрешения
Microsoft. Sql/managedInstances	/чтение, /запись
Microsoft.Sql/managedInstances/hybridCertificate	/действие
Microsoft. Sql/managedInstances/databases	/просмотр, /удалить, /записать, /полноеВосстановление/действие, /просмотрРезервныхКопий/действие, /подробностиВосстановления/просмотр
Microsoft.Sql/managedInstances/distributedAvailabilityGroups	/читать, /писать, /удалить, /установитьРоль/действие
Microsoft.Sql/managedInstances/endpointCertificates	/читать
Microsoft.Sql/managedInstances/hybridLink	/рид (read), /райт (write), /делит (delete)
Microsoft. Sql/managedInstances/serverTrustCertificates	/записать, /удалить, /прочитать

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

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

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

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

• Вы используете минимальную поддерживаемую версию.
• Вы создали главный ключ базы данных в master базе данных.
• Вы включили функцию групп доступности.
• Вы добавили соответствующие флаги трассировки при запуске.
• Резервные копии используют контрольные суммы.
• Вы включили ускоренное восстановление базы данных, если вы используете SQL Server 2019 или более поздней версии, и планируете использовать его в целевом управляемом экземпляре SQL.
• Если вы планируете использовать его в целевом управляемом экземпляре SQL, вы включили Service Broker .

Чтобы эти изменения вступили в силу, необходимо перезапустить 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%';

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

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

Примечание.

Для получения информации о SQL Server на Linux см. в разделе Enable Always On группы доступности.

Чтобы убедиться, что функция групп доступности включена, выполните следующий скрипт 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 2016 (13.x), если необходимо включить функцию групп доступности, необходимо выполнить дополнительные действия, описанные в Prepare SQL Server 2016 предварительные требования — Azure SQL Managed Instance ссылке. Эти дополнительные шаги не требуются для SQL Server 2017 (14.x) и более поздних версий, поддерживаемых ссылкой.

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

1. Откройте SQL Server Configuration Manager.

2. Выберите SQL Server Services на левой панели.

3. Щелкните правой кнопкой мыши службу SQL Server и выберите Properties.

   

4. Перейдите на вкладку Группы доступности Always On.

5. Выберите флажок "Включить Always On Availability Groups", затем выберите ОК.

   

   • Если используется SQL Server 2016 (13.x) и если параметр Enable Always On Availability Groups отключен с сообщением This computer is not a node in a failover cluster, выполните дополнительные действия, описанные по ссылке на странице Prepare SQL Server 2016 prerequisites - Azure SQL Managed Instance. Завершив эти другие действия, вернитесь и повторите этот шаг снова.

6. Нажмите кнопку "ОК " в диалоговом окне.

7. Перезапустите службу SQL Server.

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

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

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

Примечание.

Сведения о SQL Server на Linux см. в разделе Включение флагов трассировки.

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

1. Откройте SQL Server Configuration Manager.

2. Выберите SQL Server Services на левой панели.

3. Щелкните правой кнопкой мыши службу SQL Server и выберите Properties.

   

4. Перейдите на вкладку Параметры запуска. В поле Укажите параметр запуска введите -T1800 и выберите Добавить, чтобы добавить параметр запуска. Затем введите -T9567 и выберите команду Добавить, чтобы добавить другой флаг трассировки. Щелкните Применить, чтобы сохранить изменения.

   

5. Щелкните OK, чтобы закрыть окно Свойства.

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

Используйте резервные копии с контрольными суммами

При создании ссылки начальное заполнение между первичной и вторичной репликами выполняется путем создания полной резервной копии базы данных на первичной реплике, передачи ее в вторичную реплику и восстановления там. При выполнении полной резервной копии, мы рекомендуем использовать параметр WITH CHECKSUM, чтобы убедиться, что резервная копия действительна и не повреждена. Дополнительные сведения см. в разделе BACKUP (Transact-SQL).

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

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

1. Откройте SQL Server Configuration Manager.

2. Выберите SQL Server Services на левой панели.

3. Щелкните правой кнопкой мыши службу 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:

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

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

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

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

1. Включите ускоренное восстановление базы данных, выполнив следующий скрипт Transact-SQL в SQL Server:

   ALTER DATABASE [<database name>] SET ACCELERATED_DATABASE_RECOVERY = ON;
   

2. Хранилище постоянных версий (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 on Azure Virtual Machines в той же виртуальной сети Azure, на котором SQL Managed Instance, является самым простым методом, так как сетевое подключение автоматически существует между двумя экземплярами. Дополнительные сведения см. в разделе Quickstart: настройка виртуальной машины Azure для подключения к Azure SQL Managed Instance.

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

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

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

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

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

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

• VPN-подключение "сеть —сеть";
• Azure ExpressRoute подключение

Совет

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

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

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

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

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

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

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

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

Окружающая среда	Что следует делать
SQL Server (в Azure)	Откройте входящий и исходящий трафик через порт 5022 для брандмауэра сети для всего диапазона IP-адресов подсети SQL Managed Instance. При необходимости сделайте то же самое в брандмауэре операционной системы хоста SQL Server (Windows/Linux). Чтобы разрешить обмен данными через порт 5022, создайте правило группы безопасности сети (NSG) в виртуальной сети, на котором размещена виртуальная машина.
SQL Server (вне Azure)	Откройте входящий и исходящий трафик через порт 5022 для брандмауэра сети для всего диапазона IP-адресов подсети SQL Managed Instance. При необходимости сделайте то же самое в брандмауэре операционной системы хоста SQL Server (Windows/Linux).
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-адреса ресурсов в облаке, которые необходимо добавить в список разрешений.

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

Двунаправленное сетевое подключение между SQL Server и SQL Managed Instance необходимо для работы связи. После открытия портов на стороне SQL Server и настройки правила NSG на стороне SQL Managed Instance проверьте подключение с помощью SQL Server Management Studio (SSMS) или Transact-SQL.

Проверьте сеть, создав временное задание агента SQL как в SQL Server, так и в SQL Managed Instance, чтобы проверить подключение между двумя экземплярами. При использовании средства проверки сети в SSMS задание автоматически создается и удаляется после завершения теста. При тестировании сети с помощью T-SQL необходимо вручную удалить задание агента SQL.

Примечание.

Выполнение скриптов PowerShell с помощью SQL Server Agent на SQL Server в Linux в настоящее время не поддерживается, поэтому невозможно выполнить Test-NetConnection из задания SQL Server Agent на SQL Server в Linux.

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

• Пользователь, выполняющий тест, должен иметь разрешения для создания задания (либо как системный администратор, либо принадлежать роли SQLAgentOperator для msdb) для как SQL Server, так и SQL Managed Instance.
• Служба SQL Server Agent должна быть запущена на SQL Server. Так как агент по умолчанию включен в SQL Managed Instance, никаких дополнительных действий не требуется.

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

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

SSMS

Чтобы проверить сетевое подключение между SQL Server и SQL Managed Instance в SSMS, выполните следующие действия.

1. Подключитесь к экземпляру, который будет основной репликой в SSMS.

2. В Object Explorer разверните базы данных и щелкните правой кнопкой мыши базу данных, которую вы собираетесь связать со вторичной. Выберите Tasks>Azure SQL Managed Instance link>Test Connection, чтобы открыть мастер проверки Network Checker:

   

3. Нажмите кнопку "Далее" на странице "Введение" мастера проверки сети.

4. Если все требования выполнены на странице "Предварительные требования" , нажмите кнопку "Далее". В противном случае устраните любые неудовлетворенные требования, а затем выберите Повторная проверка.

5. На странице входа выберите "Войти", чтобы подключиться к другому экземпляру, который будет вторичной репликой. Выберите Далее.

6. При необходимости проверьте сведения на странице "Указать параметры сети" и укажите IP-адрес. Выберите Далее.

7. На странице "Сводка" просмотрите действия мастера, а затем нажмите кнопку "Готово", чтобы проверить подключение между двумя репликами.

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

T-SQL

Чтобы использовать T-SQL для проверки подключения, необходимо проверить подключение в обоих направлениях. Сначала проверьте подключение из SQL Server на SQL Managed Instance, а затем проверьте подключение из SQL Managed Instance на SQL Server.

Тестирование подключения из SQL Server в SQL Managed Instance

Используйте SQL Server Agent в SQL Server для выполнения тестов подключения из SQL Server в SQL Managed Instance.

1. Подключитесь к SQL Managed Instance и запустите следующий скрипт, чтобы создать параметры, которые потребуются позже:

   SELECT 'DECLARE @serverName NVARCHAR(512) = N''' + value + ''''
   FROM sys.dm_hadr_fabric_config_parameters
   WHERE parameter_name = 'DnsRecordName'
   
   UNION
   
   SELECT 'DECLARE @node NVARCHAR(512) = N''' + NodeName + '.' + Cluster + ''''
   FROM (
       SELECT SUBSTRING(replica_address, 0, CHARINDEX('\', replica_address)) AS NodeName,
           RIGHT(service_name, CHARINDEX('/', REVERSE(service_name)) - 1) AppName,
           JoinCol = 1
       FROM sys.dm_hadr_fabric_partitions fp
       INNER JOIN sys.dm_hadr_fabric_replicas fr
           ON fp.partition_id = fr.partition_id
       INNER JOIN sys.dm_hadr_fabric_nodes fn
           ON fr.node_name = fn.node_name
       WHERE service_name LIKE '%ManagedServer%'
           AND replica_role = 2
   ) t1
   LEFT JOIN (
       SELECT value AS Cluster,
           JoinCol = 1
       FROM sys.dm_hadr_fabric_config_parameters
       WHERE parameter_name = 'ClusterName'
       ) t2
       ON (t1.JoinCol = t2.JoinCol)
   INNER JOIN (
       SELECT [value] AS AppName
       FROM sys.dm_hadr_fabric_config_parameters
       WHERE section_name = 'SQL'
           AND parameter_name = 'InstanceName'
       ) t3
       ON (t1.AppName = t3.AppName)
   
   UNION
   
   SELECT 'DECLARE @port NVARCHAR(512) = N''' + value + ''''
   FROM sys.dm_hadr_fabric_config_parameters
   WHERE parameter_name = 'HadrPort';
   

   Результаты должны выглядеть следующим образом:

    DECLARE @node NVARCHAR(512) = N'DB123.tr123456.west-us.worker.database.windows.net'
    DECLARE @port NVARCHAR(512) = N'11002'
    DECLARE @serverName NVARCHAR(512) = N'contoso-instance.12345678.database.windows.net'
   

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

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

3. Откройте новое окно запроса и вставьте следующий скрипт:

   --START
   -- Parameters section
   DECLARE @node NVARCHAR(512) = N''
   DECLARE @port NVARCHAR(512) = N''
   DECLARE @serverName NVARCHAR(512) = N''
   
   --Script section
   IF EXISTS (
           SELECT job_id
           FROM msdb.dbo.sysjobs_view
           WHERE name = N'TestMILinkConnection'
           )
       EXEC msdb.dbo.sp_delete_job @job_name = N'TestMILinkConnection',
           @delete_unused_schedule = 1
   
   DECLARE @jobId BINARY (16),
       @cmd NVARCHAR(MAX)
   
   EXEC msdb.dbo.sp_add_job @job_name = N'TestMILinkConnection',
       @enabled = 1,
       @job_id = @jobId OUTPUT
   
   SET @cmd = (N'tnc ' + @serverName + N' -port 5022 | select ComputerName, RemoteAddress, TcpTestSucceeded | Format-List')
   
   EXEC msdb.dbo.sp_add_jobstep @job_id = @jobId,
       @step_name = N'Test Port 5022',
       @step_id = 1,
       @cmdexec_success_code = 0,
       @on_success_action = 3,
       @on_fail_action = 3,
       @subsystem = N'PowerShell',
       @command = @cmd,
       @database_name = N'master'
   
   SET @cmd = (N'tnc ' + @node + N' -port ' + @port + ' | select ComputerName, RemoteAddress, TcpTestSucceeded | Format-List')
   
   EXEC msdb.dbo.sp_add_jobstep @job_id = @jobId,
       @step_name = N'Test HADR Port',
       @step_id = 2,
       @cmdexec_success_code = 0,
       @subsystem = N'PowerShell',
       @command = @cmd,
       @database_name = N'master'
   
   EXEC msdb.dbo.sp_add_jobserver @job_id = @jobId,
       @server_name = N'(local)'
   GO
   
   EXEC msdb.dbo.sp_start_job @job_name = N'TestMILinkConnection'
   GO
   
   --Check status every 5 seconds
   DECLARE @RunStatus INT
   
   SET @RunStatus = 10
   
   WHILE (@RunStatus >= 4)
   BEGIN
       SELECT DISTINCT @RunStatus = run_status
       FROM [msdb].[dbo].[sysjobhistory] JH
       INNER JOIN [msdb].[dbo].[sysjobs] J
           ON JH.job_id = J.job_id
       WHERE J.name = N'TestMILinkConnection'
           AND step_id = 0
   
       WAITFOR DELAY '00:00:05';
   END
   
   --Get logs once job completes
   SELECT [step_name],
       SUBSTRING([message], CHARINDEX('TcpTestSucceeded', [message]), CHARINDEX('Process Exit', [message]) - CHARINDEX('TcpTestSucceeded', [message])) AS    TcpTestResult,
       SUBSTRING([message], CHARINDEX('RemoteAddress', [message]), CHARINDEX('TcpTestSucceeded', [message]) - CHARINDEX('RemoteAddress', [message])) AS    RemoteAddressResult,
       [run_status],
       [run_duration],
       [message]
   FROM [msdb].[dbo].[sysjobhistory] JH
   INNER JOIN [msdb].[dbo].[sysjobs] J
       ON JH.job_id = J.job_id
   WHERE J.name = N'TestMILinkConnection'
       AND step_id <> 0
       --END
   

4. Замените параметры @node, @port и @serverName значениями, полученными на первом шаге.

5. Запустите скрипт и проверьте результаты. Вы должны увидеть результаты, подобные следующему примеру:

   

6. Проверьте результаты:

   • Результат каждого теста в TcpTestSucceeded должен быть TcpTestSucceeded : True.
   • RemoteAddresses должен принадлежать диапазону IP-адресов для подсети SQL Managed Instance.

   Если тест не удался, проверьте следующие параметры сети:

   • Существуют правила в брандмауэре сети и брандмауэре операционной системы узла SQL Server (Windows/Linux), которые разрешают трафик ко всему диапазону IP-адресов подсети SQL Managed Instance.
   • Существует правило NSG, разрешающее обмен данными через порт 5022 для виртуальной сети, в которую размещаются SQL Managed Instance.

Тестирование подключения от SQL Managed Instance к SQL Server

Чтобы проверить, что SQL Managed Instance может достичь SQL Server, сначала создайте тестовую конечную точку. Затем вы используете SQL Server Agent для запуска скрипта PowerShell с помощью команды tnc pinging SQL Server через порт 5022 из управляемого экземпляра SQL.

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

-- Run on SQL Server
-- Create the certificate needed for the test endpoint
USE MASTER
CREATE CERTIFICATE TEST_CERT
WITH SUBJECT = N'Certificate for SQL Server',
EXPIRY_DATE = N'3/30/2051'
GO

-- Create the test endpoint on SQL Server
USE MASTER
CREATE ENDPOINT TEST_ENDPOINT
    STATE=STARTED
    AS TCP (LISTENER_PORT=5022, LISTENER_IP = ALL)
    FOR DATABASE_MIRRORING (
        ROLE=ALL,
        AUTHENTICATION = CERTIFICATE TEST_CERT,
        ENCRYPTION = REQUIRED ALGORITHM AES
    )

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

tnc localhost -port 5022

Успешный тест показывает TcpTestSucceeded : True. Затем можно перейти к созданию задания SQL Server Agent в управляемом экземпляре SQL, чтобы попробовать протестировать конечную точку SQL Server на порте 5022 с управляемого экземпляра SQL.

Затем создайте задание SQL Server Agent в управляемом экземпляре SQL с именем NetHelper, выполнив следующий скрипт T-SQL в управляемом экземпляре SQL. Замена:

• <SQL_SERVER_IP_ADDRESS> с IP-адресом SQL Server, к которому можно получить доступ из управляемого экземпляра SQL.

-- Run on SQL managed instance
-- SQL_SERVER_IP_ADDRESS should be an IP address that could be accessed from the SQL Managed Instance host machine.
DECLARE @SQLServerIpAddress NVARCHAR(MAX) = '<SQL_SERVER_IP_ADDRESS>'; -- insert your SQL Server IP address in here
DECLARE @tncCommand NVARCHAR(MAX) = 'tnc ' + @SQLServerIpAddress + ' -port 5022 -InformationLevel Quiet';
DECLARE @jobId BINARY(16);

IF EXISTS (
        SELECT *
        FROM msdb.dbo.sysjobs
        WHERE name = 'NetHelper'
        ) THROW 70000,
    'Agent job NetHelper already exists. Please rename the job, or drop the existing job before creating it again.',
    1
    -- To delete NetHelper job run: EXEC msdb.dbo.sp_delete_job @job_name=N'NetHelper'
    EXEC msdb.dbo.sp_add_job @job_name = N'NetHelper',
        @enabled = 1,
        @description = N'Test SQL Managed Instance to SQL Server network connectivity on port 5022.',
        @category_name = N'[Uncategorized (Local)]',
        @owner_login_name = N'sa',
        @job_id = @jobId OUTPUT;

EXEC msdb.dbo.sp_add_jobstep @job_id = @jobId,
    @step_name = N'TNC network probe from SQL MI to SQL Server',
    @step_id = 1,
    @os_run_priority = 0,
    @subsystem = N'PowerShell',
    @command = @tncCommand,
    @database_name = N'master',
    @flags = 40;

EXEC msdb.dbo.sp_update_job @job_id = @jobId,
    @start_step_id = 1;

EXEC msdb.dbo.sp_add_jobserver @job_id = @jobId,
    @server_name = N'(local)';

Совет

Если необходимо изменить IP-адрес SQL Server для пробы подключения из управляемого экземпляра SQL, удалите задание NetHelper, выполнив EXEC msdb.dbo.sp_delete_job @job_name=N'NetHelper' и повторно создав задание NetHelper с помощью предыдущего скрипта.

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

-- Run on managed instance
IF EXISTS(SELECT * FROM sys.objects WHERE name = 'ExecuteNetHelper')
    THROW 70001, 'Stored procedure ExecuteNetHelper already exists. Rename or drop the existing procedure before creating it again.', 1
GO
CREATE PROCEDURE ExecuteNetHelper AS
-- To delete the procedure run: DROP PROCEDURE ExecuteNetHelper
BEGIN
    -- Start the job.
    DECLARE @NetHelperstartTimeUtc DATETIME = GETUTCDATE();
    DECLARE @stop_exec_date DATETIME = NULL;

    EXEC msdb.dbo.sp_start_job @job_name = N'NetHelper';

    -- Wait for job to complete and then see the outcome.
    WHILE (@stop_exec_date IS NULL)
    BEGIN
        -- Wait and see if the job has completed.
        WAITFOR DELAY '00:00:01'

        SELECT @stop_exec_date = sja.stop_execution_date
        FROM msdb.dbo.sysjobs sj
        INNER JOIN msdb.dbo.sysjobactivity sja
            ON sj.job_id = sja.job_id
        WHERE sj.name = 'NetHelper'

        -- If job has completed, get the outcome of the network test.
        IF (@stop_exec_date IS NOT NULL)
        BEGIN
            SELECT sj.name JobName,
                sjsl.date_modified AS 'Date executed',
                sjs.step_name AS 'Step executed',
                sjsl.log AS 'Connectivity status'
            FROM msdb.dbo.sysjobs sj
            LEFT JOIN msdb.dbo.sysjobsteps sjs
                ON sj.job_id = sjs.job_id
            LEFT JOIN msdb.dbo.sysjobstepslogs sjsl
                ON sjs.step_uid = sjsl.step_uid
            WHERE sj.name = 'NetHelper'
        END

        -- In case of operation timeout (90 seconds), print timeout message.
        IF (datediff(second, @NetHelperstartTimeUtc, getutcdate()) > 90)
        BEGIN
            SELECT 'NetHelper timed out during the network check. Please investigate SQL Agent logs for more information.'

            BREAK;
        END
    END
END;

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

-- Run on managed instance
EXEC ExecuteNetHelper;

Если подключение выполнено успешно, в журнале показано True. Если подключение не удалось, в журнале показано False.

Если подключение не выполнено, проверьте следующие элементы:

• Брандмауэр на экземпляре SQL Server на узле разрешает входящие и исходящие соединения через порт 5022.
• Правило NSG для виртуальной сети, в которую размещается SQL Managed Instance, разрешает обмен данными через порт 5022.
• Если экземпляр SQL Server находится на виртуальной машине Azure, правило NSG разрешает обмен данными через порт 5022 в виртуальной сети, на котором размещена виртуальная машина.
• SQL Server запущен.
• На SQL Server существует тестовая конечная точка.

После устранения проблем снова запустите проверку сети NetHelper, выполнив команду EXEC ExecuteNetHelper в управляемом экземпляре.

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

-- Run on SQL Server
DROP ENDPOINT TEST_ENDPOINT;
GO
DROP CERTIFICATE TEST_CERT;
GO

Внимание

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

Перенос сертификата защищенной 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.

установка SSMS

SQL Server Management Studio (SSMS) — самый простой способ использовать ссылку Managed Instance. Установите последнюю версию SQL Server Management Studio (SSMS) на клиентском компьютере.

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

Настройка SSMS для облачных служб для государственных организаций

Если вы хотите развернуть SQL Managed Instance в облаке для государственных организаций, необходимо изменить параметры SQL Server Management Studio (SSMS), чтобы использовать правильное облако. Если вы не развертываете SQL Managed Instance в облаке для государственных организаций, пропустите этот шаг.

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

1. Откройте SSMS.
2. В меню выберите "Сервис" и выберите пункт "Параметры".
3. Разверните Azure Services и выберите Azure Cloud.
4. В разделе Select an Azure Cloud используйте раскрывающийся список для выбора AzureUSGovernment или другого облака для государственных организаций, например AzureChinaCloud:

Если вы хотите вернуться в общедоступное облако, выберите AzureCloud из раскрывающегося списка.

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

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

• Настройка связи между SQL Server и SQL Managed Instance с помощью SSMS
• Настройте связь между SQL Server и управляемым экземпляром SQL с помощью скриптов
• Переключение на резервную ссылку
• Перейдите по ссылке
• Рекомендации по поддержанию ссылки

Дополнительные сведения о ссылке:

• Обзор связывания с Managed Instance
• Катастрофическое восстановление с использованием связи Managed Instance

Для других сценариев репликации и миграции рекомендуется:

• Транзакционная репликация с SQL Managed Instance
• Служба восстановления журналов (LRS)