通过

运行数据迁移助手的最佳做法

  • 项目

重要

数据迁移助手 (DMA) 已弃用。 有关从 SQL Server 迁移到 Azure SQL 的方式选项信息，请参阅从 SQL Server 迁移到 Azure SQL 的方式选项。

本文提供了有关安装、评估和迁移的一些最佳做法信息。

安装

请勿直接在 SQL Server 主机上安装并运行数据迁移助手。

评估

  • 请在非高峰时间对生产数据库运行评估。
  • 请分别执行“兼容性问题”和“新功能建议”评估，从而缩短评估时间。

迁移

  • 请在非高峰时间迁移服务器。

  • 迁移数据库时，请提供源服务器和目标服务器可以访问的单个共享位置，并尽可能避免复制操作。 复制操作可能会根据备份文件的大小产生延迟。 复制操作还会提高由于额外步骤导致迁移失败的几率。 提供单个位置时，数据迁移助手会绕过复制操作。

    此外，为了避免迁移失败，请务必提供对共享文件夹的适当权限。 该工具中指定了正确的权限。 如果 SQL Server 实例使用网络服务凭据运行，请向 SQL Server 实例的计算机帐户授予有关共享文件夹的正确权限。

  • 连接到源服务器和目标服务器时，请启用加密连接。 使用 TLS 加密能更好地保护在数据迁移助手和 SQL Server 实例之间跨网络传输的数据，这在迁移 SQL 登录信息时尤为有用。 如果未使用 TLS 加密并且网络遭到攻击者的攻击，则迁移的 SQL 登录信息可能会被攻击者实时截获和/或篡改。

    但是，如果所有访问都具有某项安全 Intranet 配置，则可能不需要使用加密。 启用加密会降低性能，因为加密和解密数据包需要额外开销。 有关详细信息，请参阅加密与 SQL Server 的连接。

  • 在迁移数据之前，请检查源数据库和目标数据库上是否存在不受信任的约束。 迁移后，再次分析目标数据库，以查看在数据移动过程中是否有任何约束变得不受信任。 根据需要修复不受信任的约束。 将约束保留在不受信任状态可能会导致执行计划不佳，并且可能会影响性能。