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

Question

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

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

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

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

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

Answer 1

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

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

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

• Группировка связанных задач в подмастерные пакеты
• с использованием задач sql и потоков данных вместо пакетов , где пакет не дает вам ничего, кроме контейнера, в котором выполняется поток данных. Другими словами, распутайте спагетти.
• Замена имен generi c теми, которые имеют значение, Вместо «Выполнить пакет 1» попробуйте «Загрузить данные клиента в стадии подготовки»
• Добавление перезапускаемости в процесс. Это можно было бы сделать с помощью контрольной таблицы, и это дало бы картину высокого уровня того, где происходит сбой процесса.
• Стадия данных и заставило бы промежуточные таблицы простить. Например, если у вас есть поле, которое необходимо преобразовать в дату, но иногда оно имеет недопустимые значения, это удобно поместить в столбец строки в промежуточной таблице, чтобы вы могли найти значение, вызывающее возможную ошибку преобразования.