Не удается развернуть проект SSIS – Ошибка во время выполнения «encrypt_binarydata»
У меня есть проект SSIS, который я создал, который имеет DontSaveSensitive
защиты DontSaveSensitive
и с радостью развернулся на локальном сервере несколько раз до сегодняшнего дня. Однако я получаю следующую ошибку при развертывании:
Ошибка .NET Framework возникла во время выполнения пользовательской подпрограммы или агрегата «encrypt_binarydata»: System.IO.FileLoadException: Не удалось загрузить файл или сборку «System.Core, Version = 4.0.0.0, Culture = neutral, PublicKeyToken = b77a5c561934e089» или одной из его зависимостей. Недостаточно памяти для обработки этой команды. (Исключение из HRESULT: 0x80070008) System.IO.FileLoadException: в Microsoft.SqlServer.IntegrationServices.Server.Security.CryptoGraphy.CreateSymmetricKey (алгоритм String) в Microsoft.SqlServer.IntegrationServices.Server.Security.CryptoGraphy.EncryptBinaryData (алгоритм SqlStringName, SqlBytes ключ, SqlBytes IV, SqlBytes binaryData). (Microsoft SQL Server, ошибка: 6522)
- Изменение даты времени остановки сервера Выполнение пакета SSIS, как проверить зависимость от времени?
- Для пользовательского компонента SSIS, почему я должен помещать его в GAC?
- Как искать в visual studio для конкретной таблицы базы данных
- SQL Server: архивирование старых данных
- Тесты и пакеты SSIS на разных решениях
У меня был google, но не встречал ничего, что конкретно ссылается на encrypt_binarydata
. Существует ряд ссылок на deploy_project_internal
или ненадежные сборки, но ничего по этой конкретной проблеме.
Важная часть, похоже ,
Недостаточно памяти для обработки этой команды
но я не могу сделать голову или хвост этого, так как есть много гигабайт ОЗУ, запасных и большого количества дискового пространства для использования, поэтому ресурсы не должны быть проблемой.
Может ли кто-нибудь пролить свет на то, что эта ошибка имеет в виду, и в идеале, как я могу ее решить?
- Как передать данные переменной таблицы в поток данных в ssis
- Передача / преобразование данных из базы данных SQL Server 2008 в другую
- конвертировать Excel Date Serial Number в стандартную дату
- Установка переменной String в SSIS
- Возможно ли проанализировать этот XML-файл с помощью SQL Server или SSIS?
- Создание пакета SSIS - копирование данных с Oracle на SQL Server
- Как избежать ручного просмотра DLL в разделе «Добавить ссылку на скрипт» при развертывании пакета на производстве?
- SSIS Преобразование символа в логический / бит
Оказывается, это проблема с разрешениями, которые сильно запутались во внутренней работе 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