在尝试加载程序集 ID 65537 时 Microsoft .NET Framework 出错.服务器可能资源不

Question

在尝试加载程序集 ID 65537 时 Microsoft .NET Framework 出错。服务器可能资源不足，或者不信任该程序集，因为它的 PERMISSION_SET 设置为 EXTERNAL_ACCESS 或 UNSAFE。请重新运行查询，或检查有关的文档了解如何解决程序集信任问题。有关此错误的详细信息:
System.IO.FileLoadException: 未能加载文件或程序集“grqsh.moebius.core7, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null”或它的某一个依赖项。发生与安全有关的错误。 (异常来自 HRESULT:0x8013150A)
System.IO.FileLoadException:
在 System.Reflection.Assembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection)
在 System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
在 System.Reflection.Assembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
在 System.Reflection.Assembly.Load(String assemblyString)
这个是怎么回事呀，在这执行存储过程中出现的！

Answer 1

产生的原因大概是,在备份数据库的时候,在机器A,那么数据库的拥有者是A\Administrator(如果用windows登录创建),那么但是我们还原到服务器B,那么拥有者可能是B\Administrator,那么SQL CLR的安全性会认为该程序集不可靠.

解决方案:
在还原数据库之后,我们可以将数据库的OWNER设置成SA.
exec sp_changedbowner 'sa'
再调用存储过程就是成功的.
可以查看:KB http://support.microsoft.com/kb/918040
后来经过一些整理,发现当SQL CLR 存在EXTERNAL_ACCESS或者是UNSAFE的程序集的时候,SQL Server会检查DBO的SID在sys.databases 和sys.server_principals是否一致.

因此我们可能未必一定要修改成sa 的,只要所有者的SID在sys.databases和sys.server_principals 是一致的,就不出问题.

我们在SSMS里面右键数据库属性->找到文件选项卡->发现在所有者(是空的,还原以后原来的SID,数据库所有者在当前的sys.server_principals不匹配的),我们可以在 [...] 里面选择一个,具有创建CREATE ASSEMLY 权限的所有者就好,我选择了B\Administrator,然后测试 CLR 存储过程,没问题,
引深:

在SQL Server 复制里面也存在类似的问题,就是我们做 "对等复制" 的时候,会出现DBO不存在,以及sp_replcmd 不存在类似的错误.其实也是因为对等复制初始化订阅是通过 RESTORE 来实现的,因此只要简单的修改数据库所有者 就好了....那么对等复制的问题也就解决了!!

Answer 2

use master--这个必需在此数据库
GRANT UNSAFE ASSEMBLY TO [用户];
GRANT EXTERNAL ACCESS ASSEMBLY TO [用户];
ALTER DATABASE [数据库] SET TRUSTWORTHY ON; --可信
=========
做完这三个动作，就搞定了。但，我还没有研究出来，为什么，请高手跟贴。