疑难解答链接 - Azure SQL 托管实例

适用于：Azure SQL 托管实例

本文介绍如何监视和排查 SQL Server 与 Azure SQL 托管实例之间链接的问题。

可以使用 Transact-SQL (T-SQL)、Azure PowerShell 或 Azure CLI 检查链接的状态。如果遇到问题，可以使用错误代码来排查问题。

通过检查两个实例之间的网络并验证对于链接环境已正确准备好，可以解决创建链接的许多问题。

初始播种

在 SQL Server 和 Azure SQL 托管实例之间建立链接时，数据复制开始前会出现初始种子设定阶段。初始种子设定阶段是操作过程中耗时最长且开销最大的阶段。初始种子设定完成后，数据将会同步，但只会复制后续的数据更改。初始种子设定完成所需的时间取决于数据大小、主数据库上的工作负荷强度以及主要副本和次要副本网络之间的链接速度。

如果两个实例之间的链接速度比所需速度慢，则种子设定时间可能会受到明显影响。可以使用有说明的种子设定速度、总数据大小以及链接速度来估计初始种子设定阶段在数据复制开始前需要多长时间。例如，对于单个 100 GB 的数据库，如果链接每小时能够推送 84 GB 数据，并且没有其他数据库正在进行向不同链接的种子设定，则初始种子设定阶段需要花费大约 1.2 小时。如果链路每小时只能传输 10 GB，那么分发 100 GB 的数据库大约需要 10 小时。如果有多个数据库可以通过多个链接进行复制，则会并行执行种子设定，并且当与慢速链接速度相结合时，初始种子设定阶段可能需要相当长的时间，尤其是当来自所有数据库的并行种子设定超过可用链接带宽时。

初始种子设定阶段对网络中断以及实例维护或故障转移操作没有弹性。如果 SQL Server 和 SQL 托管实例之间的双向连接暂时丢失，或者在初始播种过程中重启或故障转移 SQL Server 或 SQL 托管实例，则播种过程将重新开始。

重要

初始分发阶段可能会因为极低的速度或繁忙的链接而持续数天。在这种情况下，创建链接可能会超时。创建链接会在 6 天后自动取消。

检查链接状态

如果链接出现问题，可以使用 SQL Server Management Studio（SSMS）、Transact-SQL（T-SQL）、Azure PowerShell 或 Azure CLI 获取有关链接的当前状态的信息。

使用 T-SQL 获取链接状态的快速状态详细信息，然后使用 Azure PowerShell 或 Azure CLI 获取有关链接当前状态的完整信息。

从 SQL Server Management Studio（SSMS）21.0（预览版）开始，可以使用链接监视。

若要检查 SSMS 中的链接状态，请执行以下步骤：

连接到托管链接的副本。
在“对象资源管理器”中，展开“Always On 高可用性”，并展开“可用性组”。
右键单击链接的名称，然后选择“ 属性 ”以打开 “链接属性 ”窗口：
“ 链接属性 ”窗口显示有关链接的有用信息，例如副本信息、链接状态和终结点证书过期日期：

使用 T-SQL 确定种子设定阶段或数据同步开始后链接的状态。 sys.dm_hadr_physical_seeding_stats DMV 可用于跟踪初始种子状态。该 estimate_time_complete_utc 列基于当前 transfer_rate_bytes_per_second 和未压缩的剩余数据大小（当 is_compression_enabled = 0 时）。对于托管实例链接，使用数据压缩，因此 estimate_time_complete_utc 预计会高估。

在托管通过链接进行种子设定的数据库的 SQL Server 或 SQL 托管实例上，使用以下 T-SQL 查询来确定链接在种子设定阶段的状态：

SELECT
    ag.local_database_name AS 'Local database name',
    ar.current_state AS 'Current state',
    ar.is_source AS 'Is source',
    ag.internal_state_desc AS 'Internal state desc',
    ag.database_size_bytes / 1024 / 1024 AS 'Database size MB',
    ag.transferred_size_bytes / 1024 / 1024 AS 'Transferred MB',
    ag.transfer_rate_bytes_per_second / 1024 / 1024 AS 'Transfer rate MB/s',
    ag.total_disk_io_wait_time_ms / 1000 AS 'Total Disk IO wait (sec)',
    ag.total_network_wait_time_ms / 1000 AS 'Total Network wait (sec)',
    ag.is_compression_enabled AS 'Compression',
    ag.start_time_utc AS 'Start time UTC',
    ag.estimate_time_complete_utc as 'Estimated time complete UTC',
    ar.completion_time AS 'Completion time',
    ar.number_of_attempts AS 'Attempt No'
FROM sys.dm_hadr_physical_seeding_stats AS ag
    INNER JOIN sys.dm_hadr_automatic_seeding AS ar
    ON local_physical_seeding_id = operation_id

-- Estimated seeding completion time
SELECT DISTINCT CONVERT(VARCHAR(8), DATEADD(SECOND, DATEDIFF(SECOND, start_time_utc, estimate_time_complete_utc) ,0), 108) as 'Estimated complete time'
FROM sys.dm_hadr_physical_seeding_stats

如果查询未返回任何结果，则种子设定过程尚未启动或已完成。

在开始数据同步后，对主实例使用以下 T-SQL 查询来检查链接的运行状况：

DECLARE @link_name varchar(max) = '<DAGname>'
SELECT
   rs.synchronization_health_desc [Link sync health]
FROM
   sys.availability_groups ag 
   join sys.dm_hadr_availability_replica_states rs 
   on ag.group_id = rs.group_id 
WHERE 
   rs.is_local = 0 AND rs.role = 2 AND ag.is_distributed = 1 AND ag.name = @link_name 
GO

查询返回以下可能值：

无结果：查询是在辅助实例上执行的。
HEALTHY：链接运行正常，数据正在副本之间同步。
NOT_HEALTHY：链接不稳定，副本之间的数据未同步。

使用 Get-AzSqlInstanceLink 通过 PowerShell 获取链接状态信息。

在 Azure Cloud Shell 中运行以下示例代码，或在本地安装 Az.SQL 模块。

$ManagedInstanceName = "<ManagedInstanceName>" # The name of your linked SQL Managed Instance
$DAGName = "<DAGName>" # distributed availability group name

# Find out the resource group name 
$ResourceGroupName = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName 

# Show link state details 
(Get-AzSqlInstanceLink -ResourceGroupName $ResourceGroupName -InstanceName $ManagedInstanceName -Name $DAGName).Databases

使用 az sql mi link show 通过 Azure CLI 获取链接状态信息。

# type "az" to use Azure CLI
managedInstanceName = "<ManagedInstanceName>" # The name of your linked SQL Managed Instance
dagName = "<DAGName>" # distributed availability group name
rgName = "<RGName>" # the resource group for the linked SQL Managed Instance  

# Print link state details 
az sql mi link show --resource-group $rgName --instance-name $managedInstanceName --name $dagName

replicaState 值描述当前链接。如果状态还包括“错误”，则在状态中列出的操作期间发生了错误。例如，LinkCreationError 指示创建链接时出错。

一些可能的 replicaState 值包括：

CreatingLink：初始种子设定
LinkSynchronizing：数据复制正在进行中
LinkFailoverInProgress：正在进行故障转移

有关链接状态属性的完整列表，请查看分布式可用性组 - GET REST API 命令。

计划的故障转移超时

如果次要副本无法跟上主副本的更改并滞后，计划的故障转移可能会超时并失败并出现错误。

若要解决此问题，请执行以下步骤：

检查两个实例之间的复制滞后时间。
如果复制滞后时间较高，请等待辅助副本赶上主副本。如果滞后时间仍然存在（例如暂停主副本上的工作负荷、改善两个实例之间的链接网络吞吐量或增加辅助副本上的资源容量），则可能需要执行其他故障排除步骤。
- 停止SQL Server主副本上的工作负荷的最简单方法是切断与实例的应用程序连接。
辅助副本赶上主副本后，再次尝试计划的故障转移。

初始化链接时出错

初始化链接时，可能会出现以下错误（链接状态：LinkInitError）：

错误 41962：操作已中止，因为链接未在 5 分钟内启动。检查网络连接，然后重试。
错误 41973：无法建立链接，因为 SQL Server 中的终结点证书未正确导入到 Azure SQL 托管实例。
错误 41974：无法建立链接，因为 SQL 托管实例中的终结点证书未正确导入到 SQL Server。
错误 41976：可用性组未响应。检查名称和配置参数，然后重试。
错误 41986：无法建立链接，因为连接失败或辅助副本没有响应。检查名称、配置参数和网络连接，然后重试。
错误 47521：无法建立链接，因为辅助服务器未收到请求。请确保可用性组和数据库在主服务器上正常运行，然后重试。

创建链接时出错

创建链接时可能会发生以下错误（链接状态： LinkCreationError

错误 41977：目标数据库未响应。检查链接参数，然后重试。
日志过早截断：如果在初始种子设定完成之前截断事务日志，则可能会看到以下错误之一：
- 错误 1408：复制到远程数据库的失败，由于主副本和辅助副本之间缺少日志文件重叠，无法恢复。删除现有链接并创建新链接以重启复制。
- 错误 1412：复制到远程数据库的失败，由于与主副本的日志文件大小不匹配，无法恢复。删除现有链接并创建新链接以重启复制。

错误 1412

首次创建链接时，进程的第一部分将数据库的完整备份从主副本播种到次要副本。完成完整备份的初始设置后，连接开始通过将主副本中的差异数据应用到辅副本来复制数据。此过程会无限期地继续，直到发出故障转移命令或删除链接。

如果在完整备份的初始填充期间主要副本上进行事务日志备份，事务日志会截断。链接创建失败，出现错误 1412，因为初始种子设定所需的事务日志中的数据不再可用。如果在 Azure SQL 托管实例中的 SQL Server 错误日志中看到错误 1412，则必须删除并重新创建链接。

若要抢先避免此问题，请在初始种子设定阶段暂停事务日志备份。

如果在初始种子设定阶段（尤其是对于非常大的数据库）期间需要事务日志备份，可以选择手动防止日志截断，或使用 T-SQL 脚本自动执行进程，以便在关键阶段自动暂停日志备份，以及何时安全。

手动防止日志截断

本部分中的步骤演示如何针对虚拟表启动事务，以防止初始播种阶段的日志截断。此过程需要手动监视数据填充进度，并仔细把握时机，以确保在数据填充完成之前不会发生日志截断。

监视播种进度。可以使用以下 T-SQL 查询来监视初始同步的进度：

SELECT * FROM sys.dm_exec_requests WHERE database_id = @dbId AND command = 'VDI_CLIENT_WORKER'

在播种接近 90% 完成时，在虚设表上发出 BEGIN TRAN 命令但不提交，以保持事务打开并防止日志截断。
仔细监视事务日志磁盘空间，以确保在事务打开时不会超过存储容量。
当做种达到 100%时，使用 COMMIT TRAN完成交易。

例如，在初始种子设定达到 90%之前，请运行以下命令以创建虚拟表以避免错误 1412：

-- Create table
CREATE TABLE Prevent1412
(
    Id        INT,
    CreatedAt DATETIME
);

然后，在种子设定即将完成时，运行以下命令以防止日志截断：

BEGIN TRAN;

INSERT INTO Prevent1412 (Id, CreatedAt)
VALUES (1, GETDATE());

注意

事务开始后，事务日志不再截断，因此请仔细监视事务日志磁盘空间，以确保它在事务打开时不会超过存储容量。

完成数据初始化后，可以提交事务来截短日志：

COMMIT TRAN;

迁移完成后，可以删除虚拟表：

DROP TABLE Prevent1412;

自动暂停日志备份

或者，当使用 T-SQL 脚本安全时，可以自动执行在关键阶段自动暂停日志备份的过程。

在迁移开始之前，可以执行以下脚本：

-- Get last backup date
SELECT TOP 1 @lastBackupTime = b.backup_finish_date
FROM master.sys.sysdatabases d 
LEFT OUTER JOIN msdb..backupSET b
ON b.database_name = d.name
AND b.type = 'L'
WHERE d.name = @dbName
ORDER BY backup_finish_date DESC
SELECT @diffInMins = DATEDIFF(minute, @lastBackupTime, CURRENT_TIMESTAMP);

-- Get database id and group database id
SELECT @agDbId = group_database_id, @dbId = database_id FROM sys.databases WHERE name = @dbName

-- If there is no group database id, no need for checks
IF (@agDbId IS NOT NULL)
BEGIN
              -- Get last seeding start time and check if backup (VDI client) is actually running
              SELECT TOP 1 @seedingStartTime = start_time, @state = current_state, @agDbId = ag_db_id FROM sys.dm_hadr_automatic_seeding ORDER BY start_time DESC

              IF (@state = 'PENDING' OR @state = 'CHECK_IF_SEEDING_NEEDED' OR @state = 'LIMIT_CONCURRENT_BACKUPS')
                             SET @seedingStarting = 1
              ELSE
                             SET @seedingStarting = 0
              
              SELECT @backupWorkers = COUNT(*) FROM sys.dm_exec_requests WHERE database_id = @dbId AND command = 'VDI_CLIENT_WORKER'

              -- Check if seeding is done by looking at remote replica state and health
              SELECT TOP 1 @db_state = synchronization_state_desc, @db_health = synchronization_health_desc FROM sys.dm_hadr_database_replica_states WHERE database_id = @dbId AND is_local = 0

              IF (@db_state = N'SYNCHRONIZING' AND @db_health = N'HEALTHY')
              SET @seedingDone = 1
              ELSE
              SET @seedingDone = 0
END

-- If X minutes has passed since last log backup, do it, we don't want to wait anymore
IF (@alreadyFailed = 1 or @diffInMins > {set_minutes})
BEGIN
              {do_log_backup}
              SET @alreadyFailed = 1
              CONTINUE;
END

-- If seeding has started and finished take log backups
IF ((@agDbId IS NOT NULL) AND (@seedingStartTime IS NOT NULL) AND (@startTime < @seedingStartTime) AND (@seedingDone = 1))
BEGIN
              {do_log_backup}
              SET @alreadyFailed = 1
              CONTINUE;
END

-- If database is not in ag or
-- If seeding has not started or
-- If seeding is ongoing 
-- Take log backups
IF ((@agDbId IS NULL) OR (@seedingStartTime IS NULL) OR (@startTime > @seedingStartTime) OR (@seedingStarting = 1) or (@backupWorkers > 0))
BEGIN
              {do_log_backup}
              CONTINUE;
END

强制故障转移后的状态不一致

在强制故障转移后，你可能会遇到脑裂情况，即两个副本都担当主要角色，这导致链接处于不一致状态。如果在灾难期间故障转移到次要副本，然后主副本重新联机，则可能会发生这种情况。

首先，确认你处于脑裂情况中。可以使用 SQL Server Management Studio (SSMS) 或 Transact-SQL (T-SQL) 来执行此操作。

在 SSMS 中连接到 SQL Server 和 SQL 托管实例，然后在“对象资源管理器”中，展开“Always On 高可用性”中的“可用性组”节点下的“可用性副本”。如果两个不同的副本被列为“(主要)”，则表示处于裂脑情况中。

或者，可以在 SQL Server 和 SQL 托管实例上运行以下 T-SQL 脚本来检查副本的角色：

-- Execute on SQL Server and SQL Managed Instance 
USE master
DECLARE @link_name varchar(max) = '<DAGName>'
SELECT
   ag.name [Link name], 
   rs.role_desc [Link role] 
FROM
   sys.availability_groups ag 
   JOIN sys.dm_hadr_availability_replica_states rs 
   ON ag.group_id = rs.group_id 
WHERE 
   rs.is_local = 1 AND ag.is_distributed = 1 AND ag.name = @link_name 
GO

如果这两个实例在“链接角色”列中都作为“主要”实例列出，则表明处于裂脑情况。

要解决裂脑状态，请首先对曾是原始主要实例的任意副本进行备份。如果原始主数据库是 SQL Server，则执行尾日志备份。如果原始主实例是 SQL 托管实例，则进行仅复制完整备份。在备份完成后，在分布式可用性组中，将曾经是原始主要副本但现在将成为新的辅助副本的副本设置为辅助角色。

例如，在真正发生灾难时，假设你已强制将 SQL Server 工作负载故障转移到 Azure SQL 托管实例，并且你打算继续在 SQL 托管实例上运行工作负载，请在 SQL Server 上进行尾日志备份，然后将分布式可用性组设置为 SQL Server 上的辅助角色，如下例所示：

--Execute on SQL Server 
USE master
ALTER AVAILABILITY GROUP [<DAGName>] 
SET (ROLE = SECONDARY) 
GO

接下来，使用链接执行从 SQL 托管实例到 SQL Server 的计划内手动故障转移，如下例所示：

--Execute on SQL Managed Instance 
USE master
ALTER AVAILABILITY GROUP [<DAGName>] FAILOVER 
GO

证书已过期

用于链接的证书可能会过期。如果证书过期，则链接会失败。若要解决此问题，请轮换证书。

迁移到 SQL 托管实例后的已知问题

迁移到 Azure SQL 托管实例后，请考虑以下已知问题：

迁移到 SQL 托管实例后还原操作失败

如果您将启用了加速数据库恢复的 SQL Server 2019 及更高版本的数据库迁移到 Azure SQL 托管实例，但将永久性版本存储（PVS）配置为文件组以外的 PRIMARY，则可能会在目标 SQL 托管实例上遇到还原操作失败的情况。

若要解决此问题，请确保在将永久性版本存储（PVS）设置为源 SQL Server 数据库上的 PRIMARY，然后再将其迁移到 SQL 托管实例。如果您已经在没有将 PVS 设置为 PRIMARY 的情况下迁移了数据库，可以在源 SQL Server 数据库上设置 PVS，然后重新迁移数据库到 SQL 托管实例。

迁移到 SQL 托管实例后无法使用加速数据库恢复

从 SQL Server 2019 开始，如果将数据库迁移到 Azure SQL 托管实例，并且源数据库已禁用加速数据库恢复，则无法在目标 SQL 托管实例上使用加速数据库恢复。

若要解决此问题，请确保在将数据库迁移到 SQL 托管实例之前，在源 SQL Server 数据库上启用加速数据库恢复。如果已在未启用加速数据库恢复的情况下迁移数据库，则可以在源 SQL Server 数据库上启用该数据库，然后将数据库重新迁移到 SQL 托管实例。

SQL Server 2017 和早期版本不支持加速数据库恢复，因此此问题不适用于从这些版本的 SQL Server 迁移的数据库。

迁移到 SQL 托管实例后无法使用 Service Broker

如果将数据库迁移到 Azure SQL 托管实例，并且源数据库上禁用 Service Broker，则无法在目标 SQL 托管实例上使用 Service Broker。

若要解决此问题，请确保先在源 SQL Server 数据库上启用 Service Broker，然后再将其迁移到 SQL 托管实例。如果已在未启用 Service Broker 的情况下迁移数据库，则可以在源 SQL Server 数据库上启用该数据库，然后将数据库重新迁移到 SQL 托管实例。

测试网络连接

SQL Server 和 SQL 托管实例之间必须有双向网络连接，链接才能正常工作。在 SQL Server 端打开端口并在 SQL 托管实例端配置 NSG 规则后，使用 SQL Server Management Studio (SSMS) 或 Transact-SQL 测试连接。

通过在 SQL Server 和 SQL 托管实例上创建临时 SQL 代理作业来测试网络，以检查两个实例之间的连接。在 SSMS 中使用网络检查器时，系统会自动为你创建作业，并在测试完成后将其删除。如果使用 T-SQL 测试网络，则需要手动删除 SQL 代理作业。

注意

目前不支持通过 Linux 上 SQL Server 上的 SQL Server 代理执行 PowerShell 脚本，因此目前无法从 Linux 上 SQL Server 上的 SQL Server 代理作业执行 Test-NetConnection。

若要使用 SQL 代理测试网络连接，需要满足下面的要求：

执行测试的用户必须具有为 SQL Server 和 SQL 托管实例创建作业的权限（作为 sysadmin 或属于 msdb 的 SQLAgentOperator 角色）。
SQL Server 代理服务必须在 SQL Server 上运行。由于代理在 SQL 托管实例上默认处于启用状态，因此无需采取其他操作。

请考虑以下事项：

为了避免误报，网络路径上的所有防火墙都必须允许 Internet 控制消息协议（ICMP）流量。
为了避免误报，网络路径上的所有防火墙都必须允许专有 SQL Server UCS 协议上的流量。阻止协议可能会导致连接测试成功，但无法创建链接。
需要正确配置具有数据包级防护措施的高级防火墙设置，以正确允许 SQL Server 和 SQL 托管实例之间的流量。

SSMS
T-SQL

若要在 SSMS 中测试 SQL Server 与 SQL 托管实例之间的网络连接，请执行以下步骤：

连接到将在 SSMS 中作为主要副本的实例。
在“对象资源管理器”中，展开数据库，然后右键单击要链接到次要副本的数据库。选择“任务”>“Azure SQL 托管实例链接”>“测试连接”，以打开“网络检查器”向导：
在“网络检查器”向导的“简介”页上，选择“下一步”。
如果满足“先决条件”页上的所有要求，请选择“下一步”。否则，请解决任何未满足的先决条件，然后选择“重新运行验证”。
在“登录”页上，选择“登录”以连接到将作为次要副本的其他实例。选择下一步。
检查“指定网络选项”页上的详细信息，并在必要时提供 IP 地址。选择下一步。
在“摘要”页上，查看向导执行的操作，然后选择“完成”以测试两个副本之间的连接。
查看“结果”页，验证两个副本之间是否存在连接，然后选择“关闭”以完成。

若要使用 T-SQL 测试连接，必须沿两个方向检查连接。首先，测试从 SQL Server 到SQL 托管实例的连接，然后测试从 SQL 托管实例到 SQL Server 的连接。

测试从 SQL Server 到 SQL 托管实例的连接

使用 SQL Server 上的 SQL Server 代理运行从 SQL Server 到 SQL 托管实例的连接测试。

连接到 SQL 托管实例并运行以下脚本以生成稍后需要用到的参数：

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.china-east.worker.database.chinacloudapi.cn'
 DECLARE @port NVARCHAR(512) = N'11002'
 DECLARE @serverName NVARCHAR(512) = N'contoso-instance.12345678.database.chinacloudapi.cn'

保存要在后续步骤中使用的结果。由于这些参数可以在任何故障转移后更改，因此如有必要，请务必再次生成这些参数。

连接到你的 SQL Server 实例。

打开新的查询窗口并粘贴以下脚本：

--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

将 @node、@port 和 @serverName 参数替换为从第一步中获取的值。
运行脚本并检查结果。应显示如以下示例所示的结果：
验证结果：
- TcpTestSucceeded 的每个测试的结果应为 TcpTestSucceeded : True。
- 这些 RemoteAddress 应属于 SQL 托管实例子网的 IP 范围。
如果响应为不成功，请验证以下网络设置：
- 网络防火墙和 SQL Server 主机操作系统 (Windows/Linux) 防火墙中都有规则允许流量流向 SQL 托管实例的整个子网 IP 范围。
- 有一个允许在端口 5022 上进行通信的 NSG 规则用于托管 SQL 托管实例的虚拟网络。

测试从 SQL 托管实例到 SQL Server 的连接

若要检查 SQL 托管实例是否可以访问 SQL Server，请首先创建一个测试终结点。然后使用 SQL Server 代理运行 PowerShell 脚本，并通过 tnc 命令从 SQL 托管实例对端口 5022 上的 SQL Server 执行 ping。

若要创建测试终结点，请连接到 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 上接收连接，请在 SQL Server 实例的主机操作系统上运行以下 PowerShell 命令：

tnc localhost -port 5022

如果测试成功，则会显示 TcpTestSucceeded : True。然后可以在 SQL 管理实例上创建一个 SQL Server 代理作业，以尝试从该实例通过端口 5022 测试 SQL Server 测试终结点。

接下来，通过在 SQL 托管实例上运行以下 T-SQL 脚本，在 SQL 托管实例上创建名为 NetHelper 的 SQL Server 代理作业。进行以下替换：

<SQL_SERVER_IP_ADDRESS> 替换为可从 SQL 托管实例访问的 SQL Server 的 IP 地址。

-- 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)';

提示

若要修改用于从 SQL 托管实例进行连接探测的 SQL Server IP 地址，请通过运行 EXEC msdb.dbo.sp_delete_job @job_name=N'NetHelper' 删除 NetHelper 作业，并使用上一个脚本重新创建 NetHelper 作业。

然后，创建一个存储过程 ExecuteNetHelper，以帮助运行作业，并从网络探测中获取结果。在 SQL 托管实例上运行以下 T-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。

显示 NetHelper SQL 代理作业预期输出的屏幕截图。

如果连接不成功，请验证以下各项：

主机 SQL Server 实例上的防火墙允许端口 5022 上的入站和出站通信。
承载 SQL 托管实例的虚拟网络中有一个允许在端口 5022 上进行通信的 NSG 规则。
如果 SQL Server 实例位于 Azure VM 上，那么托管该 VM 的虚拟网络是否有一个允许在端口 5022 上进行通信的 NSG 规则。
SQL Server 正在运行。
SQL Server 上存在测试终结点。

解决问题后，通过在托管实例上运行 EXEC ExecuteNetHelper 来重新运行 NetHelper 网络探测。

最后，在网络测试成功完成后，请在 SQL Server 上使用以下 T-SQL 命令删除测试终结点和证书：

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

注意

仅当源环境和目标环境之间有已经过验证的网络连接时，才继续执行后续步骤。否则，请先排查网络连接问题，然后再继续。

有关链接功能的详细信息，请参阅以下资源：

Last updated on 2026-04-30