@Ravenenok

Различное поведение SSIS в MSSQL 2012 и 2014?

Для загрузки данных c sybase ASE 15.7 в MS SQL используем SSIS.

Изначально пакет был создан в VS 2010 и успешно работал на MS SQL 2012, после этого был развернут новый MS SQL 2014 и VS2013, пакет бы перенесен на новый сервер и тут была замечена одна неприятная особенность.

Пакет содержит 26 параллельных DataFlow блоков, которые используют один объект Connection Manager, который в свою очередь использует Sybase ASE ODBC драйвер.

Если запускать пакет из VS2010 и MSSQL 2012, то каждый DataFlow при работе создает одно подключение к базе Sybase и после завершения закрывает соединение, таким образом изначально создается 26 соединений, которые в процессе работы уменьшаются до 0. По мониторингу процессов видно, что все соединения создаются от процесса Devenv.exe

Если запускать этот же пакет из VS2013 и MSSQL 2014, то сразу при открытии пакета в студии, он создает 26 соединений от devenv.exe, при запуске пакета сразу создается еще 26 соединений, но уже от процесса DtsDebugHost.exe, в процессе работы от этого же процесса создается дополнительное кол-во соединений, при этом каждый раз разное, при этом 80% всех соединений находится в статусе sleep.

Вроде бы не ошибка, но проблема в том, что кол-во соединений с Sybase ограничено лицензией и выполнение пакета создает большее кол-во соединений, чем разрешено лицензией и выполнение пакета прекращается с ошибкой.

Дополнительно отмечу, что RetainSameConnection установлен в false и не играет роли в данной ситуации.

Окружение серверов полностью идентичное.

С чем связано такое поведение SSIS на 2014 сервере и можно ли как-то его заставить вести себя как в MSSQL 2012?
  • Вопрос задан
  • 232 просмотра
Решения вопроса 1
@Ravenenok Автор вопроса
Однозначного ответа я не нашел, но в ходе экспериментов было установлено, что процесс dtsdebughost создается только в студии и только в 2013. В 10 и 12 студиях такого нет.

При запуске пакета через агента sql на сервере создается кол-во соединений равное кол-ву dataflow блоков без retainsameconnection, плюс кол-во connectionmanagerов с включенной опцией retainsameconnection.

В итоге выкрутились следующим образом, создали 2 connectionmanegera (cm) в один завернули всю мелочь с опцией rts true, во второй все большие таблицы с опцией rts false, таким образом получили кол-во подключений к базе меньше 20, а в скорости проиграли буквально на 30 секунд.

В дополнение в студии для всего включили опцию delayedvalidation, чтобы она коннекты при открытии пакета не создавала.
Ответ написан
Комментировать
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы