Har*_*wok 43 .net sql-server logging sqlclr sql-server-2008-r2
我们为SQL Server 2008 R2开发了一个程序集.
大会已经工作了一个星期.程序集内的托管存储过程在整个星期都运行良好,然后它停止工作.我们已经多次看到这个问题了.使其再次工作的方法是重新启动SQL Server.
Msg 10314, Level 16, State 11, Line 4
An error occurred in the Microsoft .NET Framework while trying to load assembly id 65536. The server may be running out of resources, or the assembly may not be trusted with PERMISSION_SET = EXTERNAL_ACCESS or UNSAFE. Run the query again, or check documentation to see how to solve the assembly trust issues. For more information about this error:
System.IO.FileLoadException: Could not load file or assembly 'myAssembly, Version=2.0.0.490, Culture=neutral, PublicKeyToken=5963130873dd3a75' or one of its dependencies. Exception from HRESULT: 0x80FC0E21 System.IO.FileLoadException:
at System.Reflection.Assembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection)
at System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
at System.Reflection.Assembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
at System.Reflection.Assembly.Load(String assemblyString)
我在网上发现了不同的文章.
这个KB表明我可能已经从另一个SQL Server恢复了数据库,我发誓我没有.
这篇博客说如果我在SQL Server 2005上安装了.NET 3.5,我可能会遇到这种情况,但我的是SQL Server 2008 R2,并且在出现此问题时我没有安装任何东西.
重点是它可以持续一段时间.它只是随机停止工作.然后,如果我们重新启动SQL Server,它将再次开始工作.我原以为我的服务器内存确实不足,但是现在,我再次看到了问题.SQL Server仅使用300MB RAM,我的服务器有16GB RAM.这听起来不可能,因为我的内存不足.
现在,我想收集有关此问题的更多信息.我可以打开并查看的任何日志？欢迎任何有助于解决此问题的建议.
我运行了一些SQL查询.
SELECT * from sys.dm_clr_properties
=============================================
directory C:\Windows\Microsoft.NET\Framework64\v2.0.50727\
version v2.0.50727
state CLR is initialized
.
SELECT * from sys.dm_clr_appdomains
======================================================
0x0000000087160240 3 mydatabase.dbo[runtime].2 2011-08-12 08:44:08.940 10 1 E_APPDOMAIN_SHARED 1 1
.
SELECT * from sys.dm_clr_tasks
======================================================
0x000000008185A080 0x00000000818562C8 0x0000000000000000 E_TASK_ATTACHED_TO_CLR E_ABORT_NONE E_TYPE_ADUNLOAD 0 0
0x00000000818CE080 0x00000000818CA2C8 0x0000000000000000 E_TASK_ATTACHED_TO_CLR E_ABORT_NONE E_TYPE_FINALIZER 0 0
0x0000000081AD4C30 0x000000000400D048 0x0000000000000000 E_TASK_ATTACHED_TO_CLR E_ABORT_NONE E_TYPE_USER 0 0
.
SELECT * from sys.dm_clr_loaded_assemblies
<returns nothing>
*更新*
在我的SQL Server上,我创建了四个数据库.它们中的每一个都附有相同的组件.现在,SQL Server拒绝加载程序集并给我上述错误.
SELECT * from sys.dm_clr_appdomains在那一点上显示我只加载了一个appdomain SELECT * from sys.dm_clr_loaded_assemblies并向我显示根本没有加载程序集.
然后,我在其他三个数据库上运行相同的存储过程.它工作并成功加载程序集并成功运行存储过程.执行存储过程后. SELECT * from sys.dm_clr_appdomains现在告诉我,只有四个appdomain加载并SELECT * from sys.dm_clr_loaded_assemblies显示我现在有三个程序集已加载.
这是有道理的.现在,我希望如果我在原始数据库中再次运行存储过程,它应该按原样加载程序集.你猜怎么着.不,它没有.它仍然给我同样的错误.看起来这个数据库完全卡住了.解决它的唯一方法是重新启动SQL Server.我希望系统表中的某个地方有一个标志/锁来阻止它.我找不到它了.欢迎任何想法.
现在,我的SQL Server处于要求我重新启动以使其再次运行的状态.
*更新(2011年8月31日)*
听起来它与数据库的数据库所有者有关.这有点复杂.我们有两个站点和两个AD森林.SQL Server计算机已连接到林A但数据库所有者来自林B.林A和林B之间的连接不稳定,因为它们位于通过WAN物理连接的两个不同站点中.
一旦我将数据库所有者更改为SQL登录(非Windows帐户),我的存储过程就会运行几周,到目前为止没有中断.
如果有人能解释,我会接受答案.
Rem*_*anu 47
具有EXTERNAL_ACCESS的程序集通过一些复杂的路径落在EXECUTE AS路径下.当'dbo'无法映射到有效登录时,会出现此问题.dbo的登录名是SID owner_sid值的登录名sys.databases.除非在CREATE DATABASE中使用了AUTHORIZATION子句,否则owner_sid是发出CREATE DATABASE语句的主体的登录sid.大多数情况下,这是登录用户的Windows SID并发出CREATE DATABASE.掌握了这些知识,人们可以很容易地想到可能出现的问题:
MachineA\user或DomainA\user)在机器A上发出CREATE DATABASE,然后将数据库复制到机器B(通过备份/恢复或通过文件复制).owner_sid由文件复制以及备份/恢复保留,在机器B上,owner_sid无效.所有需要EXECUTE的东西都失败了,包括从数据库加载程序集.所有这些问题都可以通过简单运行来诊断:EXECUTE AS USER = 'dbo';在问题db的上下文中.它失败并出现错误,然后组装加载问题的原因是EXECUTE AS上下文dbo.
解决方案很简单,只需强制owner_sid登录即可.sa通常是最好的候选人:
ALTER AUTHORIZATION ON DATABASE::[<dbanme>] TO sa;
有趣的是,数据库可能看起来非常健康; 表可用,您可以运行选择,更新,删除,创建和删除表等.只有某些组件需要EXECUTE AS:
EXECUTE AS在T-SQL代码中显式后者是最常见的罪魁祸首,因为SqlDependency突然依赖的应用程序似乎停止工作,或者有随机问题.本文解释了SqlDependency最终如何依赖于EXECUTE AS:The Mysterious Notification
Ehs*_*edi 33
我经历过.恢复数据库TRUSTWORTHY设置为OFF时似乎.所以我的解决方案是打开它:
ALTER DATABASE [myDB] SET TRUSTWORTHY ON
GO
在我打开它后,我的触发器和存储过程开始像以前一样工作.
mah*_*nya 21
万一有人遇到这个问题,对我有用的解决方案是:
ALTER AUTHORIZATION ON DATABASE::[mydb] TO sa;
其次是
ALTER DATABASE [mydb] SET TRUSTWORTHY ON;
我正在使用管理员帐户恢复我的数据库,除了这两个调用的组合之外别无其他功能.
用[yourdatabasename]替换[mydb]
在我从其他服务器复制数据库并且创建数据库的用户不存在于新服务器上的情况下，需要综合考虑。
myDB是我要访问的数据库，validDbUser是新数据库服务器上的用户名，我希望将该数据库的所有者更改为该用户名。
USE myDB
GO
ALTER DATABASE [myDB] SET TRUSTWORTHY ON
GO
EXEC sp_changedbowner [validDbUser]
小智 7
我将数据库从服务器恢复到我的本地机器并遇到了这个错误。尝试以下两个查询。对我来说，第一个查询有效：
--第一次查询
ALTER DATABASE [database_name] SET TRUSTWORTHY ON;
GO
USE [database_name]
GO
EXEC sp_changedbowner 'sa'
GO
--Second Query -- 如果设置为 false 则启用 CLR 集成
IF ((SELECT [value] FROM sys.configurations WHERE [name] = 'clr enabled') = 0)
BEGIN
EXEC sp_configure 'clr enabled', 1
RECONFIGURE
END
GO
-- 禁用 CLR 严格安全，如果设置为 true
IF EXISTS(SELECT 1 FROM SYS.CONFIGURATIONS WHERE name = 'clr strict security' AND [value] = 1)
BEGIN
IF EXISTS(SELECT 1 FROM SYS.CONFIGURATIONS WHERE name = 'show advanced options' AND [value] = 0)
BEGIN
EXEC sp_configure 'show advanced options', 1
RECONFIGURE
END
EXEC sp_configure 'clr strict security', 0
RECONFIGURE
END
GO
GO
尝试在运行SQL Server 2017的新服务器上更新空间列时看到此错误。
感谢我们客户公司的IT主管发现：
SQL 2017为CLR引入了新的信任规则（SQL 2012没问题）...即使“安全” CLR也必须已签名（此dll不是），否则您必须按以下方式强制信任：
DECLARE @clrName nvarchar(4000) = 'sqlspatialtools, version=0.0.0.0, culture=neutral, publickeytoken=null, processorarchitecture=msil'
DECLARE @asmBin varbinary(max) = 'PUT THE BINARY STRING HERE (GET FROM SCRIPTING CREATE TO FOR THE EXISTING ASSEMBLY'
DECLARE @hash varbinary(64);
SELECT @hash = HASHBYTES('SHA2_512', @asmBin);
EXEC sys.sp_add_trusted_assembly @hash = @hash, @description = @clrName;
这为我们解决了这个问题。
小智 5
我有同样的错误并注意到了什么错误:看看你的程序集ID!它是65536 - 我的是65538
似乎程序集ID是在16位整数上编码的.因此,"服务器可能耗尽资源"具有逻辑意义.
微软的错误,在我看来.如果您找到了比重启或更新服务更好的方法,请告诉我们!:)