SQL: CLR: The server may be running out of resources, or the assembly may not be trusted with PERMISSION_SET = EXTERNAL_ACCESS or UNSAFE.

30-gru-2015

Oto jaki błąd przywitał mnie dzisiaj na pewnym serwerze:

An error occurred in the Microsoft .NET Framework while trying to load assembly id 65541. 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 'XXXXXXX, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null’ or one of its dependencies.

Exception from HRESULT: 0x80FC3C2C System.IO.FileLoadException: at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean

Co u licha!? CLR miewa problemy z rezerwowaniem pamięci, zwłasza jeżeli pamięc zostałaby zeswapowana (brak lock pages in memory dla sql) lub w SQL 2008 R2 Max memory jest ustawione zbyt wysoko. Ponieważ serwer był testowy mogłem zrestartować SQL, ale… nie pomogło!

Trochę mnie zasmucił wpis:

https://social.msdn.microsoft.com/Forums/sqlserver/en-US/edfb60d0-8422-441c-afeb-8e13eae25631/after-working-for-a-while-an-sqlclr-assembly-wont-load?forum=sqlnetfx

Ale to chyba nie mój przypadek – szukam dalej:

https://support.microsoft.com/en-us/kb/918040

Wprawdzie to nie był dokładnie mój przypadek, ale nasunął mi się pomysł sprawdzenia, jaki login jest właścicielem bazy danych. Bingo – właścicielem było konto użytkownika, które zostało zablokowane w AD. Zmieniłem właściciela bazy, w której znajdował się assembly CLR na „sa” i zaczęło działać!