Има ли начин дъщерните пакети да пишат независимо в catalog.operation_messages?

Наследих много набори от SSIS пакети, които следват тази структура:

Във всяка група един главен пакет се изпълнява от задание на SQL Server. Главният пакет (с изключение на някои минимални операции за регистриране) не съдържа нищо друго освен десетки задачи ExecutePackage. Те извикват дъщерни пакети с ExecuteOutOfProcess False.

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

Това прави отстраняването на грешки много трудно. SSISDB.catalog.operation_messages е мой приятел тук. Но изглежда, че само главният пакет записва ред в catalog.executions и всички съобщения от всички дъщерни пакети в крайна сметка се смесват под този единствен operation_id, който принадлежи на главния пакет. Понякога името на компонента в съобщението ми дава представа: но предишните разработчици често не променяха имената на компонентите при клониране на пакети, така че дори това е подвеждащо.

Би било страхотно, ако всеки дъщерен пакет може да напише свой собствен ред catalog.executions и тогава всички негови съобщения ще бъдат под този идентификатор на операция (execution_id в таблицата 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
Много полезен отговор, благодаря. Редизайн Съгласен съм, че е най-добре. Не е възможно в момента (обичайни глупави причини - просрочен проект, пъргав и т.н.). Най-доброто решение е този път на изпълнение. Но къде виждате това? Не е в 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 и execution_path са решението за диагностика. За съжаление дъщерните пакети също не създават собствени отчети за изпълнение! - person SebTHU; 21.04.2020