У меня есть пакет служб SSIS - две задачи потока данных, по 8 компонентов каждая, чтение из двух плоских файлов, ничего особенного. Если я запускаю его в BIDS, это надежно занимает около 60 секунд. У меня есть сервер БД песочницы с пакетом, выполняющимся в задании, которое также надежно занимает 30-60 секунд. На моем производственном сервере та же самая работа с тем же пакетом занимает от 30 секунд до12 часов.

При включенном ведении журнала в пакете это выглядит так, как будто он застопорился - по крайней мере, первоначально - на этапе предварительного выполнения одной или другой (или обеих) задач потока данных. Но я также вижу, как поступают данные - медленно, по частям, поэтому я думаю, что они потом оттуда уйдут. Подсистема ввода-вывода становится заглушенной, и SSIS генерирует много больших временных файлов (около 150 МБ - мои входные файлы составляют всего около 24 МБ вместе взятых) и энергично читает и записывает из этих файлов (бьется?).

Следует отметить, что если я укажу свой экземпляр BIDS пакета на производственный сервер, запуск все равно займет около 60 секунд! Так что должно быть что-то с запущенным там dtexec, а не с самой БД.

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

Оба сервера БД работают под управлением MSSQL 2008 R2 64-разрядной версии, одинакового уровня исправлений. Оба сервера являются виртуальными машинами на одном хосте с одинаковым распределением ресурсов. На данный момент нагрузка на рабочий сервер не должна быть намного выше, чем на сервере-песочнице. Единственное отличие, которое я вижу, состоит в том, что рабочий сервер работаетWindows Server 2008, в то время как песочница находится на Windows Server 2008R2.

Помогите!!! Любые идеи, которые можно попробовать, приветствуются, что может быть причиной этого огромного расхождения?

Приложение

Вот как выглядит моя посылка ...

Поток управления предельно прост:

Поток данных выглядит так:

Вторая задача потока данных точно такая же, только с другим исходным файлом и таблицей назначения.

Примечания

Ограничение завершения в потоке управления существует только для того, чтобы задачи запускались последовательно, чтобы попытаться сократить ресурсы, необходимые одновременно (не то, чтобы это помогло решить проблему)… между этими двумя задачами нет реальной зависимости.

Мне известны потенциальные проблемы с блокирующими и частично блокирующими преобразованиями (не могу сказать, что полностью их понимаю, но, по крайней мере, по крайней мере), и я знаю, что агрегатное и слияние объединяются и могут вызывать проблемы. Однако, опять же, все это работает хорошо и быстро в любой другой среде, кроме рабочего сервера ... так что дает?

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

Вывод ошибки «Удалить записи» всегда пуст - это намеренно, так как я не хочу, чтобы в слиянии были строки из этой ветви (слияние только для синхронизации завершения, как объяснено выше).

Смотрите комментарий ниже о значках предупреждения.