SqlPackage.exe занимает много времени

Итак, мы работаем над добавлением SQL DACPACs в рамках нашей постоянной интеграции. Мы делаем это с помощью скрипта powershell, запускающего «sqlpackage.exe» с каждым файлом DacPac. у нас около 12 БД, так что это около 12 DacPac.SqlPackage.exe занимает много времени

Каждый раз, когда мы запускаем «sqlpackage.exe» для публикации или сценария DacPac, мы замечаем, что для завершения инициализации потребуется 0,5-1 + мин. Большая часть этого времени выполняется во время потока инициализации, когда начинается «sqlpackage.exe».

Я пытаюсь найти способ уменьшить это, если возможно, так как у нас есть 12 БД, мы говорим о не менее 12-ти минутах для развертывания БД, что для нас слишком много.

Вы знаете какой-либо способ уменьшить это?

источник

2015-08-06 JarJarrr

Рассматривали ли вы одновременное выполнение обновлений (параллельно)? –

Также я использую подобный подход, а также генерация сценария из dacpac занимает много времени. У меня есть сценарий powershell для параллельной работы сценариев в группах по четыре. Обратите внимание, что он использует до 100% нашего процессора при одновременном создании четырех сценариев. – scar80

И по этим линиям вы считаете, что не нажимаете изменения, если нет никаких реальных изменений? Это немного больше, чтобы отслеживать фронт, но это также может сократить время на выпуск, если вы не обновляете каждую базу данных. –

Время, которое, как мне кажется, используется для получения текущей схемы из базы данных, сравнения ее с тем, что находится в dacpac, и придумать необходимые сценарии изменения. Невозможно устранить это, используя dacpac.

Однако вы могли бы сделать это заблаговременно, создав сценарии обновления SqlPackage, а затем при развертывании просто запустите скрипты. Это может сократить время простоя вплоть до времени, необходимого для запуска сценария, и, как было предложено, при параллельном запуске время простоя может быть значительно сокращено.

Если все ваши БД гарантировали, чтобы быть в одном и том же состоянии (схеме), вы могли бы просто создать один сценарий обновления с первой БД и запустить его на всех БД.

источник

2015-08-09 21:14:26 Mark

Это интересная идея для создания сценариев до развертывания. Единственная проблема заключается в том, что мы хотим, чтобы это было частью продолжения интеграции и развертывания, поэтому их создание до этого на самом деле невозможно. – JarJarrr

Это может быть слишком поздно, но потенциально полезно для других - мы обнаружили, что открытие всех портов в брандмауэре на сервере SQL позволило решить проблему развертывания на долгое время. Прошел от 4-5 минут до 1 минуты.

источник

2017-11-17 04:48:46 benpage

Можете ли вы сказать, какие порты вы открыли, когда вы говорите «мы обнаружили, что открываем все порты в брандмауэре на SQL-сервере» – Gwasshoppa

, как и в, мы отключили брандмауэр Windows-сервера, так что теперь все порты открыты. для ясности это был брандмауэр на сервере sql, который мы отключили, а не брандмауэр на веб-сервере (который делает выпуск). – benpage

SqlPackage.exe занимает много времени

ответ

Смежные вопросы