Есть ли способ заставить дочерние пакеты писать независимо в catalog.operation_messages?

Я унаследовал множество наборов пакетов SSIS, которые имеют следующую структуру:

В каждой группе один основной пакет выполняется заданием SQL Server. Главный пакет (за исключением некоторых минимальных операций ведения журнала) не содержит ничего, кроме десятков задач ExecutePackage. Они вызывают дочерние пакеты с ExecuteOutOfProcess False.

Задачи ExecutePackage иногда располагаются последовательно (связанные с ограничениями OnCompletion), но иногда и с сильным параллелизмом: например, один контейнер последовательности, содержащий 40 задач ExecPackage, без ограничений, управляющих порядком их выполнения.

Это делает отладку проблем очень сложной. SSISDB.catalog.operation_messages — мой друг. Но кажется, что только главный пакет записывает строку в catalog.executions, и все сообщения от всех дочерних пакетов в конечном итоге смешиваются под тем единственным идентификатором операции, который принадлежит главному пакету. Иногда имя компонента в сообщении дает мне подсказку: но предыдущие разработчики часто не меняли имена компонентов при клонировании пакетов, так что даже это вводит в заблуждение.

Было бы здорово, если бы каждый дочерний пакет мог написать свою собственную строку catalog.executions, и тогда все его сообщения были бы под этим идентификатором операции (идентификатор_исполнения в таблице catalog.executions). Есть ли способ сделать это? Будет ли ExecuteOutOfProcess=True делать это, и есть ли у него недостатки?


ssis
person SebTHU    schedule 09.04.2020    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Вы определенно не хотите не устанавливать ExecuteOutOfProcess=true. Это запустит новый процесс Windows под названием «DTS — суррогатная служба» для каждого приложения. Это потребует дополнительного времени при запуске дочерних пакетов и никак не повлияет на ведение журнала в каталоге.

Что у вас есть в вашем существующем процессе, так это то, что SSIS принудительно использует уникальные имена в контейнере, а сообщения о событиях имеют свойство, называемое «путь выполнения», которое приведет вас к точному местоположению задачи. Таким образом, это должно помочь отслеживать исключения — контекстная ссылка также поможет при задании значений переменных.

Кроме того, не помешало бы перестроить его. Рассмотреть возможность:

  • Группировка связанных задач в подчиненные пакеты
  • используя задачи executesql и потоки данных вместо пакетов, когда пакет не дает вам ничего, кроме контейнера, в котором выполняется поток данных. Другими словами, распутайте спагетти.
  • Замена общих имен значимыми. Вместо «Выполнить пакет 1» попробуйте «Загрузить данные клиента в промежуточную версию».
  • Добавление перезапуска в процесс. Это можно сделать с помощью контрольной таблицы, и это даст общую картину того, где происходит сбой процесса.
  • Промежуточные данные и сделать промежуточные таблицы прощающими. Например, если у вас есть поле, которое необходимо преобразовать в дату, но иногда оно имеет недопустимые значения, его удобно поместить в строковый столбец в промежуточной таблице, чтобы вы могли найти значение, вызывающее возможную ошибку преобразования.
person Mark Wojciechowicz    schedule 09.04.2020
comment
Очень полезный ответ, спасибо. Редизайн, я согласен, лучше всего. Невозможно прямо сейчас (обычные дерьмовые причины - просроченный проект, agile и т. д.). Лучшим обходным решением является этот путь выполнения. Но где ты это видишь? Его нет в catalog.operation_messages. - person SebTHU; 14.04.2020
comment
Вы найдете это в catalog.event_messages. Кроме того, если вы используете стандартные отчеты в SSMS, они показывают это там. Наконец, приведенные выше пункты могут потребовать много работы в зависимости от того, насколько болен пациент. Я бы порекомендовал выполнять один этап рефакторинга за раз, чтобы это не было масштабным мероприятием. Переименуйте вещи в этом месяце, перегруппируйте пакеты в следующем месяце, замените дочерние пакеты потоками данных в следующем и так далее. - person Mark Wojciechowicz; 14.04.2020
comment
catalog.event_messages.package_path и execute_path — это решение для диагностики. К сожалению, дочерние пакеты также не создают никаких собственных отчетов о выполнении! - person SebTHU; 21.04.2020