我有一个不太大的数据库，我正在尝试将其迁移到 SQL Azure，大约 1.6 GB。我在 blob 存储中有 BACPAC 文件，开始导入，然后...什么也没有。就状态而言，它会达到 5%，但除此之外不会很快。 10 小时后，数据库大小似乎为 380 MB，监控显示平均每小时大约有 53 个成功连接，没有失败。看来还在继续。
我将相同的 BACPAC 带到家里的本地计算机，并且我可以在不到三分钟的时间内导入相同的数据库，因此我假设文件的完整性都很好。
这里可能出现什么问题？在这种情况持续下去时，我不能让我要迁移的应用程序离线数天。一定有什么根本不同的东西让它窒息。
呃，我讨厌回答自己的问题，但我知道问题是什么。这似乎与他们新的基本-标准-高级等级（2014 年 4 月宣布）有关。数据库导入到旧的网络业务级别没有问题。由于新层是围绕“可预测性能”的节流而构建的，因此它们使导入的大批量交易变得异常缓慢。
我自己还没有尝试过（今天到目前为止已经花了 5 个小时等待 ~11GB 测试数据库导入到 S3 大小的 Azure SQL 数据库）...
但是微软自己提到这是因为他们没有分配足够的仓鼠来运行轮子，并建议直接从命令行使用 SQLPackage.exe 作为导入缓慢的解决方法。 （请参阅此处：Azure SQL 数据库和托管实例导入/导出服务需要很长时间才能导入或导出数据库）
有兴趣看看会发生什么，我等不及要在几天内迁移 Prod DB，所以要尝试一下这个工具！
更新：
在等待 4 个多小时等待我的 BACPAC 文件导入后，它崩溃了。
有趣的是，来自崩溃导入的数据库出现在 Azure 门户中，我可以看到 DTU 使用率（S3 数据库）几乎在整个 4 小时内一直处于 100%...
所以我想知道如果我在导入过程中将数据库性能一路调高会发生什么，因此我从崩溃的导入中删除了数据库并再次启动它，这次将性能设置为 P15（4000DTU 与 S2 中的 40DTU） ).
你猜怎么着...
导入只花了 3 分钟多一点
将数据库恢复为 S3（客户已指定并乐意为此付费）。
那是我生命中的 4 个小时，我永远不会再回来了......
我刚刚也遇到过类似的情况。 我在计划的维护活动期间定期删除然后重新创建 Azure SQL Server 数据库。 这次，将 2.5 GB bacpac 文件导入 Azure SQL Server 时，导入过程在 4 小时后停留在 1%。 历史上需要 15 到 30 分钟，随着文件大小的增加，时间也会增加。
我将定价层从 S2 标准 50 DTU 250 GB 更改为 S12 标准 3000 DTU 250 GB，看看这是否会导致导入崩溃或加快导入速度。 快进 30 分钟，仍然停留在 1%。
我意识到我的计算机上仍然运行着 MSSMS，该计算机与要替换的 Azure SQL Server DB 有持久连接（服务器对象 > 链接服务器 > AZUREDB > 目录 > MyDatabaseName）。
退出 MSSMS 后几秒钟内，导入过程就完成了。 退出 MSSMS 是启动 bacpac 导入之前的程序步骤之一，但在凌晨 4:30 我无意中跳过了它。
TL;DR 对我来说，解决方案是在 SSMS 中完成整个操作。
2024 年末，问题仍然很明显。 遗憾的是，之前的答案并没有为我解决问题，而且数据库通知中的进度条从未超过 1%。 我还注意到，在数据库监视器中，计算机统计数据从未超过 1%，因此我不相信成功创建数据库后导入过程实际上已开始。
门户网站提供的信息不足以让我们对任何潜在问题采取行动，但我们在此过程中为容量支付了大笔费用，这给我们留下了不好的印象。
我使用 SSMS 从本地还原创建 BACPAC 文件，然后连接到 SQL Azure 数据库服务器，然后将
Databases > Import Data-tier application使用 Gen5 80 核配置，一个包含 160 个表、约 200 万行数据的 3.3GB 数据库需要 5 分钟。这里的主要好处（恕我直言）是 SSMS 显示流程每一步的详细进度。
显然，完成后不要忘记缩减数据库！