目录
1 引言
Azure SQL 数据库是一种完全托管的服务，与传统的本地 SQL Server 部署相差无几，但通过轻松提高性能和存储容量并提供标准的高可用性显著提升了 SQL 的性能和稳健性。Azure SQL 数据库可在多个服务级别提供可预测的性能，在不停机的情况下提供动态可扩展性以及内置智能优化、全局可扩展性和可用性与高级安全选项，所有这些几乎都不需要管理。通过这些功能，你可以专注于快速开发应用并缩短上市时间，而不是将宝贵的时间和资源用于管理虚拟机和基础架构。
客户本地数据中心拥有大量的存量数据，那么如何从传统的本地 SQL Server 实施迁移到现代 Azure SQL 数据库技术并从云数据库服务提供的功能中受益呢？本白皮书将指导你完成将数据库工作负载从本地迁移到基于 Azure 的云数据服务。
数据库迁移服务作为北京贝斯平云科技有限公司Microsoft Azure云数据库解决方案的重要组成部分，在整个数据库产品中扮演非常重要的角色。迁移工具为不同数据库的数据移植提供了重要地手段支撑。
1.1 目标受众
本白皮书适用于希望通过将本地 SQL Server 工作负载迁移到 Microsoft Azure 云服务来实现数据现代化的数据专业人员、IT 专业人员和 IT 决策者。
1.2 先决条件
我们假设读者对 Microsoft SQL Server 和 Microsoft Azure 云服务有一定的了解和基本操作能力。
2 迁移概述
SQL 迁移路线图由五个阶段组成，每个阶段都包含成功迁移到 Azure 云服务需要完成的几项重要任务。
每个阶段的目的可以概括如下，我们将在以下各节深入地探讨每个阶段：
- 启动和发现：解你的数据库占用空间和潜在的迁移方法
- 评估：估已发现工作负载的要求和任何依赖关系
- 计划：划和描述要迁移的工作负载、用于迁移的工具以及工作负载的目标平台
- 转换和优化：转换目前与现代数据平台不兼容的任何工作负载。优化工作负载以利用新功能
- 迁移、验证和修复：进行迁移、验证成功的迁移，并根据需要修复应用程序
3 启动和发现
迁移路线图的第一阶段是启动和发现。在第一阶段，目标是确定三个要素：
- 你的数据资产的清单
这包括哪些数据可用、数据所在的位置、所驻留的平台以及数据的大小。
- 应用程序数据库依赖关系
应用程序通常会使用多个数据库或与具有自己数据库的其他应用程序集成。我们需要了解数据库与其他数据库的 依赖关系，以便根据这些关系将它们在逻辑上组合在一起。
- 哪些数据库一起迁移
按关系进行逻辑分组之后，我们就可以使用这些分组来构成成批的数据库以迁移到 Azure。
Azure 数据库迁移服务集成了一些现有工具和服务的功能。 它为客户提供高度可用的综合解决方案。 该服务使用数据迁移助手生成评估报告，这些报告提供建议以指导你在执行迁移之前完成所需的更改。 你可以自己选择执行所需的修正。 准备好开始迁移过程时，Azure 数据库迁移服务会执行所有必需的步骤。 该过程利用了 Microsoft 确定的最佳做法，因此你便可以在启动迁移项目后高枕无忧。
为了实现这些目标，Microsoft 提供了许多资源和工具。其中包括：
数据库迁移指南
新的《数据库迁移指南》适用于愿意迁移到 Azure 云服务（即从 Oracle 或
SQL Server 迁移到 Azure 数据服务）的企业客户、合作伙伴和业务决策者。
数据库迁移指南为执行迁移提供了全面的分步指导，并帮助发现可用于帮助客户执行这些迁移的指南、工具、软件和程序。
Microsoft Assessment & Planning (MAP) Toolkit
利用 Microsoft Assessment & Planning (MAP) Toolkit，你可以针对各种技术迁移项目轻松评估当前的 IT 基础架构。此解决方案加速器提供了强大的清单、评估和报告工具，可简化迁移规划过程。MAP Toolkit 虽然不是完全针对数据库迁移，但包含有关可以在云迁移规划中使用的数据库和服务器软件的信息。
数据迁移助手 (DMA)
借助数据迁移助手 (DMA)，你可以通过检测可能影响 Azure SQL 数据库中的数据库功能的兼容性问题来升级到 Azure 数据服务。它会提出有关你的目标环境的性能和可靠性改进的建议。利用它，你不仅可以将架构和数据从源服务器迁移到目标服务，还可以同样迁移未包含的对象。DMA 取代了旧 SQL Server 升级顾问工具，应该用于从大多数 SQL Server 版本进行升级和迁移。
本白皮书将介绍使用 数据迁移助手 (DMA) 将 SQL Server 迁移到 Azure SQL 数据库
数据迁移助手 (DMA)可以从 Microsoft 网站免费下载，可帮助将本地 SQL Server 实例迁移到 Azure SQL 数据库或在 Azure 虚拟机上托管的现代 SQL Server 实例。
DMA 允许你定义用于数据评估或数据迁移的项目。对于这两种类型，在创建项目时定义所需的源类型和目标类型。评估项目使用 DMA 评估工作流来帮助你检测可能影响 Azure SQL 数据库迁移的问题，然后针对如何解决这些问题提供详细指导。
迁移项目将使用 DMA 的迁移工作流来帮助你将选定的数据从源迁移到目标，并完成两个实体之间的复制过程。
4 评估
管理员知道并清楚正在处理哪些工作负载，它们在哪里，有多大容量以及它们的用途。从启动和发现阶段获得的这些 数据现在可用于输入到第二阶段– 评估中。需要对数据进行汇编和分析，以实现我们在这一阶段的目标，即确定：
- 阻碍迁移的因素
在解决这些问题之前，迁移将无法继续。
- 中断性更改
迁移能够继续进行，但需要在迁移后修复工作负载才能正常工作。
- 要利用的功能
可用的 Azure 功能，使用这些功能可以最大程度地增加迁移到 Azure 服务的好处。
- 解决问题所需的工作
纠正上述突出问题所需的预估时间和流程。为实现这些目标，对工作负载进行更仔细的评估，重点包括以下方面：
- 评估要进行迁移的工作负载
- 评估工作负载标准
- 使用数据迁移助手评估数据库
4.1 评估要进行迁移的工作负载
要制定完整的迁移计划，在迁移之前对工作负载进行全面评估将有助于确定哪些数据库需要迁移到云以及所涉及的 数量。
如果打算将所有本地工作负载迁移到 Azure 云服务，应进行初步评估并尽可能合并或停用旧工作负载，这有助于减少需要迁移的数据库工作负载的最终数量。
应调查正在使用的本地应用程序现在是否有基于 SaaS 或托管的部署模型，如果有，请考虑迁移到该平台以降低管理成本。
通过迁移任何工作量少、影响大的数据库来继续实施云迁移之路。也就是说根据业务影响对发现的工作负载进行 隔离。
与在整个企业内广泛使用的应用程序相比，企业中指定数量的用户所使用的应用程序的工作负载所造成的中断范 围应该较小。非关键工作负载（如开发、测试和培训平台）将成为第一批迁移的理想候选项。
接下来，可以根据在启动和发现阶段突出显示的问题的严重性对工作负载进行进一步排名。阻碍迁移的因素或已 知的中断性更改可能需要大量的修复工作，并将工作负载定位在迁移列表中的合适位置。
同样，行为更改可能意味着在过渡到云之前需要对某些工作负载进行更多调查和规划，以充分了解所有影响。你仍然可以对使用弃用功能的任何工作负载进行迁移，但需要稍后进行调查，以消除它们对这些弃用功能的依赖。
使用连续迁移
企业内部使用的关键应用程序可能无法承受将工作负载迁移到云所需的可度量的停机窗口。它们还可能依赖于需要在同一分组中迁移的其他工作负载以及所有分组应用程序中的数据大小（决定在工作负载上复制数据时停机窗口所需的时间长度）。
通过使用连续迁移方法，应用程序可以继续使用源数据库，而大部分数据在后台同步到云。迁移过程中更改的任何数据都会动态复制到目标平台，从而确保保留所有数据事务。
此方法可大大减少总体停机时间，因为停机时间仅限于完成将消耗应用程序重建到目标数据库的最后一步所需的 时间。
4.2 评估工作负载标准
性能要求
应了解每个工作负载使用资源的多少，并衡量迁移后需要多少 Azure 资源，这一点非常重要。如果希望过渡到 Azure IaaS 虚拟机上的 SQL Server，可能只需与当前分配给目标平台上虚拟机的计算核心数量相匹配。如果迁移到Azure SQL 数据库，这可能需要计算每个数据库所需的数据库事务单位 (DTU) 或虚拟核心 (vCore) 的数量。Azure
SQL 数据库提供了用于评估和购买计算的两种不同模型：基于 DTU 的计算模型和基于 vCore 的计算模型。
什么是数据库事务单位 (DTU)？
利用数据库事务单位（即 DTU）对 Azure SQL 数据库的性能进行评估，它是 CPU、内存和 I/O 的汇总指标。DTU 可用于了解在不同 Azure SQL 数据库之间分配的资源的相对数量，因为不同可用性能级别以分配的 DTU 为特点。例如，基本性能级别的最大 DTU 数为 5，而对于标准性能级别，从“S0”实例对应的最大 DTU 数 10 开始，到“S12”实例时最大 DTU 数增加到 3000。P15 是可用的最高性能级别，可实现多达 4000 个 DTU。基于 DTU 的模型为那些需要预配置解决方案的用户提供了简便性。
什么是 vCore？
虚拟核心 (vCore) 表示逻辑 CPU，可以在多代硬件之间进行选择。第 4 代逻辑 CPU 基于 Intel E5-2673 v3 (Haswell)
2.4 GHz 处理器，第 5 代逻辑 CPU 基于 Intel E5-2673 v4 (Broadwell) 2.3 GHz 处理器。基于 vCore 的模型为那些希望通过独立配置计算、存储和 I/O 来优化云中工作负载的用户提供了更多的选择和灵活性。例如，Azure SQL 数据库托管实例允许你从 8、16 或 24 个 vCore 实例和最高 8 TB 的存储中进行选择。
合规性要求
确定是否有任何特定的安全或法规要求。Microsoft 的可信云计划是围绕安全、隐私、合规性和透明度这四项基本原则构建的，反映在通过 Azure 提供的平台和服务中。Azure 数据中心遵守严格的法规和合规性标准，可帮助客户满足国际数据保护法律和行业要求。数据驻留法还可能意味着特定应用程序的数据必须保留在国家或地理区域内， 从而限制可以使用哪些 Azure 数据中心。
迁移停机
了解要迁移的工作负载的业务要求。是否可以接受停机？这将影响迁移方法、使用的工具集以及所需的时间范围。
可用性
继迁移停机之后，工作负载的持续可用性要求是什么？Azure SQL 数据库作为标准在本地具有高可用性，数据库的
三个副本用于在修补和瞬态硬故障期间使数据保持联机且可以访问。Azure 虚拟机上的 SQL Server 需要 HA 技术， 如“Always On 故障转移群集”、“Always On 可用性组”、数据库镜像或日志传送。
灾难恢复
确定数据库支持的应用程序工作负载是否具有灾难恢复要求，并了解 RTO 和 RPO 要求。在 Azure SQL 数据库上实现灾难恢复只需点击几下即可以最低的成本在区域外建立数据库副本，异地复制功能可保护数据库和应用程序免受 更广泛的区域故障的影响。Azure IaaS 虚拟机上的 SQL Server 没有现成的灾难恢复支持，可能需要使用 Always On 可用性组来实施 SQL Server 企业版，以满足任务关键型工作负载严格的 RTO 要求。当虚拟服务器级别的保护可以接受时，使用 Azure Site Recovery 的优先级较低的工作负载通常就够用了。
自定义工作负载
可能有些数据库集成了第三方工具，Azure SQL 数据库目前不支持此类集成。可能需要与第三方供应商联系以了解考虑的兼容版本或替代产品。
4.3 使用数据库迁移助手 (DMA) 进行数据库评估
如前所述，数据迁移助手 (DMA) 是 Microsoft 提供的可免费下载的工具，可在本地安装和执行。借助 DMA，你可以通过先检测可能影响数据库功能的兼容性问题，然后尝试迁移到新版 SQL Server 或 Azure SQL 数据库来升级到现代数据平台。它还就如何解决这些问题提出了建议。
- 评估迁移到 Azure SQL数据库的本地 SQL Server 实例
- 发现可能影响升级到本地 SQLServer 的问题
- 发现目标 SQLServer 平台中可让数据库在升级后获益的新功能
- 将本地 SQLServer 实例迁移到现代化 SQL Server 实例
使用 DMA 时，应首先评估和确定源数据库中阻碍成功迁移的问题。有了这些信息，你必须修正根本原因或针对每个发现问题实施替代方法。然后重复评估和修复过程，直到源数据库通过所有 DMA 测试，此时就可以信心十足地将源数据库的架构部署到云中的目标数据库。
4.4 使用 DMA 进行评估的步骤
若要使用 DMA 建立评估，请执行以下步骤。
1.下载DMA，然后安装。
2.创建“新建评估”项目。
a.选择“新建 (+)”图标，然后选择“评估”项目类型，指定项目名称，选择“SQL Server”作为源，选择“Azure SQL 数据库”作为目标，然后选择“创建”。
b.选择一种或两种评估报告类型（“检查数据库兼容性”和“检查功能对等性”），然后选择“下一步”。选择“新建 (+)”图标，然后选择“评估”项目类型，指定项目名称，选择“SQL Server”作为源，选择“AzureSQL数据库”作为目标，然后选择“创建”。
c.在“连接到服务器”边栏选项卡中，指定要连接到的 SQLServer 实例的名称，指定身份验证类型和连接属性，然后选择“连接”。
d.在“添加源”弹出窗口中，选择要评估的数据库，然后选择“添加”。
e.选择“开始评估”。
现在等待评估结果；评估的持续时间取决于添加的数据库数量和每个数据库的架构大小。结果出来后， 会立即按每个数据库显示。
f.选择已完成评估的数据库，然后选择“兼容性问题”以查看分类为“阻止迁移的因素”、“行为更改”和
“弃用功能”的不兼容对象。
同样，你可以查看针对性能、存储和安全性方面的建议。功能建议涵盖各种功能，如内存中 OLTP 和列存储、Stretch Database、Always Encrypted、动态数据掩码和透明数据加密。
g.选择“SQL Server 功能对等性”可查看 AzureSQL 数据库中不支持的功能或部分支持的功能。
3.查看评估结果
a.完成所有数据库评估后，选择“导出报告”将结果导出到 JSON或 CSV 文件，以便在你方便时分析数据。
5 计划
迁移路线图的第三阶段是计划。在这个最重要的阶段，目标是为每个工作负载确立两个关键要素：
- 目标平台
这是每个工作负载的最终位置。
- 一次性迁移与连续同步
一次性迁移意味着工作负载可以脱机，而连续同步意味着在迁移过程中工作负载源数据库需要始终可
以下部分将指导你做出这些决策，并帮助你使用以下主题为每个工作负载制定行动计划：
- 规划目标平台
- 如何选择合适的目标平台
- 规划迁移工具
- 目标平台选择示例
5.1 规划目标平台
在完成对源环境的评估并了解工作负载要求后，你可以选择目标位置：
Azure SQL 数据库
图 19 可用的 Azure 数据库平台
Azure SQL 数据库是 Azure 中的一个完全托管的服务产品，你可以借助它通过在虚拟机中运行你自己的 SQL Server 的大部分功能创建一个数据库，而不必担心操作其中的虚拟机部分。因为 Microsoft Operations 可为你处理所有基础操作系统和应用程序事务，所以可以避免相关的维护和管理开销。
Azure SQL 数据库在基于 DTU 的模型中提供了三个服务层以支持从轻量级到重量级的数据库工作负载：
- 基本
- 标准
- 高级
服务层影响数据库的规格和特性，包括大小、性能级别、可用性和并发性。所选择的服务层决定了对可实现性能
（以数据库事务单位 (DTU) 衡量）以及数据库大小的限制。
- 基本：最适合小型数据库，尤其是处于开发阶段的数据库。大小限制为 2GB，并且只分配有限的计算资源。
- 标准：最适合具有中等性能要求的通用数据库，因此很可能包括大部分 AzureSQL 数据库。支持最高 250 GB 的数据库。
- 高级：专为具有高性能要求和高可用性要求的任务关键型数据库而设计。高级服务层具有较低的延迟，可以支持高输入/输出工作负载以及最大 4TB 的数据库。
你能以较低的每月成本在单个小型数据库上构建第一个应用，然后随时手动或以编程方式更改其服务层，从而满 足解决方案的需求。你可以在不停机的情况下针对应用或客户的需求进行性能调整。动态可扩展性使你的数据库 能够透明地响应快速变化的资源需求，并使你能够根据需要只为所需的资源付费。
Azure SQL 数据库在其基于 vCore 的模型中提供了两个服务层：
- 通用
- 业务关键型
对于使用 DTU 模型的现有 SQL 数据库应用程序，“通用”服务层相当于标准版。“业务关键型”服务层相当于高级版。基于 vCore 的服务层通过独立控制计算和存储配置提供了灵活性，以便你可以根据应用程序的具体要求对其进行优化并支付相应的费用。
- 通用：大多数业务工作负载。提供面向预算的平衡且可扩展的计算和存储选项。
- 业务关键型：最适合 IO 要求较高的业务应用程序。使用多个隔离的副本提供最高的故障恢复能力。
为什么使用 Azure SQL 数据库？
Azure SQL 数据库可在多个服务级别提供可预测的性能，它可以提供：
- SQL Server引擎兼容性和本机虚拟网络 (VNET) 支持
- 不会造成停机的动态可扩展性
- 内置智能优化、全局可扩展性和可用性以及高级安全选项
- 消除硬件成本并降低管理成本
- AzureSQL 数据库内置容错基础架构功能，提供自动备份、时间点还原、异地还原和活动异地复制以增加在
Azure SQL 数据库中托管数据的应用程序的业务连续性。
Microsoft Azure SQL 数据库可以在服务层之间进行更改，以便随着数据库需求的不断增长，你可以轻松地分配更多的资源和容量（需要支付额外费用）。通过 Azure 门户或 PowerShell 脚本更改层可以触发后台操作来创建数据库的副本，然后在切换时出现仅几秒钟的短暂中断。这也意味着，在初始容量调整过程中对容量估计不足很容易在后一个阶段得到纠正。最高 4TB 的数据库或更大的数据库，可使用横向扩展模式进行水平或垂直分区
Azure SQL 数据库托管实例
Azure SQL 数据库托管实例提供广泛的 SQL Server 兼容性和网络隔离，因此可以轻松地将 SQL Server 数据库直接迁移到 Azure。现在，你只需备份本地数据库并将其还原到 Azure SQL 数据库托管实例中。它基于与 Azure SQL 数据库相同的完全托管服务产品基础架构而构建，并保持所有 Azure SQL 数据库功能，如活动异地复制、高可用性、自动备份、数据库顾问、威胁检测、智能见解和漏洞评估。它还支持最高 8 TB 的数据库以及 SQL 代理、跨数据库查询和复制等 SQL Server 功能。
使用 Azure SQL 数据库托管实例的原因：对于希望以尽可能少的工作量从本地或虚拟机/托管、自建或 ISV 提供的计算机上迁移大量 SQL Server 数据库的组织，托管实例提供了一种简单、安全且经济的迁移目标。
- 隔离环境（支持 VNET 的单租户服务、专用计算和存储资源）
- 客户可配置的备份保留和恢复
- 用于高级工作负载分析的数据库顾问和日志分析
- 为实现可预测性能的自动数据库调整和维护
- 大规模监控、故障排除和管理
- 用于手动服务设置和扩展的 Azure门户功能
- AzureAD 身份验证、单点登录支持
- 遵守与 Azure SQL数据库相同的合规性标准
- 使用客户提供的加密密钥对传输中的数据和静态数据进行加密
- 没有修补和版本升级开销
Azure 虚拟机上的 SQL Server
在 Azure 上运行的 Windows Server 虚拟机（也称为基础架构即服务 (IaaS)）上的云中安装和托管的 SQL Server。Azure 虚拟机上的 SQL Server 针对迁移现有 SQL Server 应用程序进行了优化。SQL Server 的所有版本都可以使用。虚拟机完全兼容 SQL Server，让你可以根据需要托管任意数量的数据库并执行跨数据库事务。虚拟机允许对 SQL Server 和 Windows 进行完全控制。
为何使用 Azure 虚拟机上的 SQL Server？
虚拟机非常适合需要以最少的更改快速迁移到云的现有应用程序。当你不愿购买本地非生产 SQL Server 硬件时，虚拟机非常适合快速开发和测试场景。
在云中使用虚拟机进行 SQL Server 部署的其他原因：
- 配置和管理 SQLServer 的高可用性、灾难恢复和修补比本地计算机更容易
- 具有完全管理权限的定制环境
- SQL Server实例具有高达 64 TB 的存储空间和所需的任意数量数据库
- 完全支持 SQL Server 事务复制、AlwaysOn 可用性组、集成服务、用于复制数据的日志传送和传统的 SQL Server
备份
5.2 如何选择合适的目标平台
在为每个工作负载选择合适的目标平台时，需要考虑以下三个因素：
- 使用场景
- 功能
- 总拥有成本
5.3 按使用场景选择目标平台
Azure SQL 数据库单一数据库和弹性池
Azure SQL 数据库非常适合正在开发新的 SaaS 多租户应用程序或有意将现有本地应用程序转换为 SaaS 多租户应用程序的客户。Azure SQL 数据库单一数据库、弹性池和本地 SQL Server 之间存在较大的差异，因此将本地数据库工作负载直接迁移到 Azure SQL 数据库通常并不轻松。同样，第三方应用程序尚不支持 Azure SQL 数据库平台。
此版本的 SQL Server 专为实现高水平的正常运行时间目标而设计，以高可用性为标准，可以进行扩展以提供异地复制拓扑。
Azure SQL 数据库托管实例
托管实例非常适合希望以尽可能少的迁移工作量从本地或虚拟机/托管、自建或 ISV 提供的计算机上迁移多个应用程序的客户。
此外，以下特性使托管实例更受欢迎：
- 与本地SQL Server 的高度兼容性
- 支持利用 VNET 支持与专用 IP地址和 VPN 将工作负载从公共 Internet 隔离到本地网络
Azure 虚拟机上的 SQL Server
虚拟机可以帮助需要自定义操作系统或数据库服务器的客户以及在与 SQL Server 并行运行第三方应用（在同一虚拟机上）方面有特殊要求的客户。
5.4 按功能选择目标平台
Azure SQL 数据库单一数据库和弹性池
如果应用程序表面区域属于数据库范围，则适合使用 Azure SQL 数据库。
如果应用程序使用某些 SQL 功能，则 Azure SQL 数据库可能不合适，因为并非所有功能都可用。
Azure SQL 数据库托管实例
如果应用程序表面区域属于实例范围并且需要 Azure SQL 数据库中不提供的以下功能，则适合使用此平台：
- SQL代理
- MSDTC
- DQS
- MDS
- 数据库邮件
- Filestream
- FileTable
- Polybase
其他功能包括：
- 支持链接服务器
- 支持新的 Azure云服务，如威胁检测
Azure IaaS 上的 SQL Server
如果应用程序表面区域属于实例范围并且需要 Azure SQL 数据库托管实例中不提供的以下功能，则适合使用此平台： 此外，还支持以下本地实例：
- SSRS
- SSAS
- SSIS
5.5 按成本选择目标平台
Azure SQL 数据库
与 Azure IaaS 拓扑上更传统的 SQL Server 相比，Azure SQL 数据库的平台即服务本质大大降低了管理成本，因为大多数所需的工作都是由 Microsoft Operations 安静地在后台为你完成的。在大规模时这一点显而易见，可以节省大量时间和工作量。
Azure SQL 数据库弹性池
Azure SQL 数据库弹性池如果由具有不可预测的不同使用需求的多个数据库使用，则可以节省大量成本。在池中的所有数据库之间共享计算资源意味着客户不需要为了满足偶尔出现的使用峰值为所有数据库过度预配资源。由于大多数所需的工作都是由 Microsoft Operations 安静地在后台完成的，因此在降低服务器维护和管理成本方面节省了更多费用。
Azure SQL 数据库托管实例
托管实例提供给那些需要完全托管的服务产品的客户，他们可以利用此产品轻松地直接迁移本地环境，并最大限度减少所需的配置更改。该环境至少提供 8 个核心和最多 35 TB 的存储，并且位于一个独立的虚拟网络中。此产品非常适合希望快速迁移到云并希望避免虚拟机开销的客户。
Azure 虚拟机上的 SQL Server
虚拟机的计算、存储和管理成本高于 Azure SQL 数据库产品，但可以更好地控制 SQL Server 和基础架构。
5.6 规划迁移工具
通常，应用程序所有者规定的可接受的停机时间或维护时段将决定需要使用哪种迁移方法以及匹配的相应迁移工具。
关键（零停机）– SQL Server Management Studio (SSMS) 事务复制高（短维护时段）– Azure 数据库迁移服务 (DMS)
低（长维护时段）– SQL Server Management Studio BACPAC 导出/导入
对于必须保持联机且可用的关键工作负载，使用事务复制技术可以在后台将大部分数据复制到 Azure，然后将目标数据与源数据保持同步，直到进行切换。SQL Server Management Studio 可用于建立此复制过程。
对于能够承受一些停机时间的重要应用程序，应使用 Azure 数据库迁移服务执行初始评估，并以一致且正确的方式迁移数据。
最后，SQL Server Management Studio 可用于以 BACPAC 文件的形式导出数据库的数据和架构。对于较大的数据库，导出和导入 BACPAC 所需的时间可能较长，因此这种方法最适合具有较长维护时段的低优先级工作负载。
5.7 目标平台选择示例
在本节中，我们将介绍客户工作负载和需求的示例，并决定合适的目标平台以及我们迁移到该平台需要使用的方法。
示例 1 – Azure SQL 数据库单个数据库
客户有一个使用本地 SQL Server 2008 R2 安装的应用程序。此应用程序是全天候业务关键型应用程序，一年中的任何停机都会对它产生重大影响。这种严格的运营要求意味着没有可用的定期维护时段，并且不可接受计划外维护。为此，底层基础架构专为实现高可用性而设计，并在所有组件之间实现完全冗余。实际数据库每年的增长最小，但事务频率极高，需要大量的计算资源以及较低的延迟/高吞吐量存储和网络。所有组件上的冗余要求意味着有大量的 SQL Server、虚拟机、存储和网络，因此数据库管理员和系统管理员在相当长的时间里都非常忙碌，而他们宁愿将这些时间用于提高应用程序的性能和安全性。
解决方案：
在这种情况下，使用 Azure SQL 数据库完全托管的服务产品平台非常有益，因为它消除了管理计算和存储要求的问题。由于 Azure SQL 数据库（以本地高可用性作为标准）可满足 99.99% 正常运行时间的 SLA，以及可以使用异地复制实现区域高可用性和灾难恢复，高正常运行时间要求应能轻松满足。Azure SQL 数据库的高级性能层能够实现
2 毫秒 IO 延迟，IO 吞吐量的测量速度约为每个 DTU 48 IOPS，其性能水平与企业基于闪存的 SAN 存储设备相当。
由于所涉及的数据量非常大，缺失允许的维护时段意味着无法使用备份和还原技术将本地数据库迁移到 Azure SQL 数据库。通过 WAN 连接复制备份文件所需的时间过长。而事务复制将用于同步后台的数据，同时保持源数据库联机且可用。
迁移到 Azure SQL 数据库就无需监控、修补和修复本地解决方案中的众多服务器，从而节省硬件成本和管理开销。
该应用程序还将受益于 Azure SQL 数据库的内置智能优化和监视功能。Azure SQL 数据库顾问可以针对应添加的缺失索引或可以删除的未使用索引提供建议，以主动提高应用程序性能。Azure SQL 数据库智能见解通过将当前数据库工作负载与历史基线进行比较来分析 SQL 数据库性能，以揭示性能下降及其可能的原因。可以通过 Azure 安全中心利用威胁检测来检测潜在威胁，并在出现威胁时进行应对。
示例 2- Azure SQL 托管实例
客户有一个基于本地 SQL Server 的定制应用程序，其中包含与知识产权相关的敏感数据。应用程序代码在过去使用了一些不合理的开发实践，导致过去几年在从 SQL Server 2000 到 2005、2008 一直到 2012 的升级过程中出现了兼容性问题。对此应用程序所做的任何更改都成本高昂，因为开发工作一直由第三方开发团队负责。应用程序还出于报告和分析原因执行许多跨数据库查询。
应用程序的计划中断将对业务产生中等程度的影响，但通过采取一些前瞻性计划这些影响是可以接受的。由于缺少 可用磁盘空间或备份代理进程挂起而经常发生故障，因此客户不相信他们当前的备份和恢复解决方案是可靠的。客 户希望解决这些操作任务（如执行备份、修补和版本升级）的难题。
客户还听说，基于云的服务具有多租户特性，这意味着他们需要记住每个用户的另一组用户凭据，这可能会给用 户带来额外的开销。
解决方案：
Azure SQL 数据库单一数据库的首选平台还不支持传统本地 SQL Server 可能提供的所有功能和兼容性级别，其中一个功能缺少执行跨数据库查询的能力，而这种功能则是客户指明需要的。Azure SQL 数据库托管实例可以用来实现与本地 SQL Server 的高度兼容性，而不必重新设计应用程序以适应成本高昂且耗时的解决方案，同时仍可享受云带来的诸多好处。
要进行迁移，可以从本地 SQL Server 数据库中获取本机 SQL 备份，上传到 Azure Blob 存储，然后直接还原到
Azure SQL 数据库托管实例中。
进入 Azure SQL 数据库托管实例后，内置的自动备份和时间点还原功能就可以解决确保可靠数据保护的难题，但客户可配置的备份保留和恢复功能意味着他们仍然可以在需要时进行控制。
Azure SQL 数据库托管实例对加密的本机支持进一步增强了数据保护，这意味着使用客户提供的加密密钥，加密数据（传输过程中和静态数据）可以保护宝贵的知识产权数据。
可以在服务器维护和管理方面节省成本，无需修补和版本升级开销，以便管理员能够完成更高优先级的任务。通 过使用 SQL Server 的 Azure 混合权益，将自己的 SQL 许可证与有效软件保障结合使用，可以节省更多成本。
最后，通过使用免费的 Microsoft AADConnect 目录同步工具将其本地活动目录同步到 Azure Active Directory，可以提供单一登录体验，以便使用 Windows 用户凭据访问 Azure SQL 数据库托管实例数据库，而不会显示任何其他登录提示。托管实例还遵循适用于 Azure SQL Server 的合规性标准，因此客户无需承担大量管理开销即可达到新标准的要求。
5.8 示例摘要 – 目标平台选择
下表总结了上述示例中每个目标平台适合的场景。
Azure SQL 平台的常见场景：
| 目标平台 | 需要观察的指标 | 优势 |
| Azure SQL 数据库单一数据库Azure SQL 数据库弹性池Azure SQL 数据库托管实例 | 当前容量或管理问题需要高可用性 | 为你提供和管理计算层与存储层可按需提供近乎无限的容量
高级层可满足更高的性能和吞吐量要求高可用性作为标准 可用于区域高可用性和灾难恢复保护的选项 Azure 为你管理备份、升级和修补 Azure 针对性能和安全事件提供自动分析和建议。支持数据加密 支持使用 Azure AAD 单点登录 |
特定于每个平台：
| 目标平台 | 需要观察的指标 | 独特的优势 |
| Azure SQL 数据库单一数据库 | 无论数据库数量多少，都具有稳定的高使用率 | 单一数据库成本最低 |
| Azure SQL 数据库弹性池 | 多个数据库或多租户部署 | 在多个数据库之间共享聚合资源，因此具有成本 效益 |
| Azure SQL 数据库托管实例 | 不拥有应用程序代码，或者更改成本高昂
需要较高的兼容性 使用 Azure SQL 数据库尚不支持的 SQL Server 功能 |
完全托管的服务，同时保持与 SQL Server 的高度兼容
支持 Azure SQL 数据库不提供的 SQL 功能，如跨数据库查询 |
| Azure 基础架构即服务上的 SQL Server | 使用 Azure SQL 数据库尚不支持的 SQL Server 功能
本地安装在 SQL Server 上的第三方工具 |
与本地 SQL Server 完全兼容
第三方应用程序和插件很有可能按原样工作 完全访问基础操作系统以安装第三方工具和服务 |
5.9 示例摘要 – 迁移工具选择
下表总结了上述示例中每个迁移工具适合的场景。
| 迁移工具 | 需要观察的指标 | 独特的优势 |
| 事务复制 | 维护时段较短或不存在的关键数据库
大型数据库 (>1 TB) |
切换所需的停机时间最短，因为在数据同步过程中源数据库保持联机状态并可响应请求 |
| Azure 数据库迁移服务
(DMS) |
需要迁移许多数据库，允许的维护窗口适中
大型数据库 (>1 TB) |
支持同时迁移多个数据库 |
| BACPAC 导出/导入 | 要迁移的临时数据库数量很少中小型数据库 (<1 TB)
可用性要求低，维护时段宽松 |
快速、简单，没有真正的设置要求 |
| Azure Site Recovery | 要按原样将现有 SQL Server
迁移到 Azure |
将服务器的精准副本直接迁移到 Azure IaaS
虚拟机 在服务器数据同步过程中源服务器保持联机状态并可响应请求 |
6 转换和优化
现在，我们对迁移的内容、迁移的目标平台以及实施迁移的方法有了切实的了解，下一步是对源环境进行转换和优化并进行必要的更改，以便为即将到来的迁移阶段做好准备。完成转换和优化阶段后，我们将获得以下成果：
与目标兼容的架构
数据库架构将处于受目标平台支持的状态，并为迁移做好准备数据迁移的准备工作已完成
将纠正所有错误，数据已为迁移做好准备。
在本节的剩余部分，我们将研究如何转换源数据或修复任何问题所用的机制，并研究为充分利用 Azure SQL 平台可进行的优化。
6.1 转换
在理想的情况下，将数据从本地迁移到云就可以工常工作了，但很有可能需要更改某些内容以确保迁移成功、正常 运行。需要重点进行必要更改的领域包括：
更新和检查数据库架构
早期评估任务得出的结果应强调了需要对数据库架构进行的所有更改，这些更改应在此阶段实施。实施环境要求的所有版本升级
SQL Server 源通常必须至少是 SQL Server 2005 或更高版本才能使用 Microsoft 提供的迁移工具，如 Azure 数据库
迁移服务 (Azure DMS) 和数据迁移助理 (DMA)。如果源 SQL Server 不能满足此最低要求，则需要先考虑升级，然后才能使用这些迁移工具来简化其余的迁移任务。
迁移评估工具针对任何错误或警告提供的修复
由于某些功能在 Azure SQL 数据库中无法使用，因此必须补充或删除某些功能，包括跨数据库引用、服务代理、日志传送或链接服务器等功能的使用。可能需要更新或重新编写弃用的 SQL 语法，以满足 Azure SQL 数据库上所需的 SQL 版本的要求。
将现有的集成数据库服务迁移到 Azure
正如我们之前发现的，Azure 还没有一个类似于 SSIS 或 SSRS 的云服务。这些工作负载将需要实施新的 Azure 服务，这些服务可以部分支持所需的工作负载，将工作负载保留在本地，或在虚拟机中实施这些工作负载。
6.2 优化
优化可能包括以下步骤：
评估目标平台上可提供哪些新功能
以前过于复杂或成本高昂而无法在本地实现的新功能现在只需在 Azure 门户中点击几下即可实现。应考虑这些功能是否会给每个工作负载带来好处，然后再酌情实施。
将工作负载重新构建为更具成本效益或更高性能的集合
这可能包括将构成工作负载的数据库分配到 Azure SQL 数据库上的各种服务级别和性能层。由于硬件和许可成本，这些资源以前集中在同一本地 SQL Server 上，但利用 Azure SQL 数
据库的完全托管服务产品，现在为单一数据库分配额外资源（如果有好处的话）就非常经济高效了。
确保工作负载大小合适
考虑将工作负载重新调整到更合适的服务级别和性能层。以前，它们在驻留的物理服务器上共享一个组合的计算和 存储资源池，资源池没有得到充分利用，无法实现未来增长。现在，利用 Azure SQL 数据库的完全托管服务产品， 就可以使用 Azure SQL 数据库 DTU 计算器等工具或将本地核心要求与 vCore 进行比较，从而获得更准确的数据库大小，并根据需要增加分配的资源。
下表包含在导入过程中获得最佳性能的建议：
根据预算，选择能最大限度地提高传输性能的迁移时间所对应的最高服务级别和性能层。
在迁移过程中，数据库将执行大量的写入操作，所选性能层的大小不够可能会无意中限制吞吐量，从而导致迁移时 间大幅延长。相反，在迁移过程中选择比临时需要的性能层更高的性能层，然后在迁移后缩小规模可最大限度地降 低成本。
最大限度地缩小 BACPAC 文件与目标数据中心之间的距离
通过最大限度地缩小 BACPAC 文件与目标数据中心之间的物理距离，将减少网络延迟。进而会增加总体迁移吞吐量，因为可以在同一时段完成对目标数据库的更多读取和写入操作。
在迁移过程中禁用自动统计
在 Azure SQL 数据库中，在默认情况下统计信息对象会开启“自动更新”。当对表进行足量的更改后，将自动更新统计信息。在导入过程中，当所有表中的几乎所有行都发生更改时，会反复满足此触发条件，从而导致不断尝试更 新统计信息。此更新占用宝贵的 IO 资源来完成，这将减小可用于导入过程的总体 IO 资源池，并延长迁移时间。
分区表和索引
分区表和索引有助于在迁移过程中传输和访问数据。可以将数据分区为一个或多个类似的子集，从而加快数据传 输速度。对大型数据集进行分区还可以减少锁争用，因为可以在分区级别激活锁升级，而不会损害整个数据集。 数据迁移到云后，可实现更快的查询性能并降低应用程序的开销成本。总体分区表和索引有助于提高数据的性 能，从而降低迁移成本和迁移后的未来风险。
删除索引视图并在完成后重新创建视图
使用索引视图时，每次修改基础表上的数据时，Azure SQL 都会维护这些表上的索引项，同时还会维护视图上的索引项。这可能会影响写入性能，并再次减少可用于导入过程的 IO 资源，从而延长迁移时间。此外，它们还可能导致锁争用等其他问题。
将很少查询的历史数据移至另一个数据库，并将此历史数据迁移到单独的 Azure SQL 数据库。然后，你可以使用
弹性查询来查询此历史数据。
通过清除数据库中的历史数据，可以大幅缩减数据库的大小，从而大幅减少需要迁移的数据量。这有助于实现严格的维护时段目标，因为核心数据可以在更短的时间内迁移到 Azure SQL，从而使应用程序能够更快地恢复联机。可以在不严苛的时间段内迁移很少查询的历史数据，因为它的优先级要低得多。
7 迁移、验证和修复
我们进入最后一个阶段：数据迁移。以前的规划、评估和转换阶段确保已经为迁移做好所有准备，并可在迁移到
Azure 后正常运行。因此，剩下来要做的就是准备所需的迁移工具、执行迁移，并运行迁移后的功能和性能验证。
7.1 迁移概述
考虑可供应用程序和数据库进行迁移的维护时段
如果它们是关键工作负载，则可能只能在非常特定的时间点脱机几分钟。或者，工作负载可能用于编写历史报告，并且可以在一周中的大部分时间轻松地脱机，而不会影响最终用户。这些差异有助于确定需要使用哪种迁移 技术。
首先从低优先级数据库开始
这有助于确保迁移过程正常实施，并有助于衡量当迁移到更关键的工作负载时，迁移可能需要多长时间。修复数据迁移助手中归纳的兼容性问题
这些问题应在转换和优化阶段得到解决，但还要验证 DMA 是否没有显示任何其余问题。
使用所选工具执行测试迁移
在迁移数据库之前，请执行数据库的测试迁移，以确认迁移所需的时间量以及迁移过程中遇到的任何问题。
测试数据库有无问题
测试迁移完成后，执行验证步骤以确认数据已完全迁移，并检查在
Azure SQL 平台上遇到的任何问题。反复修复问题，直至修复数据库
对于在测试过程中发现的每个问题，找到修复方法，然后重新测试。继续重复此测试-修复周期，直到发现并修复
所有问题。
根据需要为云重新编写第三方应用程序
Azure 应用程序体系结构指南对旧的本地体系结构模型与云体系结构模型进行了比较，云体系结构模型可以通过更简洁的编码方法帮助优化性能和减少开销。该指南可为第三方应用程序提供帮助。应逐个案例对每个应用程序进 行分析，确定需要进行“直接迁移”还是重新编写。
测试第三方应用程序：认在迁移每个应用程序时，任何第三方应用程序在云中仍可按预期运行，包括任何依赖项。
将旧数据库和应用程序脱机
在开始迁移过程之前，请将源数据库和应用程序脱机以避免混淆，并在需要引用它们或执行回滚时保留
原始数据。
创建新的灾难恢复和维护计划
花些时间更新灾难恢复计划，因为数据现在已经移动了位置，并且访问方式也发生了改变。考虑通过利用 Azure 的异地复制功能来改进灾难恢复计划，为以前在本地时保护方法过于复杂或成本太高的数据提供保护。由于 Azure 现在在后台自动为你执行许多维护任务，而无需手动执行这些任务，因此还需要对维护计划进行检查。
使用工具集，你可以更深入地了解所处环境，并在迁移过程中为你提供极大的帮助
其中包含许多 Microsoft 和第三方工具，可以帮助监视本地和云中的 SQL 环境，包括：
- Azure 数据库迁移服务 (DMS) 可帮助跟踪将数据大规模迁移到 Azure 的进度。
- MicrosoftOperations Management Suite 可以帮助监视和直观显示本地和云中的 SQL 工作负载，包括 SQL Server
版本数、当前 CPU 性能、作业成功次数和失败次数以及任何记录的事件。
- AzureSQL 数据库智能见解是一种工具，使用内置智能持续监视数据库使用情况并检测导致性能低下的破坏性事件，并提供有助于改进功能的建议。
基于中断评估迁移工具，以帮助降低数据库停机的风险
在接下来的章节中，我们将介绍哪些迁移工具需要停机来完成，以及哪些迁移工具可以在工作负载保持联机且可 用的状态下在后台工作。
将了解工作负载要求作为起点
要求可能包括存储大小、存储吞吐量和高可用性。创建计划以降低与停机和兼容性问题相关的风险
本白皮书中讨论的许多要点将有助于降低迁移过程中出错的风险。在执行最终迁移之前执行测试迁移，了解任何
错误，然后再迁移更关键的工作负载，并制定回滚计划以应对紧急情况。
了解 SQL Server 版本之间的功能对等性，并使用评估工具来减轻选择错误目标选项所带来的影响数据迁移助手 (DMA) 等工具将帮助确定源工作负载是否在使用 Azure 中某些平台上不支持的功能。首先选择非关键工作负载进行迁移
这有助于确保迁移过程正常进行，并有助于衡量当迁移到关键工作负载时，迁移可能需要多长时间。
持续完善迁移过程
在第一次迁移过程中，将发现微小的更改，需要创建文档或过程，或者需要删除不必要的迁移步骤。应将这些发 现反馈到迁移过程中，你按照此过程优化其余更高优先级的迁移。
7.2 迁移工具选择
将根据工作负载的重要性以及应用程序在切换过程中可以脱机的时间长短来选择用于将数据迁移到 Azure 的迁移工具。
下面是一个简单的工作流，可以帮助你选择工具：
对于只接受零数据库停机的关键工作负载，应使用 SQL Server 事务复制来同步本地和 Azure 之间的所有数据，同时使源数据库保持联机并可为请求提供服务。对于可接受短暂停机的常规工作负载，可以使用 Azure 数据迁移服务来管理所有这些数据库的迁移过程。对于可在计划时间脱机的所有其他工作负载，导出包含源数据库的数据和架构的 BACPAC 文件并将其导入到 Azure 是一种不错的选择。
不同的工具可用于不同需求，没有一种工具必须用于所有数据库迁移。我们将在接下来的章节中进一步研究其中 每一种工具。
使用 SQL Server 事务复制进行迁移
事务复制将 SQL Server 数据库逐步迁移到云，同时使生产服务器保持联机并创建事务。当在源上创建新事务时， 这些事务也会迁移到目标数据库，从而使源和目标保持同步。此技术可实现较高的可用性，因为只有在切换应用程序以指向新迁移的 Azure SQL 数据库时才需要停机。它还特别适合需要逐步或部分迁移而不是批量迁移所有数据的混合场景。
可以使用 SQL Server Management Studio (SSMS) 或 T-SQL 语句来配置事务复制，并将 Azure SQL 数据库设置为源
SQL Server 发布服务器的推送订阅服务器。所需的分发数据库和复制代理不能置于正在迁移的 SQL 数据库上。支持快照和单向事务复制，但不支持对等事务复制和合并复制。
若要使用此方法，源数据库必须满足事务复制的要求，并与 Azure SQL 数据库兼容。支持在事务复制配置中使用
SQL Server 2012 以后所有版本的 SQL Server，但可能需要安装特定的服务包和累积更新，然后才能使用。
事务复制支持的 SQL Server 源包括：
- SQL Server 2016RTM
- SQL Server 2014 SP1CU3
- SQL Server 2014 RTMCU10
- SQL Server 2012 SP2CU8
使用事务复制时，对数据或架构的所有更改都显示在 Azure SQL 数据库中。完成同步并且准备好数据进行切换后， 请更改应用程序的连接字符串以指向 Azure SQL 数据库并将应用程序发布到生产环境中。若要使用此解决方案，请将 Azure SQL 数据库配置为要迁移的 SQL Server 实例的订阅服务器。事务复制分发服务器将同步需要同步的数据库（发布服务器）中的数据，同时继续产生新的事务。
当事务复制完成源数据库上其余的更改，并且所有应用程序都指向新的 Azure SQL 数据库后，则可以卸载事务复制。使用 Azure 数据迁移服务 (DMS) 进行迁移
Azure 数据迁移服务是一种完全托管的迁移服务，能够以最少的停机时间实现从多个数据库源到 Azure 数据平台的无
缝迁移。为此，Azure DMS 将多个 Microsoft 迁移引擎（如数据迁移助手 (DMA)、数据库实验助手 (DEA) 和 SQL Server
迁移助手 (SSMA)）结合在一起，可满足各种场景的需求。
通过 Azure 门户 (https://portal.azure.com) 访问 Azure DMS，在该门户中，可以根据不同的区域创建 Azure DMS 实例，并提供各种 vCore 选项。通过为服务分配更多的 vCore，你可以提供更快的迁移以满足预期时间线，但要以成本增加为代价。
Azure DMS 支持迁移到 Azure SQL 数据库的所有服务选项（单个、弹性和托管实例）以及 Azure IaaS 虚拟机上的
SQL Server。
在这里可以创建项目，从而执行源评估、架构、数据转换和验证活动，以帮助准备迁移源。还可以轻松地创建迁 移任务，例如概念证明迁移和自动化脚本。
在将数据从本地 SQL Server 实例迁移到 Azure SQL 数据库之前，需要对 SQL Server 数据库进行评估，了解是否存在阻碍因素。数据库迁移助手用于执行此任务，如前面的“评估”部分所示。
完成评估并发现所选数据库是迁移到 Azure SQL 数据库的理想选择后，使用数据迁移助手将数据库架构迁移到
Azure SQL 数据库。
DMA 通过生成 SQL 脚本来实现此功能，然后在 Azure SQL 数据库上重播该脚本，以建立数据库架构并准备用于插入数据的目标数据库。
然后使用 Azure DMS 服务将数据迁移到 Azure 数据服务。
使用数据层应用程序导出/导入 (BACPAC) 进行迁移
SQL Server Management Studio 可以导出用于封装数据库架构以及存储在数据库应用程序中的数据的 BACPAC 文件。此工具很有用，因为可以轻松地将 BACPAC 文件导入到 Azure SQL 数据库中，以提供一种在本地和 Azure 之间迁移数据的简单方法。
为确保导出的 BACPAC 以完整且一致的状态包含所有数据，使用源数据库的工作负载需要在导出过程中脱机，以便在导出时不会处理事务。这意味着导出 BACPAC 文件需要实施计划中断，而这可能需要大量的时间。可以将最多 200 GB 的数据导出到 Blob 存储，因此使用 BACPAC 文件进行迁移只适用于较小的数据库。此限制可能存在争议，因为将较大的数据库导出到 BACPAC 文件、将 BACPAC 文件复制到 Azure Blob 存储，然后将 BACPAC 文件导入到 Azure SQL 数据库可能需要很长时间，而其他迁移技术更适合最大限度地减少停机时间。
将 BACPAC 文件导入到 Azure SQL 数据库
- 登录到 Azure平台管理门户，网址为：https://portal.azure.com
- 单击“新建”>“数据服务”>“SQL 数据库”>“导入”。此操作将打开“导入数据库”对话框。
- 导航到要导入的 .bacpac文件：单击“存储帐户”>“容器”>“BACPAC”，然后单击“打开”。
- 指定新 SQL数据库的名称。数据库名称在服务器上必须唯一，因此该名称不能与另一个 SQL Server 相同，并且该名称必须符合标识符的 SQL Server 规则。有关更多信息，请参阅“标识符”。
- 指定“订阅”、“版本”、“最大大小”和主机“服务器”详细信息。如需继续，请单击对话框底部的箭头。
- 指定主机服务器的登录详细信息。
- 要开始导入操作，请单击对话框底部的复选标记。门户将在页面底部的功能区中显示状态信息。
- 要查看新数据库，请单击导航窗格中的“SQL 数据库”并刷新页面。
