我们正在从内部部署服务器（Win 2008 R2）迁移到Azure PaaS。
为了移动数据库，我们使用了Microsoft Data Migration Assistant (DMA)工具，该工具运行良好，我们可以通过SQL Server Management Studio连接到迁移后的Azure数据库。
考虑到：
- 对迁移的Azure DB（表、存储过程、索引）进行了大量更改，以便与Azure中的应用程序配合使用
- 通过DMA将多个内部数据库合并到Azure中的一个数据库中，以保存成本
- 在迁移过程中，内部数据库不断被插入/更新操作（多个表）修改
**问题：**考虑到上述情况，迁移数据（全部迁移与缺失/更新）的最佳、最快方法是什么？
3条答案
按热度按时间6bc51xsx1#
我建议您首先只将内部部署数据库的架构迁移到Azure SQL数据库，然后让Azure SQL Data Sync将数据迁移到Azure，并在Azure SQL数据库上保持更新。
我建议从Azure SQL数据库端的空架构开始，因为当SQL数据同步在内部部署和Azure上找到数据时，它会开始比较两个数据库，这会消耗大量资源。
在初始同步时，SQL数据同步可能会消耗内部部署数据库服务器上的大量资源，即使Azure端的架构为空，为此，您可以使用SQL Server Resource Governor限制内部部署SQL Server中数据同步会话使用的CPU，这样可以避免可能影响数据库用户的巨大性能影响。
准备就绪后，你可以将用户切换（如果SQL数据同步处于双向模式，则可以逐步切换或不切换）到Azure。迁移用户后，你可以从SQL数据同步配置中删除成员数据库（内部部署数据库）并停止SQL数据同步操作。
8zzbczxx2#
我不同意这里所有的答案。
如果你运行的是Win2008R2，很有可能你使用的是旧版SQL Server（2008？2012？），它们已经过时，不适合Azure SQL数据库。而且应用程序可能也很旧，一般来说不适合云。我建议你好好测试一下。
这是我的待办事项清单：
1.在内部将SQL Server升级到SQL Server 2016，并测试您的所有查询是否仍在正常运行
1.测试您的SQL Server是否准备好通过Microsoft数据迁移助手（DMA）工具或新的Azure SQL Migration extension for Azure Data Studio（本月推出）迁移到Azure SQL数据库。
1.甚至不要认为合并数据库会降低你的总成本。决定是多租户还是单租户不是因为数据库的价格。
1.根据迁移的大小规划停机时间。在修改数据库时不要迁移。预计停机时间。最好的方法是备份前一天的日志，然后恢复日志。
然后疯狂地测试，这可不容易，因为应用程序太旧了。
祝你好运
kgsdhlau3#
VisualStudio还提供了一个很好的工具，用于比较不同服务器上的两个数据库之间的架构和数据。
然后，它可以使用任何更改更新目标数据库，之后您可以切换到使用Azure DB。
此方法需要停机大约5-30分钟，具体取决于数据量，但这可能是可以接受的，具体取决于您的要求。