it-swarm.com.de

.NET SQLCLR-Assembly funktioniert nicht in SQL Server 2016 (Fehlermeldung 10314)

Ich migriere eine Datenbankanwendung von Windows 2008 R2/SQL Server 2008 R2 auf Windows 2012 R2/SQL Server 2016, die eine .NET CLR-Assembly eines Drittanbieters zum Analysieren von Zeichenfolgen verwendet.

Der Fehler, den ich bekomme, ist:

In Microsoft .NET Framework ist beim Laden der Assembly-ID 65540 ein Fehler aufgetreten. Dem Server gehen möglicherweise die Ressourcen aus, oder der Assembly wird möglicherweise nicht PERMISSION_SET = EXTERNAL_ACCESS oder UNSAFE anvertraut. Führen Sie die Abfrage erneut aus, oder überprüfen Sie die Dokumentation, um zu erfahren, wie Sie die Assembly-Vertrauensprobleme lösen können. Weitere Informationen zu diesem Fehler:
System.IO.FileLoadException: Datei oder Assembly 'clrsplit, Version = 0.0.0.0, Culture = neutral, PublicKeyToken = null' oder eine ihrer Abhängigkeiten konnte nicht geladen werden. Ein Sicherheitsfehler ist aufgetreten. (Ausnahme von HRESULT: 0x8013150A)

System.IO.FileLoadException: at System.Reflection.RuntimeAssembly._nLoad (AssemblyName Dateiname, String codeBase, Evidence AssemblySecurity, RuntimeAssembly locationHint, StackCrawlMark & ​​stackMark, IntPtr pPrivHostBinder. (Assembly AssemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark & ​​stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks) bei System.Reflection.RuntimeAssembly.InternalLoad (String assembly, Evidence assemblySecurity, StackCrawlMark & ​​stackMark, IntPtr pPrivHostBinder, Boolean forIntrospection) bei System.Reflection.RuntimeAssembly.InternalLoad (String AssemblyString, Evidence AssemblySecurity, StackCrawlMark & ​​StackMark, Boolean forIntrospection) bei System.Reflection.Assembly.Load (String AssemblyString) [SQLSTATE 42000] (Erro r 10314).

Fehler: 10314, Schweregrad: 16, Status: 11.

Das Datenbank-TRUSTWORTHY-Bit wird gesetzt:

name             is_trustworthy_on
msdb             1
SimplusStaging   1

PERMISSION_SET Ist auf UNSAFE gesetzt. Die Montage ist als UNSICHER gekennzeichnet, da dies die Installationsanweisungen des Herstellers waren. Ich habe versucht, die Assembly und zugehörige T-SQL-Objekte zu löschen und neu zu erstellen. Keine Änderung. Der DBO-Benutzer ist der SA Login. Und dies ist die einzige CLR-Assembly, die wir für diese Datenbank/diesen Server verwenden.

Dies ist eine Neuinstallation mit Trennen/Anhängen. Wurde KB2919355 installiert, da sonst SQL Server 2016 nicht installiert würde.

Ich würde gerne die neue Funktion STRING_SPLIT Im Jahr 2016 verwenden, außer dass die Anwendung von einem Drittanbieter unterstützt wird und alles für 2008 R2 erstellt wurde. Wollte 2016 einige der neuen Funktionen nutzen, bei denen "es nur schneller läuft".

Die SID des Datenbankbesitzers ist sowohl für die ursprüngliche als auch für die neue Installation gleich. Die beiden folgenden Abfragen geben 0x01 Zurück, wenn sie im Kontext der Problemdatenbank ausgeführt werden:

SELECT [sid] FROM sys.database_principals WHERE [name] = N'dbo';
SELECT [owner_sid] FROM sys.databases WHERE [database_id] = DB_ID();

Muss ich die CLR-Assembly für ein neues .Net-Framework neu kompilieren oder sollte es einfach funktionieren?

Die gleiche Migration zu SQL 2012 und 2014 unter Windows 2008 R2 funktionierte ohne Probleme.

6
ArgeeSix

Ein Fehler in Form von:

Nachricht 10314, Ebene 16, Status 11, Zeile 1
Beim Laden der Assembly-ID ##### ist in Microsoft .NET Framework ein Fehler aufgetreten. Dem Server gehen möglicherweise die Ressourcen aus, oder der Assembly wird PERMISSION_SET = EXTERNAL_ACCESS oder UNSAFE möglicherweise nicht vertraut. Führen Sie die Abfrage erneut aus, oder überprüfen Sie die Dokumentation, um zu erfahren, wie Sie die Assembly-Vertrauensprobleme lösen können. Weitere Informationen zu diesem Fehler:
System.IO.FileLoadException: Datei oder Assembly '{_Assembly_name_}, Version = #. #. #. #, Culture = neutral, PublicKeyToken = xxxxxxxxxxxxxxxx' oder eine ihrer Abhängigkeiten konnte nicht geladen werden. Ein Sicherheitsfehler ist aufgetreten. (Ausnahme von HRESULT: 0x8013150A)

bedeutet, dass die Assembly, die derzeit mit einem PERMISSION_SET von entweder EXTERNAL_ACCESS oder UNSAFE gekennzeichnet ist, diese Berechtigungsstufe erst im zweiten Teil der SQLCLR-Berechtigungen verwenden darf Setup ist erledigt. Dieser zweite Teil soll eins der folgenden Aufgaben ausführen:

  • Der sehr viel bevorzugte Ansatz

    1. Unterschreiben Sie die Assembly beim Kompilieren (und geben Sie ihr ein Passwort!). Dies wird manchmal als starker Name bezeichnet.

      Wenn die Assembly nicht signiert ist und Sie nicht über den Quellcode zum erneuten Kompilieren verfügen, und keine anderen Assemblys, die darauf verweisen, können Sie sie trotzdem signieren Befolgen Sie die Anweisungen in der ersten Hälfte dieses Blog-Beitrags: http://ianpicknell.blogspot.com/2009/12/adding-strong-name-to-third-party.html

    2. Erstellen Sie einen asymmetrischen Schlüssel in [master] Aus der DLL dieser Assembly)
    3. Erstellen Sie ein Login aus diesem asymmetrischen Schlüssel
    4. Gewähren Sie dem Login eine dieser beiden Berechtigungen: EXTERNAL ACCESS Assembly Oder UNSAFE Assembly (Mit der Berechtigung UNSAFE Assembly Können Baugruppen auch als EXTERNAL_ACCESS Markiert werden, sodass Sie dies nicht tun benötigen beide Berechtigungen)
    5. Erstellen Sie die Assembly in den Datenbanken, in denen sie vorhanden sein soll
    6. Setzen Sie die Eigenschaft TRUSTWORTHY der Datenbank (en), die diese Assembly enthalten, NICHT auf ON. TRUSTWORTHY kann als OFF bleiben.
  • Der NICHT bevorzugte Ansatz

    1. Ändern Sie die Datenbank (en), in denen die Assembly existieren soll, auf TRUSTWORTHY ON
    2. Stellen Sie sicher, dass die Anmeldung des Eigentümers der Datenbank (en), die diese Assembly enthält, über eine der beiden Berechtigungen verfügt: EXTERNAL ACCESS Assembly Oder UNSAFE Assembly.

      Wenn der Eigentümer der Datenbank (en) sa oder ein anderes Login ist, das sich in der festen Serverrolle sysadmin befindet, müssen Sie sich keine Sorgen machen Eine dieser beiden Berechtigungen wird explizit festgelegt, da sie von der Rolle sysadmin impliziert werden.
    3. Versuche diesen Ansatz möglichst zu vermeiden :-)
6
Solomon Rutzky

(Community Wiki Antwort generiert aus einem Kommentar des Frageautors

Habe die Antwort gefunden. Es stellte sich heraus, dass die CLR-Assembly in zwei verschiedenen Datenbanken verwendet wurde. Musste sicherstellen, dass beide vertrauenswürdige Bit eingeschaltet hatten. Außerdem wird offensichtlich etwas anderes als das Aufteilen von Zeichenfolgen ausgeführt, da ich die Assembly als UNSAFE erstellen musste, da darin angegeben ist, dass teilweise vertrauenswürdige Aufrufer nicht verwendet werden können.

2
Paul White 9