Почему обновление 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 использует старый механизм извлечения, который выполняет запрос для каждого столбца и небольшого объекта. Этот способ хорошо работает на локальном сервере и соответствует первоначальной цели разработки SQL Server 2008. Однако при управлении базой данных SqlAzure запрос необходимо передавать через Интернет, задержка в сети делает старое извлечение неэффективным, особенно когда сеть не работает.

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

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