有关使用Azure Database Migration Service的常见问题解答

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

• 可靠性和性能。
• 源和目标对的逐次添加。
• 持续投资于无摩擦迁移。

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

从 SQL Server 迁移时，Azure Database Migration Service 支持的数据源包括 SQL Server 2008 及更高版本。

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

Azure Database Migration Service是大规模迁移到Azure的首选方法。 有关Azure Database Migration Service如何与其他Microsoft数据库迁移工具相比，以及在各种情况下使用该服务的建议的详细信息，请参阅 区分Microsoft的数据库迁移工具和服务。

不是。 Database Migration Service不存储客户数据。

对于Azure VM 上的SQL Server，以及Azure SQL Managed Instance目标，DMS 使用物理迁移，即使用备份和还原。 如以下部分所述，选择的迁移模式确定数据在源和目标之间如何保持一致。

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

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

对于 Azure SQL Database 目标，DMS 执行逻辑迁移。 也就是说，它将从源 SQL 数据库的表复制数据，并将其写入目标Azure SQL数据库的表。 由于 DMS 仅支持脱机迁移到Azure SQL Database，因此在迁移启动时，应用程序停机时间将启动。 可以从迁移监视页监视和验证从源数据库表读取的行数（从源数据库表写入目标Azure SQL数据库表）。 作为额外的确认，您可以运行以下 Transact-SQL 以获取源数据库和目标数据库的校验和，并以验证源数据与还原数据是否相同。

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

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

• Azure Monitor
• Azure VM
• Azure Storage
• Azure Service Bus
• Azure Data Factory

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

DMS （经典）利用Azure Service Bus主题促进计算层之间的通信。 Azure Service Bus主题对每个 DMS 实例是唯一的，并且所有个人数据都已加密。

Azure SQL Managed Instance和SQL Server on Azure Virtual Machines

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

Azure SQL Database

迁移至Azure SQL Database需执行两个步骤。 第一步是架构迁移。 DMS （经典）使用 SQL 管理对象（SMO）进行架构迁移。 第二步是实际数据迁移。 使用 SqlBulkCopy 执行数据迁移。 DMS 不支持架构迁移。 使用Azure Data Factory迁移数据。 （可选）但强烈建议使用包含Windows性能数据的文件用于提供工作负载调整建议。

Azure Database for PostgreSQL

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

适用于 MySQL 的 Azure 数据库

在此方案中，架构提取和迁移由 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 PostgreSQL 数据库

与 Oracle Azure SQL Database非常类似，在此方案中，AWR 报表或 Windows perfmon 文件用于提供可选的（但强烈建议）工作负荷大小调整建议。 使用 ora2pg 库提取架构，并由执行迁移的用户手动迁移数据。

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

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

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

默认将使用 TLS 1.2 加密来保护所有传输中数据。 需要旧版 TLS 的旧客户端，需要在 DMS（经典）门户页中启用所需的版本。 对于 DMS，可以将安装 Self-Hosted Integration Runtime 的计算机配置为允许所需的 TLS 设置以适应旧客户端。 有关 SQL Server 的 TLS 配置的详细信息，请参阅 TLS 1.2 对 Microsoft SQL Server。

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

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

默认将使用 TLS 1.2 加密来加密所有传输中数据。 DMS（经典）门户页允许旧版 TLS 用于旧客户端。 对于 DMS，可以将安装 Self-Hosted Integration Runtime 的计算机配置为允许管理 TLS 设置以容纳旧客户端。 有关 SQL Server 的 TLS 配置的详细信息，请参阅 TLS 1.2 对 Microsoft SQL Server。

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

TDE

DMS 支持将客户托管密钥（CMK）迁移到 Azure SQL 的透明数据库加密（TDE）。

单元格加密

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

始终加密 (Always Encrypted)

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

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

我们的服务用于具有不同内部控制和业务流程的各种环境。 DMS 将数据移入和移出其所用帐户可以访问的任何位置。 用户有责任了解他们正在使用的环境的权限和内部控制。 请特别注意确保 DMS 连接到源系统所使用的账户有权查看源系统中所有打算迁移的数据。

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

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

Azure Database Migration Service在所有受支持的迁移方案中通用的先决条件包括：

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

有关使用 Azure Database Migration Service 竞争特定迁移方案所需的所有先决条件的列表，请参阅 Azure Database Migration Service 文档中的相关教程。

可能需要添加防火墙规则，以便Azure Database Migration Service访问源数据库进行迁移。 该服务的 IP 地址是动态的，但如果你使用 ExpressRoute，则企业网络会专门分配此地址。 识别适当的 IP 地址的最简单方法是查找与预配Azure Database Migration Service资源相同的资源组来查找关联的网络接口。 通常，网络接口资源的名称以 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

虽然多个Azure教程可以引导你完成虚拟网络设置过程，但官方文档将显示在文章 Azure Virtual Network。

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

1. 创建目标数据库。
2. 使用 SSMA 评估源数据库。 SSMA 还可以转换数据库对象并将架构迁移到目标平台。
3. 创建Azure Database Migration Service实例。
4. 创建一个迁移项目，指定要迁移的源数据库、目标数据库和表。
5. 开始完整加载。
6. 选择后续验证。
7. 执行从生产环境到新的基于云的数据库的手动切换。

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

如果用户显式停止Azure Database Migration Service（DMS），或者服务在 24 小时内处于非活动状态，则服务处于已停止或自动暂停状态。 在上述每种情况下，服务将不可用并处于已停止状态。 要恢复活跃迁移，请重新启动服务。

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

对于 DMS（经典）：

• 创建服务实例时使用多 CPU 常规用途定价层，使该服务可以利用多个 vCPU 来实现行化和加速数据传输。
• 在数据迁移操作期间，暂时将 Azure SQL Database 目标实例提升到高级层 SKU，以最大程度地减少在使用较低级别 SKU 时可能影响数据传输活动的 Azure SQL Database 限制行为。

对于 DMS：

• 如果您正在将备份从本地文件共享复制到 Azure Blob 存储，或者在执行到目标 Azure SQL 数据库的迁移时，DMS 会使用 SHIR 节点作为其计算资源。 因此，请确保监视该 SHIR 节点的资源使用情况。
• 在数据迁移操作期间，暂时将 Azure SQL Database 目标实例扩展到高级层 SKU，以减少 Azure SQL Database 磁盘限制导致的影响，这些影响在使用较低级别 SKU 时可能会影响数据传输活动。
• 有关详细信息，请参阅 Improving SQL DB Migration Performance - Azure Database Migration Service。

相关内容

• 什么是 Azure Database Migration Service。