Почему обновление SQL Azure DACPAC (с помощью сценария PowerShell) последовательно занимает 30 минут для завершения

Question

Я создал сценарий PowerShell для обновления экземпляра SQL Azure с помощью моего последнего DACPAC (взято из http://msdn.microsoft.com/en-us/library/ee634742.aspx).

. При запуске сценария PowerShell у меня возникло то, что для его последовательного выполнения требуется примерно 30 минут.сценарий бездействует почти полчаса, ожидая, когда $dacstore.IncrementalUpgrade($dacName, $dacType, $upgradeProperties) вернется к выполнению, и в окне консоли PowerShell ничего не выводится. Только в конце получаса инкрементное обновление начинает выдавать сообщения консоли, сообщающие мне, чтообновление происходит (по сути, кажется, что скрипт завис в течение 30 минут, пока он, наконец, не возвращается живым, и скрипт делает это последовательно каждый раз).

Обычно это занимает много времени для завершения IncrementalUpgrade иПредполагается, что период бездействия / ожидания составляет 30 минут?

Обратите внимание, что я запускаю сценарий PowerShell с моего локального компьютера, который является внешним по отношению к сети Azure.

Спасибо за пониманиеможет дать еили я надеюсь, что смогу сократить этот процесс постепенного обновления до менее чем 30 минут, чтобы моя сборка с непрерывной интеграцией не заняла так много времени.

Answer 1

По данным службы поддержки Microsoft, это известная проблема, которая будет исправлена ​​в SQL Server 2012 (кодовое имя Denali).Вот подробности из службы поддержки Microsoft:

Это известная проблема, связанная с тем, что использование SSMS 2008 или PowerShell для обновления DAC в SqlAzure идет очень медленно.SQLServer 2008 использует старый механизм извлечения, который выполняет запрос для каждого столбца и небольшого объекта.Этот способ хорошо работает на локальном сервере и соответствует первоначальной цели разработки SQLServer 2008.Однако при управлении базой данных SqlAzure запрос необходимо передавать через Интернет, задержка в сети делает старое извлечение неэффективным, особенно когда сеть плохая.

Наша команда разработчиков SQL знает эту проблему и разработала новое извлечениедвигатель, чтобы это исправить.Новый движок интегрирован в SQL Server 2012 (кодовое имя Denali).К сожалению, некоторые действия движка могут привести к критическим изменениям в SQL Server 2008. Мы пытаемся использовать другой подход, но не можем устранить барьер регрессии при применении нового движка в SQL Server 2008. Поэтому у нас нет плана по доставкеновый движок извлечения как исправление на SQLServer 2008 до сих пор.Это повлияет на текущих локальных пользователей и работу.

Дополнительные сведения о том, как я спроектировал сценарий PowerShell с процессом непрерывной интеграции (CI), можно найти здесь .