Sql Server Azure PERMISSION_SET = EXTERNAL_ACCESS 或 UNSAFE答案

【问题标题】：Sql Server Azure PERMISSION_SET = EXTERNAL_ACCESS or UNSAFESql Server Azure PERMISSION_SET = EXTERNAL_ACCESS 或 UNSAFE
【发布时间】：2015-08-20 04:41:48
【问题描述】：

我们昨天收到了这个错误。我发现一些文章表明这是孤立用户 ID 的问题，但由于数据库托管在 Azure 上，因此无法访问用户配置文件的存储过程，而且我不是数据库专家.

它说它找不到程序集 'microsoft.sqlserver.types' 11.1.0.0 几周前部署的版本是 10.0.0.0 所以我更新了我的 nuget 包，但该版本仅在 11.0.2 上

https://www.nuget.org/packages/Microsoft.SqlServer.Types/

我们目前通过复制数据库解决了这个问题。我觉得它只是暂时解决了，它会再次发生。

System.Data.SqlClient.SqlException ：尝试加载程序集 id 1 时在 Microsoft .NET Framework 中发生错误。服务器可能资源不足，或者程序集可能不受 PERMISSION_SET = EXTERNAL_ACCESS 或 UNSAFE 的信任。再次运行查询，或查看文档以了解如何解决程序集信任问题。有关此错误的详细信息：System.IO.FileNotFoundException: 无法加载文件或程序集 'microsoft.sqlserver.types, Version=11.1.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' 或其依赖项之一。该系统找不到指定的文件。 ---> System.IO.FileNotFoundException：无法加载文件或程序集 'microsoft.sqlserver.types，Version=11.0.0.0，Culture=neutral，PublicKeyToken=89845dcd8080cc91' 或其依赖项之一。该系统找不到指定的文件。 System.IO.FileNotFoundException：System.IO.FileNotFoundException：在 System.Reflection.RuntimeAssembly._nLoad（AssemblyName 文件名，字符串 codeBase，证据 assemblySecurity，RuntimeAssembly locationHint，StackCrawlMark 和 stackMark，布尔 throwOnFileNotFound，布尔 forIntrospection，布尔suppressSecurityChecks）在 System.Reflection。 RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark & stackMark, Boolean for Introspection, Boolean suppressSecurityChecks) at System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark & stackMark, Boolean for Introspection) 在 System.Reflection.Assembly.Load(String组装字符串）

【问题讨论】：

您还遇到同样的问题吗？
嗨，Joesph，两周前又发生了。我们已经升级到 Azure sql server v12。所以我希望这可能已经解决了它。我们会看到
我很想更好地了解您的情况以及触发此错误的原因。能否请您在 microsoft.com 的 joseidz 给我发电子邮件，我们将向该线程报告调查结果？

标签： sql-server azure azure-sql-database

【解决方案1】：

对于您在使用该服务时遇到的问题，我们深表歉意。虽然我们一直在积极调查这个问题，但很难重现（因此很难完全修复）。我们此时掌握的相关数据： • 该问题并非一直发生。当它开始在 SQL 实例上发生时，它是持久的，直到进程被回收。 • 虽然我们遇到了文件未找到错误，但我们对发现问题的机器的检查实际上发现了应该存在的文件 • 我们知道该问题发生在 V11 和 V12 服务器上，但在 V11 服务器上情况更糟，因为该版本的服务代码存在一些架构差异。

目前，我们建议遇到此问题的客户考虑现在是否可以将其服务器迁移到 V12。原因如下： • 根据我们的遥测数据，我们知道 V12 服务器很少遇到此问题 • 由于V11 和V12 之间的架构差异，对V11 的影响范围比对V12 的影响范围更大（这意味着当它发生时会影响更多的客户）。 • 我们在V12 上有额外的服务功能，使我们能够更快地识别和缓解这个问题。我们正在积极努力部署所需的更改。因此，准备就绪后，我们应该能够为遇到此问题的任何客户自动应用缓解步骤。

有些错误比其他错误更难修复，而这个错误比我们预期的要难一些。我们将继续努力追查此问题的确切根本原因（为什么即使文件存在也无法加载）。希望这能为您提供足够的信息，以便在我们追踪它时解决它。

感谢和道歉，康纳坎宁安架构师，SQL

【讨论】：