为什么SQL Azure DACPAC升级（通过PowerShell脚本）始终需要30分钟才能完成

我创建了一个PowerShell脚本，用从中获取的最新DACPAC升级SQL Azure实例

我在运行PowerShell脚本时的经验是，始终需要大约30分钟才能执行。脚本在等待$dacstore.IncrementalUpgrade$dacName、$dacType、$UPGRADEPPROPERTIES以从执行返回时闲置了将近半个小时，PowerShell控制台窗口上没有打印任何内容。只有在半小时结束时，增量更新才开始抛出控制台消息，通知我升级正在进行。实际上，脚本似乎已挂起30分钟，直到它最终恢复活动，并且脚本每次都一致地执行此操作

增量升级是否通常需要这么长时间才能完成，是否需要30分钟的不活动/等待时间

请注意，我正在从Azure网络外部的本地计算机运行PowerShell脚本

---

感谢您对此提供的任何见解，我希望我可以将此增量升级过程缩短到30分钟以下，以便我的持续集成构建不会花费太长时间。

根据Microsoft支持，这是一个已知的问题，将在代号为Denali的SQL Server 2012中修复。以下是Microsoft支持部门提供的详细信息：

使用SSMS 2008或PowerShell更新上的DAC是一个已知问题 SqlAzure非常慢。SQLServer2008利用旧的提取引擎 它对每个列和小对象运行查询。这种方法很有效 在本地服务器上，并满足SQLServer2008原始设计目标。 但是，在管理SqlAzure数据库时，查询需要 通过互联网传输，网络延迟使旧的提取 变得效率低下，尤其是当网络不好时

我们的SQL产品团队意识到了这个问题，并设计了新的抽取 引擎来修理它。新引擎集成在SQL Server 2012中 代号德纳利。不幸的是，某些引擎行为可能会 将中断更改带到SQL Server 2008。我们尝试不同的方法，但是 当我们把新发动机应用到汽车上时，我们无法消除倒退的障碍 SQL server 2008。因此，我们没有交付新产品的计划 提取引擎作为SQLServer2008上的修补程序。这将影响 当前本地用户和操作

---

关于我如何使用持续集成CI流程构建PowerShell脚本的更多详细信息，请参阅。

有趣的是，该脚本在本地计算机上运行仍然需要30分钟，但是，当我在Rackspace中从机箱中运行脚本时，只需5分钟。。。我知道Rackspace box具有更快的互联网连接，但我不认为这是我本地box 30分钟无响应的原因。作为跟进，我在MSDN social上发布了一个类似的问题，他们正在调查：