Спасибо за ваше предложение и извините, в принципе невозможно разместить код здесь. У нас около 40 хранимых процедур, и код там совсем не простой. Я слышу тебя. Вполне возможно, что у нас может быть какая-то утечка и, следовательно, ошибка исчерпания ресурсов. Мы установили наш параметр MemToLeave (SQL-сервер памяти, используемый для .NET, связанный сервер и некоторые другие вещи) в 1 ГБ. Во время сбоя я проверил память, SQL Server вообще не использовал 1 ГБ памяти. Мы пришли к выводу, что это связано с плохой ссылкой, и мы используем пользователя домена удаленного леса в качестве владельца базы данных.

зработали сборку для 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)

Я нашел разные статьи в Интернете.

Этот кб предположил, что я мог восстановить базу данных с другого сервера SQL, что, клянусь, я не сделал.

Этот блог сказал, что я могу столкнуться с этим, если я установил .NET 3.5 на SQL Server 2005, но у меня был SQL Server 2008 R2, и я ничего не установил, когда возникла эта проблема.

Суть в том, что он может продолжаться какое-то время. Он просто перестает работать в случайном порядке. Затем, если мы перезапустим SQL Server, он снова начнет работать. Я думал о том, что моему серверу действительно не хватает памяти, но теперь я просто вижу проблему снова. SQL Server использует только 300 МБ ОЗУ, а мой сервер имеет 16 ГБ ОЗУ. Это звучит невозможно, потому что у меня заканчивается память.

Теперь я хочу собрать больше информации по этой проблеме. Любой журнал, который я могу включить и посмотреть? Любые предложения, которые помогут решить эту проблему, приветствуются.

Я выполнил несколько запросов 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 показывает, что в тот момент был загружен только один домен приложений иSELECT * from sys.dm_clr_loaded_assemblies показал мне, что не было загруженных сборок вообще.

Затем я запустил тот же хранимый процесс в трех других базах данных. Он работал и успешно загрузил сборки и успешно запустил сохраненный процесс. После выполнения сохраненной процедуры.SELECT * from sys.dm_clr_appdomains теперь показывает, что загружено только четыре приложения иSELECT * from sys.dm_clr_loaded_assemblies показал, что сейчас загружены три сборки.

Это имеет смысл. Теперь, я надеюсь, что если я снова запущу сохраненный процесс в исходной базе данных, сборка будет загружена как есть. Угадай, что. Нет, это не так. Это все еще дает мне ту же ошибку. Похоже, эта база данных полностью застряла. Единственный способ исправить это - перезагрузить SQL Server. Я надеюсь, что где-то в системной таблице есть флаг / блокировка, удерживающая это. Я не могу найти это. Любая идея приветствуется.

Теперь мой SQL Server находится в состоянии, требующем перезагрузки, чтобы он снова заработал.

* ОБНОВЛЕНИЕ (31.08.2011) *

Похоже, это связано с владельцем базы данных базы данных. Это довольно сложно. У нас есть два сайта и два леса AD. Компьютер SQL Server присоединен к лесу A, но владелец базы данных находится в лесу B. Соединение между лесом A и лесом B не столь стабильно, поскольку они находятся в двух разных сайтах, физически соединенных через глобальную сеть.

После того, как я изменил владельца базы данных на учетную запись SQL (учетная запись не Windows), мой сохраненный процесс работает в течение нескольких недель без перерыва.

Я приму ответ, если кто-нибудь сможет это объяснить.

Ответы на вопрос(10)

Ваш ответ на вопрос