【问题标题】：Cannot deploy SSIS project - Error during execution of "encrypt_binarydata"无法部署 SSIS 项目 - 执行“encrypt_binarydata”期间出错
【发布时间】：2017-06-20 16:25:52
【问题描述】：

我创建了一个具有DontSaveSensitive 保护级别的 SSIS 项目，并且在今天之前多次愉快地部署到本地服务器。但是，我现在在部署时遇到以下错误：

执行用户定义的过程中发生 .NET Framework 错误例程或聚合“encrypt_binarydata”： System.IO.FileLoadException：无法加载文件或程序集 'System.Core，版本=4.0.0.0，文化=中性， PublicKeyToken=b77a5c561934e089' 或其依赖项之一。不是有足够的存储空间来处理此命令。（例外来自 HRESULT：0x80070008）System.IO.FileLoadException：在 Microsoft.SqlServer.IntegrationServices.Server.Security.CryptoGraphy.CreateSymmetricKey（字符串算法）在 Microsoft.SqlServer.IntegrationServices.Server.Security.CryptoGraphy.EncryptBinaryData（SqlString algorithmName，SqlBytes 键，SqlBytes IV，SqlBytes binaryData)。（Microsoft SQL Server，错误：6522）

我有一个谷歌，但没有找到专门引用 encrypt_binarydata 的内容。有很多关于deploy_project_internal 或untrusted assemblies 的引用，但在这个特定问题上没有任何内容。

重要的部分似乎是

没有足够的存储空间来处理这个命令

但我无法确定这一点，因为有许多 GB 的 RAM 可用，并且有大量驱动器空间可供使用，因此资源不应该成为问题。

谁能解释这个错误指的是什么以及理想情况下我该如何解决它？

【问题讨论】：

标签： sql-server ssis

【解决方案1】：

原来这是一个权限问题，在 SSISDB 的内部工作中，SQL 和 dll 文件之间的权限变得非常混乱。原始问题中的错误信息实际上是一个红鲱鱼，真正的问题与this excellent resolution 中解决的问题相同。

为了子孙后代，万一答案消失了（以及不想点击另一个链接的懒人），这里是完整的参考答案

感谢Remus Rusanu

带有 EXTERNAL_ACCESS 的程序集通过一些复杂的路径落入 EXECUTE AS 路径下。当“dbo”无法映射到有效登录时，就会出现问题。 dbo 的登录名是 SID 为owner_sid 值的登录名，位于sys.databases 中。除非在 CREATE DATABASE 中使用了 AUTHORIZATION 子句，否则 owner_sid 是发出 CREATE DATABASE 语句的主体的登录 sid。大多数情况下，这是用户登录并发出 CREATE DATABASE 的 Windows SID。掌握了这些知识，您可以轻松设想可能出现的问题：

复制数据库：CREATE DATABASE 由 A 本地用户（即 MachineA\user 或 DomainA\user）在机器 A 上发出，然后将数据库复制到机器 B（通过备份/恢复或文件复制）。 owner_sid 由文件副本以及备份/恢复保留，这在机器 B 上 owner_sid 无效。需要 EXECUTE As 的所有操作都会失败，包括从数据库加载程序集。
墓碑帐户。 CREATE DATABASE 由已离开公司的用户发布。 AD 帐户被删除，突然 EXECUTE AS 神秘地失败了，包括加载程序集。
笔记本电脑断开连接。当笔记本电脑连接到工作网络时，CREATE DATABASE 出现问题。在家里，您可以使用 Windows 缓存凭据登录，但 EXECUTE AS 想要连接到不可用的 AD 并失败。加载程序集也失败。第二天在工作中，当您再次触手可及 AD 时，问题就神秘地自行解决了。
不稳定的 AD 连接。 EXECUTE AS 不使用系统缓存的凭据，每次都连接到 AD。如果 AD 连接存在问题（超时、错误），则这些问题表现为 EXECUTE AS 中的类似超时和错误，包括加载程序集

所有这些问题都可以通过在问题 db 的上下文中简单地运行：EXECUTE AS USER = 'dbo'; 来诊断。如果它失败并出现错误，那么您的程序集加载问题的原因是dbo 的 EXECUTE AS 上下文。

解决方案很简单，只需强制owner_sid 进行有效登录即可。 sa 通常是最好的候选人：

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

有趣的是，数据库可能看起来非常健康；表可用，您可以运行选择、更新、删除、创建和删除表等。只有某些组件需要EXECUTE AS：

代码签名要求代码具有 EXECUTE AS 子句
程序集验证
在 T-SQL 代码中显式 EXECUTE AS
Service Broker 消息传递（包括查询通知）

后者是最常见的罪魁祸首，因为依赖SqlDependency 的应用程序似乎突然停止工作，或者出现随机问题。这篇文章解释了SqlDependency最终如何依赖于EXECUTE AS:The Mysterious Notification

【讨论】：