0

我创建了一个 PowerShell 脚本，以使用我最新的 DACPAC（取自http://msdn.microsoft.com/en-us/library/ee634742.aspx）升级 SQL Azure 实例。

我在运行我的 PowerShell 脚本时所经历的是，它始终需要大约 30 分钟才能执行。该脚本空闲了将近半个小时，等待$dacstore.IncrementalUpgrade($dacName, $dacType, $upgradeProperties)从执行返回，并且在 PowerShell 控制台窗口上没有打印任何内容。仅在半小时结束时，增量更新才开始吐出控制台消息，通知我正在进行升级（基本上，脚本似乎已挂起 30 分钟，直到它最终恢复正常，并且脚本始终如一地执行此操作每次）。

IncrementalUpgrade 完成通常需要这么长时间吗？是否应该有 30 分钟的不活动/等待时间？

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

感谢您对此提供的任何见解，我希望我可以将这个增量升级过程减少到大大少于 30 分钟，这样我的持续集成构建就不会花费这么长时间。

4

1 回答 1

0

根据 Microsoft 支持，这是一个已知问题，将在 SQL Server 2012（代号 Denali）中修复。以下是来自 Microsoft 支持的详细信息：

使用 SSMS 2008 或 PowerShell 更新 SqlAzure 上的 DAC 非常慢，这是一个已知问题。SQLServer 2008 利用旧的提取引擎，对每一列和小对象运行查询。这种方式在本地服务器上运行良好，并且符合 SQLServer 2008 最初的设计目标。但是，在管理SqlAzure数据库时，查询需要通过互联网传输，网络延迟使得旧的提取变得低效，尤其是在网络不好的情况下。

我们的 SQL 产品团队意识到了这个问题并设计了新的提取引擎来修复它。新引擎集成在 SQL Server 2012（代号 Denali）中。不幸的是，某些引擎行为可能会给 SQL Server 2008 带来重大变化。我们尝试了不同的方法，但在 SQL Server 2008 中应用新引擎时，我们无法消除回归障碍。因此，我们没有计划交付到目前为止，作为 SQLServer 2008 上的修补程序的新提取引擎。这将影响当前的本地用户和操作。

可以在此处找到有关我如何使用持续集成 (CI) 流程构建 PowerShell 脚本的更多详细信息。

于 2011-11-17T15:32:24.947 回答