迁移指南:SQL Server 到 Azure SQL 数据库

适用于:SQL ServerAzure SQL 数据库

在本指南中,了解如何将 SQL Server 实例迁移到 Azure SQL 数据库。

你可以迁移在本地或以下位置运行的 SQL Server:

  • 虚拟机上的 SQL Server
  • Amazon EC2 (Elastic Compute Cloud)
  • 适用于 SQL Server 的 Amazon RDS(关系数据库服务)
  • Google Compute Engine
  • Cloud SQL for SQL Server - GCP (Google Cloud Platform)

如需更多迁移信息,请参阅迁移概述。 有关其他迁移指南,请参阅数据库迁移

Diagram of migration process flow.

先决条件

若要将 SQL Server 迁移到 Azure SQL 数据库,请确保已执行以下操作:

迁移前

验证你的源环境是否受支持后,开始预迁移阶段。 发现所有现有数据源,评估迁移可行性,确定可能会妨碍迁移的任何阻碍性问题。

发现

在发现阶段,扫描网络以查明你的组织使用的所有 SQL Server 实例和功能。

你可以使用 Microsoft 评估和规划工具包(“MAP 工具包”)来评估你当前的 IT 基础结构。 该工具包提供了功能强大的清单、评估和报告工具,可以简化迁移规划过程。

要详细了解可用于发现阶段的工具,请参阅可用于数据迁移方案的服务和工具

评估

发现数据源后,评估可迁移到 Azure SQL 数据库的任何本地 SQL Server 数据库,以确定迁移阻碍或兼容性问题。

你可以使用数据迁移助手(4.1 及更高版本)来评估要获取的数据库:

若要使用“数据库迁移评估”来评估你的环境,请执行以下步骤:

  1. 打开数据迁移助手 (DMA)
  2. 选择“文件”,然后选择“新建评估” 。
  3. 指定一个项目名称,选择“SQL Server”作为源服务器类型,然后选择“Azure SQL 数据库”作为目标服务器类型。
  4. 选择要生成的评估报告的类型, 例如,数据库兼容性和功能奇偶一致性。 根据评估类型,源 SQL Server 上所需的权限可能有所不同。 在运行评估之前,DMA 会突出显示所选顾问所需的权限。
    • “功能奇偶一致性”类别提供了一套全面的建议、Azure 中可用的替代项以及缓解步骤来帮助你计划迁移项目 (需要 sysadmin 权限)。
    • “兼容性问题”类别标识了可能会阻止迁移的“部分支持或完全不支持的功能”兼容性问题,以及用于解决这些问题的建议(需要 CONNECT SQLVIEW SERVER STATEVIEW ANY DEFINITION 权限)。
  5. 指定 SQL Server 的源连接详细信息并连接到源数据库。
  6. 选择“开始评估”。
  7. 完成此过程后,选择并查看针对妨碍迁移的问题和功能奇偶一致性问题的评估报告。 还可以将评估报告导出到文件,以便与组织中的其他团队或人员共享。
  8. 确定可以最大程度地减少迁移后工作的数据库兼容性级别。
  9. 确定适合你的本地工作负荷的最佳 Azure SQL 数据库 SKU。

若要了解详细信息,请参阅使用数据迁移助手进行 SQL Server 迁移评估

规模化评估和分析

数据迁移助手支持执行规模化评估以及对评估报告进行合并以方便分析。

如果你有多个服务器和数据库需要进行规模化评估和分析(用于提供更广泛的数据资产视图),请参阅以下链接来了解详细信息:

迁移

完成与预迁移阶段相关联的任务后,便可以执行架构和数据迁移。

使用所选的迁移方法迁移你的数据。

本指南介绍了两个最常用的选项 - 数据迁移助手和 Azure 数据库迁移服务。

数据迁移助手 (DMA)

若要使用 DMA 将数据库从 SQL Server 迁移到 Azure SQL 数据库,请执行以下步骤:

  1. 下载并安装数据库迁移助手
  2. 创建一个新项目,并选择“迁移”作为项目类型。
  3. 将源服务器类型设置为“SQL Server”,将目标服务器类型设置为“Azure SQL 数据库”,选择“架构和数据”作为迁移范围,然后选择“创建”。
  4. 在迁移项目中,指定源服务器详细信息(例如服务器名称)、用于连接到服务器的凭据,以及要迁移的源数据库。
  5. 在目标服务器详细信息中,指定 Azure SQL 数据库服务器名称、用于连接到服务器的凭据,以及要迁移到的目标数据库。
  6. 选择架构对象并将其部署到目标 Azure SQL 数据库。
  7. 最后,选择“开始数据迁移”并监视迁移进度。

有关详细教程,请参阅使用数据迁移助手将本地 SQL Server 或 Azure VM 上的 SQL Server 迁移到 Azure SQL 数据库

注意

导入后的数据库的兼容性级别基于源数据库的兼容性级别。

Azure 数据库迁移服务 (DMS)

若要使用 DMS 将数据库从 SQL Server 迁移到 Azure SQL 数据库,请执行以下步骤:

  1. 在订阅中注册 Microsoft.DataMigration 资源提供程序(如果尚未这样做)。
  2. 在选定的所需位置创建 Azure 数据库迁移服务实例(最好与目标 Azure SQL 数据库位于同一区域)。 选择一个现有虚拟网络或新建一个虚拟网络来承载 DMS 实例。
  3. 创建 DMS 实例后,创建一个新的迁移项目,将源服务器类型指定为“SQL Server”,将目标服务器类型指定为“Azure SQL 数据库”。 在迁移项目创建边栏选项卡中选择“脱机数据迁移”作为活动类型。
  4. 在“迁移源”详细信息页上指定源 SQL Server 详细信息,在“迁移目标”详细信息页上指定目标 Azure SQL 数据库详细信息。
  5. 映射用于迁移的源数据库和目标数据库,然后选择要迁移的表。
  6. 复查迁移摘要,然后选择“运行迁移”。 然后,你可以监视迁移活动,并检查数据库迁移进度。

有关详细教程,请参阅使用 DMS 将 SQL Server 迁移到 Azure SQL 数据库

数据同步和直接转换

当使用将数据更改持续从源复制/同步到目标的迁移选项时,源数据和架构可能会变化并偏离目标。 在数据同步过程中,请确保在迁移过程中捕获对源的所有更改并将其应用到目标。

验证源和目标上的数据是否相同后,可以从源环境直接转换到目标环境。 请务必与业务/应用程序团队一起计划直接转换过程,以确保在直接转换过程中最大限度地减少中断,不影响业务连续性。

重要

有关与使用 DMS 进行迁移时执行直接转换相关的特定步骤的详细信息,请参阅执行直接转换迁移

使用事务复制进行迁移

如果在发生迁移时你无法承受从生产中删除 SQL Server 数据库的后果,可以使用 SQL Server 事务复制作为迁移解决方案。 若要使用此方法,源数据库必须满足事务复制要求且兼容 Azure SQL 数据库。 有关使用可用性组的 SQL 复制的信息,请参阅配置 Always On 可用性组 (SQL Server) 的复制

要使用此解决方案,请将 Azure SQL 数据库中的数据库配置为要迁移的 SQL Server 实例的订阅服务器。 在新的事务不断发生时,事务复制分发器将对要同步的数据库(发布服务器)中的数据进行同步。

使用事务复制时,对数据或架构所做的所有更改都会显示在 Azure SQL 数据库中的数据库中。 同步完成后,如果你已准备好进行迁移,则可更改应用程序的连接字符串,使其指向数据库。 在事务复制排出源数据库上剩余的所有更改,并且所有应用程序都指向 Azure SQL 数据库之后,可以卸载事务复制。 Azure SQL 数据库中的数据库现在是生产系统。

提示

还可以使用事务复制来迁移源数据库的子集。 复制到 Azure SQL 数据库的发布可以限制为复制的数据库中表的子集。 对于所复制的每一个表,可以将数据限制为行的子集和/或列的子集。

事务复制工作流

重要

使用最新版本的 SQL Server Management Studio 以与 Azure 和 SQL 数据库的更新保持同步。 较旧版本的 SQL Server Management Studio 不能将 SQL 数据库设置为订阅服务器。 获取最新版本的 SQL Server Management Studio

步骤 方法
设置分发 SQL Server Management Studio | Transact-SQL
创建发布 SQL Server Management Studio | Transact-SQL
创建订阅 SQL Server Management Studio | Transact-SQL

有关迁移到 SQL 数据库的一些提示和差异

  • 使用本地分发服务器
    • 这会对服务器产生性能影响。
    • 如果性能影响无法接受,可使用其他服务器,但会增加管理的复杂性。
  • 选择快照文件夹时,请确保选择的文件夹足够大,可以保存想要复制的每个表的 BCP。
  • 快照创建操作在完成之前会锁定关联的表,因此,请适当地计划好快照。
  • Azure SQL 数据库中仅支持推送订阅。 只能从源数据库添加订阅服务器。

迁移建议

若要加快迁移到 Azure SQL 数据库的速度,应考虑以下建议:

资源争用 建议
源(通常在本地) 迁移期间在源方面的主要瓶颈是数据文件 I/O 和延迟,需要仔细监视。 根据数据文件 I/O 和延迟,以及它是虚拟机还是物理服务器,你可能需要与存储管理员联系,并探索各种选项来缓解该瓶颈。
目标(Azure SQL 数据库) 最大的限制因素是日志生成速率和数据库日志文件的延迟。 使用 Azure SQL 数据库时,日志生成速率最高可达 96 MB/秒。 要加快迁移速度,请将目标 Azure SQL 数据库纵向扩展到业务关键 Gen5 8 vCore,以获取 96 MB/秒的最大日志生成速率,这也为日志文件提供了低延迟。 无论选择哪种服务级别,超大规模服务层级都提供 100 MB/秒的日志速率。
Network 所需网络带宽等于最大日志引入速率 96 MB/秒(768 Mb/秒) 根据本地数据中心到 Azure 的网络连接情况,检查网络带宽(通常是 Azure ExpressRoute),使其适应最大日志引入速率。
用于数据迁移助手 (DMA) 的虚拟机 对于运行 DMA 的虚拟机来说,主要的瓶颈是 CPU 通过以下项来加速数据迁移时的注意事项:
- Azure 计算密集型 VM
- 使用至少 F8s_v2 (8 vCore) VM 运行 DMA
- 确保 VM 在与目标相同的 Azure 区域中运行。
Azure 数据库迁移服务 (DMS) DMS 可能存在计算资源争用和数据库对象考虑。 使用高级 4 vCore。 DMS 会自动处理数据库对象(如外键、触发器、约束和非聚集索引),无需手动干预。

还可考虑以下建议,以在迁移过程中获得最佳性能。

  • 若要获得最高的传输性能,请在预算允许范围内选择最高的服务层级和计算大小。 为了节省资金,可以在迁移完成后缩减规模。
  • 如果使用 BACPAC 文件,尽量缩短 BACPAC 文件和目标数据中心的距离。
  • 在迁移期间禁用自动更新和自动创建数据统计。
  • 分区表和索引。
  • 删除已编制索引的视图,在完成后重新创建这些视图。
  • 将很少查询的历史数据转移到其他数据库,将这些历史数据迁移到 Azure SQL 数据库中的单独数据库。 然后,可以使用 弹性查询来查询这些历史数据。

迁移后

成功完成迁移阶段后,执行以下迁移后任务,确保一切顺利高效地进行。

迁移后阶段对于协调任何数据准确性问题、验证完整性以及解决工作负载的性能问题至关重要。

更新统计信息

在迁移完成后更新统计信息并进行完全扫描。

修正应用程序

将数据迁移到目标环境后,以前使用源的所有应用程序都需要开始使用目标。 在某些情况下,实现这一点需要对应用程序进行更改。

执行测试

数据库迁移的测试方法包括以下活动:

  1. 开发验证测试:要测试数据库迁移,需要使用 SQL 查询。 必须创建针对源数据库和目标数据库运行的验证查询。 验证查询应涵盖已定义的范围。
  2. 设置测试环境:测试环境应包含源数据库和目标数据库的副本。 请确保隔离测试环境。
  3. 运行验证测试:针对源和目标运行验证测试,然后分析结果。
  4. 运行性能测试:针对源和目标运行性能测试,然后分析和比较结果。

使用高级功能

请确保利用 Azure SQL 数据库提供的基于云的高级功能,例如内置高可用性威胁检测以及监视和优化工作负荷

只有将数据库兼容性级别更改为最新的兼容性级别后,某些 SQL Server 功能才可用。

要了解详细信息,请参阅在迁移后管理 Azure SQL 数据库

解决数据库迁移的兼容性问题

你可能会遇到各种各样的兼容性问题,具体取决于源数据库中的 SQL Server 版本以及正在迁移的数据库复杂性。 旧版 SQL Server 的兼容性问题更多。 除了使用所选搜索引擎的目标 Internet 搜索以外,还可以使用以下资源:

重要

使用 Azure SQL 托管实例可迁移现有 SQL Server 实例及其数据库,而几乎不会出现兼容性问题。 请参阅什么是 Azure SQL 托管实例?

后续步骤

有关在执行各种数据库和数据迁移方案及专门任务时可为你提供帮助的 Azure 与第三方服务和工具的矩阵,请参阅数据迁移服务和工具

若要详细了解 SQL 数据库,请参阅:

要详细了解云迁移的框架和采用周期,请参阅:

若要评估应用程序访问层,请参阅 Data Access Migration Toolkit(预览版)

若要详细了解如何执行数据访问层 A/B 测试,请参阅数据库实验助手