Оказывается, это проблема с разрешениями, которые сильно запутались во внутренней работе SSISDB, между файлами SQL и dll. Сообщение об ошибке в исходном вопросе на самом деле является немного красной селедкой, и реальная проблема была такой же, как и проблема, решаемая в этом превосходном разрешении .

Для потомков в случае, если ответ когда-либо исчезает (а также для ленивых людей, которые не хотят нажимать на другую ссылку), вот полный ответ

Кредит Ремусу Русану

Ассембли с EXTERNAL_ACCESS через некоторый запутанный путь попадают под путь EXECUTE AS. Проблема возникает, когда «dbo» не может быть сопоставлен с допустимым логином. Вход dbo – это логин с SID значением sys.databases в sys.databases . Если в CREATE DATABASE не использовалось условие AUTHORIZATION, owner_sid является логином входа в систему принципала, выдающего инструкцию CREATE DATABASE. В большинстве случаев это SID Windows для входа пользователя в систему и выдача CREATE DATABASE. С учетом этих знаний можно легко представить себе проблемы, которые могут возникнуть:

• копировать базу данных: CREATE DATABASE была выпущена на машине A пользователем, локальным для A (то есть MachineA\user или DomainA\user ), после чего база данных была скопирована на машину B (через резервное копирование / восстановление или через копию файла). Владелец_sid сохраняется копией файла, а также резервным копированием / восстановлением, это на машине B owner_sid недействительно. Все, требующее EXECUTE Как не удается, включая загрузку сборок из базы данных.
• надгробный счет. CREATE DATABASE была выпущена пользователем, который покинул компанию. Учетная запись AD удалена, и все внезапные EXECUTE AS таинственно терпят неудачу, включая загрузку сборок.
• отключен ноутбук. CREATE DATABASE была проблема, когда ноутбук был подключен в рабочей сети. Дома вы можете войти в систему с использованием кэшированных учетных данных Windows, но EXECUTE AS хочет подключиться к недоступному AD и не удается. Загрузка сборок также не выполняется. Проблемы загадочно решаются на следующий день на работе, когда вы снова находитесь в пределах досягаемости AD.
• пятнистая связь AD. EXECUTE AS не использует системные кешированные учетные данные и каждый раз подключается к AD. Если возникают проблемы с подключением AD (тайм-аут, ошибки), эти проблемы проявляются в виде аналогичных тайм-аутов и ошибок в EXECUTE AS, включая загрузку сборок

Все эти проблемы можно диагностировать с помощью простого запуска: EXECUTE AS USER = 'dbo'; в контексте проблемы db. Он не работает с ошибкой, поэтому причиной проблем с загрузкой сборки является EXECUTE AS-контекст dbo .

Решение тривиально, просто owner_sid к действительному логину. sa – обычно лучший кандидат:

 ALTER AUTHORIZATION ON DATABASE::[<dbanme>] TO sa; 

Самое забавное, что база данных может показаться совершенно здоровой; доступны таблицы, и вы можете выполнять выбор, обновление, удаление, создание и удаление таблиц и т. д. Только для некоторых компонентов требуется EXECUTE AS :

• подписание кода требует, чтобы код имел предложение EXECUTE AS
• проверка сборки
• Явный EXECUTE AS в коде T-SQL
• Доставка сообщений сервис-брокера (включая уведомления о запросах)

Последний является наиболее часто наблюдаемым преступником, так как приложения, полагающиеся на SqlDependency , внезапно перестают работать или имеют случайные проблемы. В этой статье объясняется, как SqlDependency конечном счете зависит от EXECUTE AS: The Mysterious Notification