Задача потока данных SSIS зависает при исключении фазы Pre-excecute

У меня есть задача потока данных, которая висит на исключение.
Поток прост, выполняет два запроса к разным таблицам (оба с парой объединений), затем сортирует и объединяет результаты с помощью общего идентификатора, добавляет статический столбец ко всем записям, сохраняет количество строк в пользовательской переменной для последующего использования. использовать и, наконец, вставляет в таблицу на другой БД. Мы используем OLE DB Sources и Destination. Источник - MSSQL 2000, а пункт назначения - MSSQL 2012

Симптомы:

При исключении поток данных получает обычный желтый значок "работает". Однако при двойном щелчке, чтобы увидеть поток данных, ни один из элементов не имеет желтой, красной или зеленой метки. Это продолжается в течение длительных периодов времени, сначала оно длилось около 20 минут, после чего оно начало удлиняться или просто не возвращалось вообще. Вывод показывает:
Информация: 0x40043006 в таблице изолированной программной среды загрузки, SSIS. Трубопровод: начинается подготовка к выполнению.
Информация: 0x40043007 в таблице изолированной программной среды загрузки, SSIS. Конвейер: начинается этап перед выполнением.
И не более того, пока исключение не будет прекращено. Да, это работало раньше. И да, мы использовали один запрос (в хранимой процедуре) для этого ETL, но мы хотели перенести все шаги в SSIS.

Неудачные решения:

Там нет поисков. Размер буфера по умолчанию для потока задач был увеличен до 40485760, а затем до 80971520. Максимальное количество строк в буфере для задачи было установлено равным 1000000. Задержка проверки была установлена в True для задачи. Все элементы в задаче были установлены в Validate External Data на False. Оба запроса имели:
ВЫКЛЮЧИТЕ FMTONLY;
ВКЛЮЧИТЬ СЧЕТ;
добавлено в начале. Для обоих запросов MAXDOP был установлен в 1. Настройка проекта Run 64 bit Runtime в False. Изменена целевая загрузка с таблицы или представления на таблицу или представление - быстрая загрузка без блокировок или ограничений. Установите количество строк в партии до 1000 для быстрой загрузки. Некоторые обходные пути предлагают разделить поток задач на два или более потоков задач. Но это невозможно, поскольку нам нужно объединить информацию, найденную в обоих исходных запросах.

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

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

Progress: 2013-03-19 14:36:26.21
   Source: Load Sandbox Table
   Validating: 0% complete
End Progress
Progress: 2013-03-19 14:36:26.21
   Source: Load Sandbox Table
   Validating: 12% complete
End Progress
Progress: 2013-03-19 14:36:26.22
   Source: Load Sandbox Table
   Validating: 25% complete
End Progress
Progress: 2013-03-19 14:36:26.22
   Source: Load Sandbox Table
   Validating: 37% complete
End Progress
Progress: 2013-03-19 14:36:26.23
   Source: Load Sandbox Table
   Validating: 50% complete
End Progress
Progress: 2013-03-19 14:36:26.25
   Source: Load Sandbox Table
   Validating: 62% complete
End Progress
Progress: 2013-03-19 14:36:26.25
   Source: Load Sandbox Table
   Validating: 75% complete
End Progress
Progress: 2013-03-19 14:36:26.25
   Source: Load Sandbox Table
   Validating: 87% complete
End Progress
Progress: 2013-03-19 14:36:26.25
   Source: Load Sandbox Table
   Validating: 100% complete
End Progress
Warning: 2013-03-19 14:36:26.26
   Code: 0x80047076
   Source: Load Sandbox Table SSIS.Pipeline
   Description: The output column "ITEM_OID (1)" (47) on output "Merge Join Outp
ut" (28) and component "Merge Join" (11) is not subsequently used in the Data Fl
ow task. Removing this unused output column can increase Data Flow task performa
nce.
End Warning
Progress: 2013-03-19 14:36:26.27
   Source: Load Sandbox Table
   Prepare for Execute: 0% complete
End Progress
Progress: 2013-03-19 14:36:26.27
   Source: Load Sandbox Table
   Prepare for Execute: 12% complete
End Progress
Progress: 2013-03-19 14:36:26.27
   Source: Load Sandbox Table
   Prepare for Execute: 25% complete
End Progress
Progress: 2013-03-19 14:36:26.27
   Source: Load Sandbox Table
   Prepare for Execute: 37% complete
End Progress
Progress: 2013-03-19 14:36:26.27
   Source: Load Sandbox Table
   Prepare for Execute: 50% complete
End Progress
Progress: 2013-03-19 14:36:26.27
   Source: Load Sandbox Table
   Prepare for Execute: 62% complete
End Progress
Progress: 2013-03-19 14:36:26.27
   Source: Load Sandbox Table
   Prepare for Execute: 75% complete
End Progress
Progress: 2013-03-19 14:36:26.27
   Source: Load Sandbox Table
   Prepare for Execute: 87% complete
End Progress
Progress: 2013-03-19 14:36:26.27
   Source: Load Sandbox Table
   Prepare for Execute: 100% complete
End Progress
Progress: 2013-03-19 14:36:26.31
   Source: Load Sandbox Table
   Pre-Execute: 0% complete
End Progress
Progress: 2013-03-19 14:36:26.31
   Source: Load Sandbox Table
   Pre-Execute: 12% complete
End Progress
Progress: 2013-03-19 14:36:26.31
   Source: Load Sandbox Table
   Pre-Execute: 25% complete
End Progress
Progress: 2013-03-19 14:36:26.34
   Source: Load Sandbox Table
   Pre-Execute: 37% complete
End Progress
Progress: 2013-03-19 14:36:45.69
   Source: Load Sandbox Table
   Pre-Execute: 50% complete
End Progress

После этого он снова зависает.

РЕШЕНИЕ (разместив это здесь, потому что я не могу ответить на свой вопрос еще 5 часов, я сделаю это, когда мне позволят.)
Я наконец получил это.
Оказывается, есть проблема с проверкой, но не только элементы SSIS проходят эту проверку, как указано в четвертом неудачном решении вопроса.
CONNECTIONS также проходят проверку и имеют собственное свойство Delay Validation, для которого необходимо установить значение true.
После этого время исключения увеличилось с 40+ минут или бездействия до менее минуты для полного процесса (это только один шаг из гораздо большего процесса)
Я надеюсь, что люди с такой же проблемой могут легко найти это решение, потому что есть много людей, сталкивающихся с этой проблемой, и почти нет решений, размещенных в Интернете.

В двух словах: убедитесь, что для всех ваших элементов, участвующих в задаче, включая подключения к БД, свойство проверки задержки установлено в значение True.

Ответ 1

Я, наконец, понял. Оказывается, есть проблема с проверкой, но не только элементы SSIS проходят эту проверку, как указано в четвертом неудавшемся решении вопроса. ПОДКЛЮЧЕНИЯ также проверяются и имеют собственное свойство проверки задержек, для которого должно быть установлено значение true. После этого время исключения продолжалось с 40 + мин или не выполнялось меньше минуты для полного процесса (это всего лишь один шаг гораздо большего процесса) Я надеюсь, что люди с этой же проблемой могут легко найти это решение, потому что в этой проблеме много людей, и почти нет решений, размещенных в Интернете.

В двух словах:. Убедитесь, что все ваши элементы, участвующие в задании, включая соединения с БД, имеют свойство проверки задержки для параметра "Истина".

Ответ 2

У меня были те же симптомы, но установка задержки проверки на True на каждом компоненте не решила мою проблему.

Я решил это, изменив метод OLE DB из таблицы или представления, в команду sql.

С уважением.

Ответ 3

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

https://connect.microsoft.com/SQLServer/feedback/details/258901/ssis-views-as-data-source-very-poor-performance-or-ssis-hangs

важной частью этого является ответ Microsoft

Отправлено Microsoft от 28.04.2008 в 14:45

Это проблема с информацией и результат текущего дизайна.

Есть два способа извлечь данные из представления в источнике OLE DB:

Использовать метод доступа "Таблица или просмотр"

Используйте метод доступа "SQL command" и введите запрос "select * from ***"
В двух подходах создается другой план выполнения.

Используемый в первом случае не так эффективен, как последний.

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

Мы также опубликовали эту статью в блоге → http://blogs.msdn.com/sqlperf/archive/2007/04/29/set-up-ole-db-source-to-read-from-view-efficiently.aspx.

Так как это элемент "По дизайну", и мы считаем, что есть работа, мы не будем давать никаких изменений в это время. В результате мы закрываем дело, связанное с вашим представлением. Если вы не согласны, пожалуйста, не стесняйтесь повторно отправлять.

Мы ценим ваше время, усилия и поддержку SSIS.

Ответ 4

Исправлена проблема с изменением режима доступа к данным на SQL Command и вставка моего представления в текст команды SQL в источнике OLE DB.

Ответ 5

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

Я проверил шаги OP, и он упоминает, что они сделали это на шаге 5

Ответ 6

Еще одна вещь, по-видимому, состоит в том, чтобы проверить флажок "Использовать 32-битную рабочую среду" - это, если вы видите проблему при запуске пакета как задание на вашем сервере БД (который является 64-битным, и в мой случай, по крайней мере, SQL Server 2008R2). Перейдите к заданию, щелкните правой кнопкой мыши > Свойства... > Шаги > щелкните правой кнопкой мыши на шаге пакета SSIS > Свойства... > Общие > Параметры выполнения (вкладка) > Используйте 32-битную рабочую среду.

Я видел эту проблему, но только после того, как я развернул пакет на сервере (у меня был включен провайдер протоколирования, поэтому я видел, как он застревает после фазы "Pre-Execute" ). Он всегда работал отлично в BIDS (и отлично на другом сервере, странно... все еще не уверен, почему это так).

Нить здесь подсказывала мне это решение, которое, похоже, работает - хотя моя проблема возникает периодически, поэтому YMMV. В этом потоке есть и другие возможные решения.

Ответ 7

Надеюсь, это поможет кому-то. Я пытался использовать этот источник OLE DB для выполнения SP с параметром. Мне не нужно было ничего возвращать, поэтому я оставил эту часть. Но это не позволило мне, он закричал: "никакая информация о столбцах не была возвращена sql". Так настроен фиктивный sql-оператор в моем SP, который я установил, чтобы никогда не было правдой. Но он никогда не получал этот столбец как результат, а работа просто зависала на этапе предварительного исполнения. Поэтому я изменил этот тест, чтобы всегда быть правдой, он возвратил столбец и престо. Я ничего не делаю с колонкой, но я думаю, что она там нужна.

Ответ 8

Эта проблема по-прежнему активна в SQL Server 2012/2014.

Ни одно из упомянутых выше решений не помогло. На самом деле ничего не изменилось, задерживая проверку, изменяя конфигурацию назначения OLD DB или OLE DB Connection.

Чтение потока из этой ссылки: https://social.msdn.microsoft.com/Forums/sqlserver/en-US/35a484c7-4850-4f86-b14a-5dfb50491ab2/long-duration-preexecute-phase?forum=sqlintegrationservices

предполагается, что проблема связана с планом выполнения.

Это было верно для моего случая и добавив условие 1 = 1 к моей конфигурации источника OLE DB, вынудило SQL-сервер создать новый план выполнения, который исправил проблему для меня.

Ответ 9

Я столкнулся с тем же вопросом несколько минут назад, и приведенные выше предложения не сработали для меня (проверка задержки = true, похоже, подходит для ответа). Недавно мы обнаружили некоторые проблемы с параметром sniffing, и как только я исправил, что в моих хранимых процедурах мой пакет работал в < 1 мин. Попробуйте проверить сохраненные процедуры, чтобы убедиться, что это может быть причиной.