Повреждение задачи сценария - ошибка выполнения SSISDB после обновления с SQL Server 2016 до SQL Server 2016 с пакетом обновления 2 (SP2) - PullRequest
0 голосов
/ 27 ноября 2018

Мы недавно обновили наш производственный экземпляр SQL Server 2016 Enterprise с SP1 до SP2.В настоящее время мы находимся на версии 13.0.5026.Перед обновлением пользователь с правами подключения к SSISDB и соответствующими правами в папке каталога служб Integration Services мог успешно развернуть файл ISPAC.

После обновления те же пользователи могут по-прежнему развертываться на SSISDB, но при выполнении .DTSX задача сценария внутри не проходит проверку.Если я разверну тот же ISPAC, что и системный администратор, проблем не возникнет.Обычное решение, которое я видел, состоит в том, чтобы подтвердить, что Свойства конфигурации SSDT установлены на SQL Server 2016. Мы убедились, что это установлено правильно до построения ISPAC.

Я обнаружил аналогичную проблему при миграции с SQL Server2014-2016 гг. Пару лет назад, но решением на тот момент было предоставление учетной записи Proxy, которая запускает права на изменение пакета, в папку C:\Windows\Temp, что позволяет создавать временные файлы.Эту новую проблему сложно определить, и я не хочу выдавать sysadmin только для того, чтобы другие могли выполнить простые шаги развертывания.

Любые мысли и предложения приветствуются.

******* Обновление / редактирование ************:

Серверимеет средство развертывания SQL Server 2016, расположенное в папке SQL Server / 130 / DTS / Binn - ISDeploymentWizard.exe.Этот инструмент развертывания работает.В папке 140 / DTS / Binn есть еще один идентичный мастер, с тем же именем, но на 1 КБ больше (при условии, что SSMS теперь является отдельной установкой, а я установил последнюю и лучшую версию на сервер).Это не удается развернуть.Я бьюсь головой о стену о том, почему один работает, а другой нет.Локально мы все используем SSMS 2017, и с этим мы получаем файл 140 / DTS / Binn ISDeployment, а не 130 (поскольку это SQL Server 2016, и мы используем SSMS 2017, который, как я думал, был обратно совместим).В любом случае, эта проблема только начала возникать, и мы работали с одной и той же версией SSMS в течение нескольких месяцев.

Изображение информационного отчета о выполнении из SSMS

enter image description here

1 Ответ

0 голосов
/ 28 ноября 2018

Недавно удалось решить аналогичную проблему со сценариями C #.Вкратце: не используйте версию 140 ISDeploymentWizard.exe с MS SQL 2016. Очевидно, что что-то искажается в коде C # или в свойствах компонентов, и среда выполнения 2016 перестает их распознавать.

В моем случае пакетс источником сценария C # начал выдавать следующую ошибку на этапе проверки:

Ошибка: Microsoft.SqlServer.Dts.Pipeline.ComponentVersionMismatchException:

Версия C# source component name - этонесовместим с этой версией DataFlow.[[Версия или версия конвейера или оба для указанного компонента выше, чем текущая версия.Этот пакет, вероятно, был создан в новой версии DTS или компонента, который установлен на текущем ПК.]] В Microsoft.SqlServer.Dts.Pipeline.ManagedComponentHost.HostCheckAndPerformUpgrade (оболочка IDTSManagedComponentWrapper100, Int32 lPipelineVersion)

1011 * Первый комментарий
здесь
помог мне окончательно определить причину.
...