你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

使用链接进行迁移 - Azure SQL 托管实例

本文介绍如何使用托管实例链接将SQL Server数据库迁移到Azure SQL 托管实例。

有关详细的迁移指南，请查看 Migrate 到 Azure SQL 托管实例。若要比较迁移工具，请查看 Compare LRS 与托管实例链接。

注意

现在可以将Azure Arc启用的SQL Server实例直接通过Azure门户迁移到Azure SQL 托管实例。有关详细信息，请参阅 Migrate 到 Azure SQL 托管实例。

概述

托管实例链接允许从任何位置托管的SQL Server迁移到Azure SQL 托管实例。该链接使用 AlwaysOn 可用性组技术将更改几乎实时地从主SQL Server实例复制到辅助SQL 托管实例。该链接提供SQL Server和Azure SQL 托管实例之间唯一真正的联机迁移选项，因为唯一的停机时间是切换到目标 SQL 托管实例。

使用链接进行迁移让你能够：

在完成迁移到Azure之前，能够在SQL 托管实例上测试只读工作负荷。
能够确保链接和迁移根据需要持续运行，可以是几周，甚至几个月。
准实时复制数据，提供到 Azure 的最快可用数据复制。
与目前可用的所有其他解决方案相比，其迁移导致的停机时间最短。
即时迁移到目标 SQL 托管实例。
能够在准备就绪后随时进行迁移。
能够将单个或多个数据库从一个或多个SQL Server实例迁移到Azure中的相同或多个 SQL 托管实例。
以唯一真正联机的方式迁移到业务关键服务层级。

注意

虽然每个链接只能迁移一个数据库，但可以建立从同一SQL Server实例到同一SQL 托管实例的多个链接。

直接转换行为

直接转换行为取决于从中迁移的 SQL Server 版本和目标 SQL 托管实例的更新策略：

对于 SQL Server 2016 到 SQL Server 2019，切换到 SQL 托管实例会断开该链接。
对于 SQL Server 2022 或更高版本，切换到 SQL 托管实例时，可以根据你在故障转移期间的选择删除链接或保留链接。如果选择保留链接，并且 SQL 托管实例配置了匹配的更新策略，则可以根据需要反向迁移到SQL Server。

对于迁移，建议删除链接。如果选择保留链接，但后来决定将其删除，请等待Azure在故障转移后完成数据库的第一次完整备份，然后再删除该链接。此步骤可确保数据库在SQL 托管实例正常运行。它还有助于避免一个罕见的已知问题，如果链接太早删除，数据库在服务器重启后可能会暂时不可用。有关详细信息，请参阅 MI 链路故障转移后服务器重新启动后，数据库不可用。

反向迁移

根据 SQL 托管实例的更新策略，可能会支持从 Azure SQL 托管实例反向迁移回 SQL Server。例如：

SQL Server 2022 更新策略：使用 SQL Server 2022 更新策略配置的实例中的数据库可以从 SQL Server 2022 实例进行还原。
SQL Server 2025 更新策略：从配置了 SQL Server 2025 更新策略的实例中备份的数据库可以还原到 SQL Server 2025 实例。
Always-up-to-date 更新策略：使用 Always-up-to-date 更新策略配置的数据库无法还原回SQL Server。

如果源SQL Server版本早于 2022 SQL Server，则无法进行反向迁移。将数据库迁移到SQL 托管实例时，会进行内部升级到与早期SQL Server版本不兼容的较新的数据库版本。仅当SQL 托管实例配置了相应的更新策略时，才能使用反向迁移数据库兼容性。

先决条件

若要将链接用于迁移Azure SQL 托管实例，需要满足以下先决条件：

一个有效的 Azure 订阅。如果没有帐户，请创建一个免费帐户。
SQL Server 的支持版本，已安装所需服务更新。

评估和发现

验证你的源环境是否受支持后，开始预迁移阶段。发现所有现有数据源，评估迁移可行性，确定可能会妨碍迁移的任何阻碍性问题。在“发现”阶段，扫描网络以识别组织使用的所有SQL Server实例和功能。

可以使用以下工具来发现环境中的 SQL 源：

Azure Arc 启用的 SQL Server：Azure Arc 启用的 SQL Server 会自动生成迁移到 Azure 的评估，简化迁移的发现和准备情况的评估过程。
Azure Migrate评估本地服务器的迁移适用性、执行基于性能的大小调整，并为在Azure中运行它们提供成本估算。
Microsoft评估和规划工具包（“MAP 工具包”）评估当前 IT 基础结构。该工具包提供了功能强大的清单、评估和报告工具，可以简化迁移规划过程。

发现数据源后，评估可以迁移到Azure SQL 托管实例的任何本地SQL Server实例，以确定迁移阻止程序或兼容性问题。

可以使用迁移就绪情况评估来评估源SQL Server实例。

有关详细指导，请参阅迁移前。

创建目标实例

评估现有环境并确定目标 SQL 托管实例的相应服务层级和硬件配置后，请使用 Azure 门户、PowerShell或 Azure CLI 部署目标实例。

设置链接

创建目标 SQL 托管实例后，在SQL Server实例和Azure SQL 托管实例上配置数据库之间的链接。首先，准备环境然后使用 SQL Server Management Studio （SSMS）或 scripts 配置链接。

检查复制延迟

在执行计划内迁移故障转移之前，确保次要副本已与主要副本同步至关重要。如果次要副本与主要副本的延迟差距过大，计划内故障转移可能会因超时而失败。

对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], 
   ars1.role_desc [Link role],
   ars2.connected_state_desc [Link connected state],
   ars2.synchronization_health_desc [Link sync health],
   drs.secondary_lag_seconds [Link replication latency (seconds)]
FROM
   sys.availability_groups ag 
   JOIN sys.dm_hadr_availability_replica_states ars1
   ON ag.group_id = ars1.group_id
   JOIN sys.dm_hadr_availability_replica_states ars2
   ON ag.group_id = ars2.group_id
   JOIN sys.dm_hadr_database_replica_states drs
   ON ars2.replica_id = drs.replica_id
WHERE 
   ag.is_distributed = 1 AND ag.name = @link_name AND ars1.is_local = 1 AND ars2.is_local = 0
GO

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

迁移多个数据库

如果计划从同一服务器上的实例迁移多个数据库，以实现最佳性能和可预测性，请一次迁移每个实例 8 个数据库。例如，如果每个实例有 10 个实例，每个实例有 32 个链接数据库，则每次使用计划的故障转移从每个实例迁移 8 个数据库，并重复此过程，直到迁移所有数据库。

数据同步和直接转换

建立链接并准备好迁移后，请遵循以下步骤（通常在维护时段）：

停止主SQL Server数据库上的工作负荷，以便SQL 托管实例上的辅助数据库赶上。停止SQL Server主副本上的工作负荷的最简单方法是切断与实例的应用程序连接。
验证所有数据是否已成功传输到 SQL 托管实例上的辅助数据库。检查复制延迟时间，确保次要副本与主要副本保持同步。
通过选择“计划的故障转移”，将链接故障转移到辅助 SQL 托管实例。
（可选）选中在成功故障转移后删除链接 的框，确保故障转移为单向，并删除该链接。
（可选）如果使用支持的 SQL Server 版本，并具备匹配的 SQL 托管实例更新策略，则可以在故障转移后保留链接，以便在需要时反向迁移。查看反向迁移部分以了解特定版本详细信息。
直接转换应用程序，以连接至 SQL 托管实例终结点。
（可选）如果你在故障转移期间未选择删除该链接，则在直接转换完成后，一旦不再需要该链接，即可将其删除。

验证迁移

切换到 SQL 托管实例目标后，监视应用程序、测试性能并修正任何问题。

有关详细信息，请查看迁移后。

迁移的已知问题

使用链接查看与迁移相关的以下已知问题。

MI 链路故障转移后服务器重新启动后，数据库不可用

在极少数情况下，当链接发生故障转移后服务器重启时，你的数据库在 SQL 托管实例上可能会暂时无法访问。当在初始故障转移至 SQL 托管实例后，Azure 尚未完成数据库的完整备份时，若此时删除链接，就会出现此已知问题。

数据库在Microsoft干预后自动恢复，但此恢复可能需要一些时间。

为避免此问题，请在从 SQL Server 故障转移到 SQL 托管实例后的首次完整备份完成之前，不要断开链接。有关详细信息，请参阅服务器重启后数据库不可用。

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

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

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

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

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

若要解决此问题，在将源SQL Server数据库迁移到SQL 托管实例之前，请确保可启用加速数据库恢复。如果已在未启用加速数据库恢复的情况下迁移数据库，则可以在源 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 托管实例。

要使用该链接，请参阅以下内容：

要了解有关该链接的详细信息，请参阅以下内容：

托管实例链接概览
使用托管实例链接进行灾难恢复

对于其他复制和迁移方案，请考虑：

反馈

此页面是否有帮助？

Last updated on 2026-06-30