有关使用 Azure 数据库迁移服务的常见问题解答

Azure 数据库迁移服务是一项完全托管的服务，旨在实现从多个数据库源到 Azure 数据平台的无缝迁移，并且最小化停机时间。 该服务目前已正式发布，目前正在进行的开发工作重点是：

• 可靠性和性能。
• 源目标对的迭代添加。
• 无摩擦迁移中的持续投资。

该服务目前支持各种源/目标对或迁移方案。 有关每个可用迁移方案的状态的完整列表，请参阅文章 Azure 数据库迁移服务支持的迁移方案的状态。

从 SQL Server 迁移时，Azure 数据库迁移服务支持的源为 SQL Server 2008 及更高版本。 如果将 Azure Data Studio 与 SQL 迁移扩展配合使用，则支持的源是 SQL Server 2008 到 SQL Server 2022。

可以使用 Azure 数据库迁移服务执行脱机和联机迁移。 使用脱机迁移时，应用程序停机时间从迁移开始时算起。 使用联机迁移时，停机时间仅限在迁移结束时进行转换的那段时间。 建议对脱机迁移进行测试，以便确定其停机时间是否可以接受；如果不能接受，请进行联机迁移。

Azure 数据库迁移服务是将数据库大规模迁移到 Microsoft Azure 的首选方法。 有关 Azure 数据库迁移服务与其他 Microsoft 数据库迁移工具的差别，以及对各种方案使用不同服务的建议，请参阅 Microsoft 数据库迁移工具和服务的差别。

Azure 迁移服务可以帮助将本地虚拟机迁移到 Azure IaaS。 该服务会评估是否适合迁移以及需要根据性能进行哪些大小调整，并提供在 Azure 中运行本地虚拟机的成本估算。 Azure Migrate 适合用于将基于本地 VM 的工作负荷直接迁移到 Azure IaaS VM。 但是，与 Azure 数据库迁移服务不同，Azure Migrate 不是适用于 Azure SQL 数据库或 Azure SQL 托管实例等 Azure PaaS 关系数据库平台的专用数据库迁移服务产品/服务。

否。 数据库迁移服务不存储客户数据。

对于 Azure SQL VM 和 Azure SQL MI 目标，DMS 使用物理迁移，即使用备份和还原。 如上所述，选择的迁移模式决定了数据在源和目标之间如何保持一致。

• 脱机迁移：在脱机迁移到 Azure SQL VM 和 Azure SQL MI 目标期间，应用程序停机时间会在迁移开始时开始。 只要源中的最新备份文件已传输到 SMB 网络存储或 Azure Blob 容器（根据迁移配置），DMS 就会将所有备份文件还原到目标。 如果使用 CHECKSUM 选项执行备份，DMS 还原操作会自动执行验证。 如果缺少校验和，则会在还原之前显式检查备份的完整性。 这可确保还原文件与备份文件相同，因此具有相同的数据。 可以验证所有备份文件，包括来自源的最后一个备份文件名以及 DMS 迁移监控页上显示的在目标上应用/还原的备份文件，并验证它们各自的校验和。

• 联机迁移：在联机迁移到 Azure SQL VM 和 Azure SQL MI 目标期间，开始迁移直接转换并停止应用程序后，停机时间就会开始。 只要源中的最新备份文件已传输到 SMB 网络存储或 Azure Blob 容器（根据迁移配置），DMS 就会将所有备份文件还原到目标。 按直接转换按钮后，DMS 会显示 SMB 网络存储或 Azure Blob 容器上存在但尚未在目标上应用/还原的挂起备份文件（如果有）的计数。 如果使用 CHECKSUM 选项执行备份，DMS 还原操作会自动执行验证。 如果缺少校验和，则会在还原之前显式检查备份的完整性。 这可确保还原文件与备份文件相同，因此具有相同的数据。 可以验证所有备份文件，包括来自源的最后一个备份文件名以及 DMS 迁移监控页上显示的在目标上应用/还原的备份文件，并验证它们各自的校验和。

对于 Azure SQL DB 目标，DMS 在 Azure SQL DB 的情况下执行逻辑迁移，即将数据从源 SQL 数据库的表复制并将其写入目标 Azure SQL DB 的表。 由于 DMS 仅支持脱机迁移到 Azure SQL DB，因此应用程序停机时间在迁移开始时开始。 可以从迁移监视页监视和验证读取的行数（从源数据库表）和复制的行数（写入目标 Azure SQL DB 表）。 作为其他确认，可以运行以下 TSQL 以获取源数据库和目标数据库的校验和，并验证源数据和还原数据是否相同。

  "SELECT CHECKSUM_AGG(CHECKSUM(*)) FROM <table_name>"
  

注意：未向源数据库或目标数据库写入任何应用程序。 还可以利用数据库比较工具等工具进行数据比较。

以下列表包含可在幕后创建的用于执行数据迁移的 Azure 资源。 使用的服务因迁移方案而异。

• Azure Monitor
• Azure VM
• Azure 存储
• Azure 服务总线
• Azure 数据工厂

在内部，DMS 维护一个元数据存储，其中包含有关网络位置、凭据、备份文件和已完成的任务的信息。 凭据和选定的字段（例如帐户密钥）已加密。 数据（例如可能包含在遥测中的表名称）已经过哈希处理。 用户名可能以纯文本形式显示在服务日志中，但密码永远不会如此。 遥测数据按区域隔离并受保留策略控制，仅可供 Microsoft 中已获授权的人员用于有效故障排除。 Azure 资源名称（例如服务器和数据库名称）遵循针对 Azure 资源的规则。

DMS（经典）利用 Azure 服务总线主题来帮助实现计算层之间的通信。 Azure 服务总线主题对于每个 DMS 实例是唯一的，所有个人数据已加密。

Azure 虚拟机上的 Azure SQL 托管实例和 SQL Server

使用备份和还原来迁移架构和数据。 客户可以选择从网络共享还原，或直接从存储容器还原。 可以使用包含 Windows 性能数据的文件来提供可选（但强烈建议）的工作负载大小建议。

Azure SQL 数据库

迁移到 Azure SQL 数据库分两个步骤执行。 第一步是架构迁移。 DMS（经典）使用 SQL 管理对象 (SMO) 进行架构迁移。 第二步是实际数据迁移。 使用 SqlBulkCopy 执行数据迁移。 DMS 不支持架构迁移。 使用 Azure 数据工厂迁移数据。 （可选但强烈建议）可以使用包含 Windows 性能数据的文件来提供工作负载大小建议。

Azure Database for PostgreSQL

在此方案中，最终用户使用 pg_dump 和 pg_restore 命令行实用工具提取元数据（在本例中为架构）。 为 PostgreSQL 配置变更数据捕获时，DMS 在内部使用 pg_dump 和 pg_restore 为 CDC 执行初始种子设定。 数据存储在仅可供 DMS 实例访问的已加密临时存储中。 可以使用包含 Windows 性能数据的文件来提供可选（但强烈建议）的工作负载大小建议。

Azure Database for MySQL

在此方案中，架构提取和迁移由 DMS（经典）使用 mysql-net/MySqlConnector 来执行。 在可能的情况下，将使用 MySQL binlog 复制来复制数据和架构更改。 在无法使用 binlog 复制的情况下，将使用自定义代码来同步更改。

MongoDB 到 Azure Cosmos DB

DMS 从 MongoDB 提取数据并将其插入 Cosmos DB。 它还提供用于从 BSON 或 JSON 转储提取数据的选项。

对于 BSON 转储，DMS 使用 Blob 容器中同一文件夹内的 bsondump 格式的数据。 DMS 仅查找使用 collection.metadata.json 格式的元数据文件。

对于 JSON 转储，DMS 将读取与包含数据库同名的 Blob 容器文件夹中的文件。 在每个数据库文件夹中，DMS 仅使用放置在 data 子文件夹中的数据文件。 DMS 仅在放置于 metadata 子文件夹中并使用格式 collection.json 命名的文件中查找元数据。

Oracle 到 Azure SQL 数据库

在此方案中，将使用 AWR 报告或 Windows perfmon 文件来提供可选（但强烈建议）的工作负载大小建议。 执行迁移的用户使用数据库架构转换工具包执行架构迁移以准备目标数据库。

Oracle 到 Azure Database for PostgreSQL

与“Oracle 到 Azure SQL 数据库”非常相似，在此方案中，将使用 AWR 报告或 Windows perfmon 文件来提供可选（但强烈建议）的工作负载大小建议。 使用 ora2pg 库提取架构，并由执行迁移的用户手动迁移数据。

DMS（经典）依赖于客户网络配置。 如果迁移源使用专用终结点，则我们将使用专用终结点，这是首选的配置。 如果只能选择公共终结点，则我们将使用公共终结点。

DMS 在幕后重度使用 ADF 来计划和协调数据移动。 此外，自承载集成运行时与可能已用于你自己的 ADF 管道的运行时没有差别。 有关防火墙和代理服务器问题的详细信息，请参阅创建和配置自承载集成运行时。

所有客户数据经过静态加密。 某些元数据，包括但不限于逻辑服务器名称和数据库名称，以及迁移状态和迁移进度，将以未加密的形式显示在服务日志中。

默认将使用 TLS 1.2 加密来保护所有传输中数据。 对于需要较旧 TLS 版本的传统客户端，需要在 DMS（经典）门户页中启用所需的版本。 对于 DMS，可以将安装了自承载集成运行时的计算机配置为允许所需的 TLS 设置以适应传统客户端。 有关 SQL Server 的 TLS 配置的详细信息，请参阅 KB3135244 - Microsoft SQL Server 的 TLS 1.2 支持。

尽可能使用专用终结点。 如果无法选择专用终结点，则使用公共终结点在服务层之间进行通信。 无论终结点类型如何，所有资源都专用于/范围限定为 DMS 的特定实例，并使用唯一的凭据进行保护。

我们不支持使用客户管理的密钥来加密数据平面或控制平面中的数据。 但是，会使用服务管理的密钥对所有客户数据进行静态加密。 某些元数据，包括但不限于逻辑服务器名称和数据库名称，以及迁移状态和进度，将以未加密形式显示在服务日志中。

默认将使用 TLS 1.2 加密来加密所有传输中数据。 在 DMS（经典）门户页中可以将较旧的 TLS 版本用于传统客户端。 对于 DMS，可以将安装了自承载集成运行时的计算机配置为允许管理 TLS 设置以适应传统客户端。 有关 SQL Server 的 TLS 配置的详细信息，请参阅 KB3135244 - Microsoft SQL Server 的 TLS 1.2 支持。

我们不会公开用于通过客户管理的密钥加密控制平面或数据平面中的数据的功能。 在删除 DMS 实例的那一刻，将删除所有客户数据（服务日志除外）。 DMS 服务日志仅保留 30 天。

TDE

DMS 支持将客户管理的密钥 (CMK) 迁移到 Azure SQL，以便实现透明数据库加密 (TDE)。 有关迁移 TDE 密钥的分步说明，请参阅教程：在 Azure Data Studio 中，将已启用 TDE 的数据库（预览版）迁移到 Azure SQL。

单元格加密

单元级加密在架构级别进行处理。 架构迁移工具将迁移所有架构对象，包括实现单元格级别加密所需的函数和存储过程。

Always Encrypted

DMS 目前不支持通过在源和目标之间迁移单个数据行的方案来迁移 Always Encrypted。 在使用备份/还原的方案中，例如从现有 SQL Server 实例移动到 Azure SQL VM 或 Azure SQL 托管实例，通过 Always Encrypted 加密的列将按预期迁移。

除 Azure 中已有的访问控制之外，我们不会实施任何其他位置感知访问控制。 与 DMS 实例关联的所有数据驻留在 DMS 资源所在同一区域中。

我们的服务用于具有不同内部控制和业务流程的各种环境。 DMS 将数据移入和移出其所用帐户可以访问的任何位置。 用户需负责了解其所在工作环境的权限和内部控制。 确保 DMS 用于连接到源的帐户有权查看要从源迁移的所有数据尤为重要。

VNET 注入是将驻留在 Microsoft 租户中的 Azure 资源，添加到客户租户下的 VNet 中的子网的操作。 此方法与 DMS 一起使用，使我们能够代表客户管理计算，同时仍然保留对客户资源的访问权限。 由于网络在客户订阅中，因此 Microsoft 除了发出“启动”、“停止”、“删除”或“部署”命令之外，无法管理 VM。 所有其他需要访问 VM 的管理操作都需要客户发起支持请求并获得批准。

若要确保 Azure 数据库迁移服务在执行数据库迁移时顺利运行，需要满足几个先决条件。 某些先决条件适用于该服务支持的所有方案（源/目标对），而其他先决条件则是特定方案所特有的。

在所有支持的迁移方案中通用的 Azure 数据库迁移服务先决条件包括需要：

• 使用 Azure 资源管理器部署模型创建适合 Azure 数据库迁移服务的 Microsoft Azure 虚拟网络，它将使用 ExpressRoute 或 VPN 为本地源服务器提供站点到站点连接。
• 请确保虚拟网络的网络安全组规则不阻止 ServiceBus、存储服务和 AzureMonitor 的 ServiceTag 的端口 443。 有关虚拟网络 NSG 流量筛选的更多详细信息，请参阅使用网络安全组筛选网络流量一文。
• 在源数据库的前面使用了防火墙设备时，可能需要添加防火墙规则以允许 Azure 数据库迁移服务访问要迁移的源数据库。

有关使用 Azure 数据库迁移服务完成特定迁移方案所需的所有先决条件列表，请参阅 Azure 数据库迁移服务文档中的相关教程。

可能需要添加防火墙规则，以允许 Azure 数据库迁移服务访问要迁移的源数据库。 该服务的 IP 地址是动态的，但如果你使用 ExpressRoute，则企业网络会专门分配此地址。 标识相应 IP 地址的最简单方法是查看预配的 Azure 数据库迁移服务资源所在的同一个资源组，找到关联的网络接口。 通常，网络接口资源的名称以 NIC 前缀开头，后接唯一的字符和序号，例如“NIC-jj6tnztnmarpsskr82rbndyp”。 选择此网络接口资源后，可以看到需要包含在 Azure 门户资源概述页上的允许列表中的 IP 地址。

可能还需要在允许列表中包含 SQL Server 侦听的端口源。 默认情况下为端口 1433，但源 SQL Server 可能也配置为侦听其他端口。 在这种情况下，也需要在允许列表中包含这些端口。 可以使用动态管理视图查询来确定 SQL Server 侦听的端口：

SELECT DISTINCT
    local_tcp_port
FROM sys.dm_exec_connections
WHERE local_tcp_port IS NOT NULL;

也可以通过查询 SQL Server 错误日志来确定 SQL Server 侦听的端口：

USE master;
GO
xp_readerrorlog 0, 1, N'Server is listening on';
GO

虽然有多篇 Microsoft 教程可以指导你完成设置虚拟网络的过程，但官方文档出现在 Azure 虚拟网络一文中。

在典型的简单数据库迁移过程中，需要：

1. 创建目标数据库。
2. 评估源数据库。
   • 对于同构迁移，使用 DMA 评估现有数据库。
   • 对于异构迁移（从竞争源进行），使用 SSMA 评估现有数据库。 还可以使用 SSMA 来转换数据库对象，以及将架构迁移到目标平台。
3. 创建 Azure 数据库迁移服务的实例。
4. 创建迁移项目，用于指定源数据库、目标数据库和要迁移的表。
5. 启动完全加载。
6. 选择后续验证。
7. 执行从生产环境到新的基于云的数据库的手动切换。

如果在迁移过程中连接到源数据库系统时遇到问题，请在用于设置 DMS 实例的虚拟网络的同一子网中创建一个虚拟机。 在该虚拟机中，应该能够运行连接测试，例如，使用 UDL 文件测试连接到 SQL Server，或下载 Robo 3T 以测试 MongoDB 连接。 如果连接测试成功，则在连接到源数据库时应该不会遇到问题。 如果连接测试失败，请与网络管理员联系。

如果用户显式停止 Azure 数据库迁移服务 (DMS)，或者如果服务处于非活动状态已有 24 小时，则服务将处于已停止或自动暂停状态。 在上述每种情况下，服务将不可用并处于已停止状态。 若要恢复活动迁移，请重启该服务。

可以采取几项措施来加快使用该服务迁移数据库的速度：

对于 DMS（经典版）-

• 创建服务实例时使用多 CPU 常规用途定价层，使该服务可以利用多个 vCPU 来实现行化和加速数据传输。
• 在数据迁移操作期间，暂时将 Azure SQL 数据库目标实例纵向扩展到高级层 SKU，以尽量减少遇到使用较低级 SKU 时出现的 Azure SQL 数据库限制，从而避免对数据传输活动造成影响。

对于 DMS-

• 如果正在将备份从本地文件共享复制到 Azure Blob 存储，或者正在执行迁移到目标 Azure SQL DB 的操作，DMS 将使用 SHIR 节点作为其计算资源。 因此，请确保监视该 SHIR 节点的资源使用情况。
• 在数据迁移操作期间，请暂时将 Azure SQL 数据库目标实例纵向扩展到高级层 SKU，以尽量减少在使用较低级别的 SKU 时出现的 Azure SQL 数据库磁盘限制，避免对数据传输活动造成影响。
• 有关详细信息，请参阅博客。

后续步骤

• 什么是 Azure 数据库迁移服务。