2016-11-22 14 views
0

Реферат: База данных «master» содержит набор строк подключения. Файл .dtsConfig XML используется для указания пакетов в эту базу данных. Динамическое назначение соединений выполняется с использованием переменных пакета и выражений в соединениях. Работает безупречно в среде разработки, но раз развертывается, чтобы жить, она падает.SQL Server 2014, SSDT: развертывание пакетов .dtsx для жизни, проблемы с менеджерами подключений и переменными

В настоящее время у меня возникают проблемы при развертывании пакетов .dtsx в производственной среде. Проблема связана с диспетчером соединений при выполнении заданий. Журнал истории сообщает об ошибке ... network ... с ошибкой Login timeout.

(Для справки, я использую Visual Studio 2013 с инструментами SQL Server Data)

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

  2. Пакеты проверяют файл конфигурации, который указывает их в базу данных, как указано в (1).

  3. Соединения извлекаются и помещаются в переменную объекта.

  4. Переменная отображается в контейнер цикла foreach, где набор переменных строки соединения сопоставляется с соответствующими столбцами.

  5. Затем пакеты прогрессируют как обычно.

Некоторые примечания:

  1. Когда я сделал развитие, я предоставил значения по умолчанию в моей сети для соединения строк.

  2. Я проверил параметры строки подключения и форматирование внутри базы данных и они соответствуют спецификации Microsoft.

  3. Наши разработчики установили SSDT на сервере QA клиента, где я изменил переменные соединения, чтобы указать на их сеть. Это решило проблему, но она не устойчива (по крайней мере, на мой взгляд).

Так что мой вопрос: как я могу получить мои развертывания производства для правильной работы с динамическим назначением управления соединения без необходимости изменять строки соединения переменных внутри каждого пакета на одного клиента основе?

Любая помощь будет оценена по достоинству.

ответ

0

После проведения дополнительных исследований, поставив много вопросов на DuckDuckGo, я наконец получил свой ответ here.

Цитата из вышеприведенного блога:

У меня был набор SSIS пакетов, работающих для моего клиента, используя третий вариант, указанный выше. Пакеты работали отлично на века до одного прекрасного дня, когда они потерпели неудачу.Журналы показали, что пакеты не прошли проверку, и я обнаружил, что у всех пакетов были менеджеры соединений DelayValidation свойство установлено на False. Переменная, используемая для установки строки подключения, имела значение по умолчанию, указывающее на сервер DEV. Эти пакеты в производстве фактически пытались проверить наличие базы данных DEV, хотя строка подключения была динамически задана с помощью переменной, указывающей на PROD. Это было опасно, так как задания не запускались, если сервер DEV не работал, что и произошло.