2013-05-03 5 views
1

Редактировать: Обновлено, чтобы заявить, что он не висит, просто требуется ВОЗРАСТ!Dacpac Обновление базы данных Времена немного глупые

Я пытаюсь обновить существующую базу данных SQL-сервера, используя dacpac.

Я могу создать новую базу данных SQL-сервера с приведенным ниже примером за 30 секунд. Проблема, с которой я сталкиваюсь, заключается в том, что использование одного и того же dacpac, повторение процедуры (так что обновление существующей базы данных, а не создание заново) занимает 20 минут.

Возможно, если разница во времени, что ожидать? Используя комплексный подход Redgate SqlCompare, я нахожу время незаменимым.

Третий параметр метода развертывания: UpgradeExisting, который я устанавливаю в true - это все, что мне нужно сделать, или я что-то не хватает?

void Deploy(string TargetConnectionString, string TargetDatabaseName, string pathToSourceDACPAC) 
{ 

    DacServices dacServices = new DacServices(TargetConnectionString); 

    //Set up message and progress handlers 
    dacServices.Message += new EventHandler<DacMessageEventArgs>(dbServices_Message); 
    dacServices.ProgressChanged += new EventHandler<DacProgressEventArgs>(dbServices_ProgressChanged); 

    //Load the DACPAC 
    DacPackage dacpac = DacPackage.Load(pathToSourceDACPAC); 

    //Set Deployment Options 
    DacDeployOptions dacOptions = new DacDeployOptions(); 
    dacOptions.AllowIncompatiblePlatform = true; 

    //Deploy the dacpac 
    dacServices.Deploy(dacpac, TargetDatabaseName, true, dacOptions); 

} 

//Event handlers... 
void dbServices_Message(object sender, DacMessageEventArgs e) 
{ 
    OutputThis("DAC Message", e.Message.ToString()); 
} 

void dbServices_ProgressChanged(object sender, DacProgressEventArgs e) 
{ 
    OutputThis(e.Status.ToString(), e.Message.ToString()); 
} 

NB программа исчезает в эфир на линии dacServices.Deploy ..

+0

Что произойдет, если вы попытаетесь просто сгенерировать скрипт из самого SSDT? Требуется ли какое-то время для создания/публикации? Является ли это действием сборки или действием публикации, которое занимает много времени? У вас много ссылок на БД? Если да, считаете ли вы, что вы удаляете ненужные объекты? Сколько объектов у вас в целевом БД/проекте? Время будет увеличиваться по мере добавления большего количества объектов, потому что вы их сравниваете. Вы также можете попробовать использовать SQLPackage.exe для изменения изменений и/или генерации сценария, чтобы увидеть, как это работает. Не конечная цель, но может помочь устранить неполадки –

+0

Hi @PeterSchott. Внутри SSDT для создания скрипта требуется около 10 секунд, аналогично, если я создаю скрипт через sqlpackage.exe. Однако, если я использую развертывание через dacpac или создаю скрипт diff через API, используя строку GenerateDeployScript (а не .Deploy в оригинал Q) требуется в области 20 минут. База данных относительно небольшая (200 таблиц, 200 просмотров, 150 функций, 700 sp ..) ... ничего смешного, & db цели в настоящее время пуст. Цифры при запуске на локальном компьютере, так что сеть тоже не проблема. –

+0

Процесс завершения сценария через sqlpackage и развертывание обновлений через sqlcmd составляет около 20, поэтому я, вероятно, в конечном итоге сделаю это ... Я просто хотел бы понять разницу во времени. –

ответ

5

ОК, глупые времена были испытаны при работе через отладчик (VS2012). После компиляции время составляло 25 секунд, когда вы использовали DacSchemaModelStorageType, или 45 секунд, когда вы запускали файл DacSchemaModelStorageType.

Я думаю, это просто означает, что отладка - это боль в whatsit!

+0

У меня также были те же проблемы. Но мое решение содержит 7 баз данных со ссылками друг на друга и около 3500 хранимых процедур среди них. Запуск через отладчик занимает около 2 часов для развертывания! Но если я запустил свое скомпилированное приложение, это займет 10 минут. Спасибо за совет!!! –

+0

@MarkWhitfeld - 2 часа ... yikes! –

+1

@Mark - как я уже упоминал выше, проверьте, получаете ли вы много предупреждений, поскольку все antlr - это первые случайные исключения, которые приостанавливают приложение, передают управление отладчику (vs), который решает, нужно ли прерывать или продолжать - даже если вы у меня есть первые исключения исключений, это то, что вы получаете с отладкой api (визуальная студия не контролирует ее) - это огромные накладные расходы, если есть много исключений. –

0

Надеюсь кто-то будет иметь некоторые dacpac конкретные советы, но так как вы упомянули SQL сравнения был быстрее, вы можете иметь рассмотрите развертывания на основе пакетов как часть инструмента Red развертывания Deployment Manager, который имеет встроенную поддержку баз данных SQL Server.

+0

Привет @ Justin, спасибо за ответ. Мы взглянули на DM и, увы, требования к лицензии не соответствовали нашему документообороту. –

2

Если вы находите это намного медленнее под отладчиком, у вас есть много предупреждений?

Предупреждения, как правило, генерируются парсером antlr, который он использует, и парсер выдает исключения, которые являются очень дорогими.

Работа по исправлению предупреждений и времени сборки должна снизиться.

Ed

+0

Спасибо Эдди за подсказку. Я проверю это. Он работает в прямом эфире на 100-летних клиентах уже более 18 месяцев, поэтому он не находится в верхней части списка приоритетов, и, очевидно, они работают в режиме деблокирования. У нас нет правильной или ошибочной политики «0 предупреждений о компиляции», поэтому вполне возможные предупреждения были подняты и проигнорированы: | –

1

У нас была такая же проблема - dacpac развертывает будет выполнять отлично при выполнении тестов, но работать очень медленно при отладке тестов.

В моем случае у dacpac была куча скриптов .sql, которые засеяли некоторые тестовые данные в базу данных. Один из этих сценариев был сгенерирован с SSMS, так что это было долго 40,000 линии, что-то вроде этого:

INSERT [dbo].[Resource] ([CategoryId], [StoreCode], [LocaleCode], [ResourceName], [ResourceText]) VALUES (1, N'AU', N'en-AU', N'AD', N'Andorra') 
GO 
INSERT [dbo].[Resource] ([CategoryId], [StoreCode], [LocaleCode], [ResourceName], [ResourceText]) VALUES (1, N'AU', N'en-AU', N'AE', N'United Arab Emirates') 
GO 
INSERT [dbo].[Resource] ([CategoryId], [StoreCode], [LocaleCode], [ResourceName], [ResourceText]) VALUES (1, N'AU', N'en-AU', N'AF', N'Afghanistan') 

и т.д., для 40 000 линий, то есть 20000 INSERT И GO заявления. Мне удалось увидеть, что сценарий вызывает проблему, запрашивая мою таблицу dbo.Resource во время отладки и видя, что этот скрипт выполняется медленно, поскольку количество строк в этой таблице все еще увеличивается.

Я переписал этот скрипт, используя некоторые макросы Notepad ++, чтобы иметь меньше операторов INSERT и вставить 1000 строк на каждый INSERT, например.

INSERT [dbo].[Resource] ([CategoryId], [StoreCode], [LocaleCode], [ResourceName], [ResourceText]) VALUES 
(1, N'AU', N'en-AU', N'AD', N'Andorra'), 
(1, N'AU', N'en-AU', N'AE', N'United Arab Emirates'), 
(1, N'AU', N'en-AU', N'AF', N'Afghanistan'), 
... 
GO 

, и это устраняет проблему.

+0

Полезно знать, Мэтт. благодаря –

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

  • Нет связанных вопросов^_^