Что на самом деле делают несколько работающих версий службы SSIS?

У меня есть сервер, на котором работают 3 разные версии службы SSIS. (В данном случае это версии 10, 11 и 13).

Кажется, что существует единое хранилище пакетов в SSISDB. Меня сбивает с толку, что это означает для версий развернутых пакетов. (Я не имею в виду версию объекта SSIS, я имею в виду, для какой версии SSIS они изначально созданы).

1. Делают ли что-то службы SSIS более низких версий на самом деле, или я могу их остановить? Мне не нравится, что каждая версия использует различную учетную запись для входа в службу: доставляет много радости управлять разрешениями, если более низкие версии действительно что-то делают.
2. Я не могу найти никакой журнал службы SSIS (например, что-то, которое говорит “запуск службы SSIS 2016 (т.е. 13.0)”). SSISDB.catalog.event_messages, похоже, охватывает только выполнение пакетов. Существует ли такой журнал?
3. Как я могу узнать целевую версию (например, 2014, 2016) пакетов/проектов, хранящихся на сервере? Или пакеты/проекты преобразуются в версию службы SSIS (или, в данном случае, в наивысшую версию любой службы SSIS) при развертывании, а не при проверке/выполнении?

Я никогда не сталкивался с такой запутанной настройкой раньше, и я немного озадачен тем, с чего начать ее анализировать.

Что делают несколько версий службы SSIS, работающие одновременно?

Ваша ситуация, когда на сервере работают несколько версий службы SQL Server Integration Services (SSIS) – 10, 11 и 13, действительно может создать запутанность в управлении пакетами и их выполнением. Рассмотрим несколько ключевых аспектов вашего вопроса.

1. Функции и взаимодействие между версиями SSIS

Каждая отдельная версия службы SSIS может работать независимо и, в большинстве случаев, обрабатывать только те пакеты, которые были разработаны или корректно развернуты для данной версии. Интересно, что SSISDB может хранить пакеты, которые предназначены для выполнения более старой, текущей или более новой версии службы. Это предоставляет гибкость, но требует осторожности при управлении пакетами, чтобы избежать проблем совместимости.

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

2. Логи и их нахождение

SSISDB.catalog.event_messages действительно покрывает только выполнение пакетов и не содержит информации о запуске служб. Однако, вам могут помочь системные журналы событий Windows, в которых часто фиксируются сообщения о запуске и остановке служб. Это может включать информацию о версиях, но может потребовать дополнительной фильтрации и анализа данных.

3. Идентификация версии целевых пакетов

Пакеты сохраняют метаданные, которые могут указывать на версию проекта или пакета. Эти данные можно получить с помощью SQL-запроса к SSISDB или используя инструменты управления SQL Server. Пакеты, как правило, не преобразуются в новую версию в момент развертывания; они могут быть выполнены на версии службы, совместимой с их разработчиком.

Процесс преобразования обычно происходит в момент обновления пакета в дизайнере SSIS, но не при простом развертывании или выполнении. Кроме того, было бы целесообразно согласовать стратегии и процессы развертывания для упрощения сопровождения и уменьшения числа активных версий службы.

Заключение

Ваш случай уникален, и требует аккуратного анализа текущих установок и содержания пакетов. Возможно, стоит составить график миграции всех пакетов на единую версию SSIS, чтобы упростить администрирование и уменьшить количество потенциальных проблем с совместимостью. Не забудьте также учитывать безопасность и права доступа в контексте каждой служебной учетной записи.