SSIS - лучшие практики для менеджеров соединений - составить из параметров?

Question

Я много работал с Pentaho PDI, поэтому некоторые очевидные вещи бросаются в глаза.

С этого момента я буду называть менеджеров соединений "CM".

Очевидно, CM проекта> Пакет CM, для расширяемости / повторного использования. Кажется, действительно редкий случай, когда вам нужен CM уровня пакета.

Но мне интересно еще одна лучшая практика. Должен ли каждый проектный CM сам состоять из переменных? (или параметры, я думаю).

Давайте поговорим в конкретных условиях. Есть конкретные источники базы данных. Давайте назовем два из них: Finance2000 и ETL_Log_db. У них есть определенные строки подключения (пароль, источник и т. Д.).

Теперь, если у вас есть 50 пакетов, извлеченных из Finance2000, а также использующих ETL_Log_db ... хорошо ... что произойдет, если базы данных изменятся? (хост, имя, пользователь, пароль?)

Скажите, что сейчас Финансы3000.

Ну, я думаю, вы можете пойти в Finance2000 и изменить источник, спецификации и даже само имя - тогда все должно работать, верно?

Или вы должны просто создать базу данных уровня проекта под названием «FinanceX» или что-то подобное и сделать ее состоящей из параметров, чтобы строка подключения была чем-то вроде @Source + @ credentials + @ что угодно?

Или это просто избыточно?

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

Answer 1

SSIS, начиная с версии 2012 года, имеет БД каталога служб SSIS. Вы можете создать все свои 50 пакетов в одном проекте, и все эти пакеты используют одни и те же менеджеры подключений к проектам.
Затем вы развертываете этот проект в каталоге служб SSIS; Проект автоматически выставляет параметры диспетчера подключений с префиксом CM. Параметры CM являются частью определения диспетчера подключений.

В каталоге служб SSIS вы можете создавать так называемые среды. В среде вы определяете переменные с именем и типом данных и сохраняете их значение.
Затем - самая интересная часть - вы можете связать среду и загруженный проект. Это позволяет связать параметр проекта с переменной среды.

При выполнении пакета - вы должны указать, какую среду использовать при указании строк подключения. Да, вы можете иметь несколько сред в каталоге и выбирать при запуске Package.
Круто, не правда ли?
Более того, пароли хранятся в зашифрованном виде, поэтому никто не может их скопировать. Значения этих переменных среды могут быть настроены инженерами службы поддержки, которые не знают о пакетах служб SSIS.
Подробнее о каталоге и средах служб SSIS от MS Docs .

Answer 2

Я передам свою справедливую долю опыта.

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

Используемая нами модель не самая лучшая, но по этой и другим причинам работать с ней довольно удобно. Мы используем файлы BAT для передачи именованных параметров в «основное» задание, и, в основном, в зависимости от 2 параметров, задание выполняется на альтернативной базе данных / хосте.

Модель, которую мы используем, состоит в том, что в каждом KTR / KJB мы используем переменные $ {host} и $ {dbname}, эти параметры передаются с каждым BAT-файлом. Поэтому, когда нам пришлось изменить имена хостов и баз данных, это было простое «Заменить все текстовое соответствие» в NotePad ++, и все было готово, было исправлено более 2000 файлов BAT, и времени простоя не было.

Наличие переменной для имени хоста / БД как для клиентского подключения, так и для подключения к журналу позволяет вам иметь такую ​​гибкость, когда все радикально меняется.

Вы также можете использовать файл kettle.properties для подключения к журналу.