web-dev-qa-db-fra.com

L'assembly .NET SQLCLR ne fonctionne pas dans SQL Server 2016 (message d'erreur 10314)

Je migre une application de base de données de Windows 2008 R2/SQL Server 2008 R2 vers Windows 2012 R2/SQL Server 2016 qui utilise un assemblage .NET CLR tiers pour analyser les chaînes.

L'erreur que j'obtiens est:

Une erreur s'est produite dans Microsoft .NET Framework lors de la tentative de chargement de l'ID d'assembly 65540. Le serveur peut manquer de ressources, ou l'assembly peut ne pas être approuvé avec PERMISSION_SET = EXTERNAL_ACCESS ou UNSAFE. Exécutez à nouveau la requête ou consultez la documentation pour voir comment résoudre les problèmes d'approbation d'assembly. Pour plus d'informations sur cette erreur:
System.IO.FileLoadException: impossible de charger le fichier ou l'assembly "clrsplit, Version = 0.0.0.0, Culture = neutral, PublicKeyToken = null" ou l'une de ses dépendances. Une erreur relative à la sécurité s'est produite. (Exception de HRESULT: 0x8013150A)

System.IO.FileLoadException: at System.Reflection.RuntimeAssembly._nLoad (AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark & ​​stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean throwOnFileNotFound, Boolean Throw (AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark & ​​stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks) at System.Reflection.RuntimeAssembly, AssemblySystemAssembly, Assembly System.Reflection.RuntimeAssembly.InternalLoad (String assemblyString, Evidence assemblySecurity, StackCrawlMark & ​​stackMark, Boolean forIntrospection) sur System.Reflection.Assembly.Load (String assemblyString) [SQLSTATE 42000] (Erro r 10314).

Erreur: 10314, gravité: 16, état: 11.

Le bit TRUSTWORTHY de la base de données est défini:

name             is_trustworthy_on
msdb             1
SimplusStaging   1

PERMISSION_SET est défini sur UNSAFE. L'assemblage est marqué UNSAFE car il s'agit des instructions d'installation du fournisseur. J'ai essayé de supprimer l'assembly et les objets T-SQL associés et de les recréer. Pas de changement. L'utilisateur DBO est le login SA. Et, c'est le seul assemblage CLR que nous utilisons pour cette base de données/serveur.

Il s'agit d'une nouvelle installation utilisant detach/attach. KB2919355 s'est-il installé parce que sinon SQL Server 2016 ne s'installerait pas.

J'aimerais utiliser le nouveau STRING_SPLIT fonctionne en 2016, sauf que l'application est prise en charge par un tiers et qu'ils ont tout construit pour 2008 R2. Je voulais profiter de certaines des nouvelles fonctionnalités de 2016 où "ça fonctionne juste plus vite".

Le SID du propriétaire de la base de données est le même pour l'installation d'origine et la nouvelle installation. Les deux requêtes suivantes renvoient 0x01 lorsqu'il est exécuté dans le contexte de la base de données de problèmes:

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

Dois-je recompiler l'assembly CLR pour un nouveau framework .Net ou doit-il simplement fonctionner?

Faire cette même migration vers SQL 2012 et 2014 sur Windows 2008 R2 a fonctionné sans problème.

sql-serversql-server-2016sql-clr
6
ArgeeSix

Une erreur sous forme de:

Msg 10314, niveau 16, état 11, ligne 1
Une erreur s'est produite dans Microsoft .NET Framework lors de la tentative de chargement de l'ID d'assembly #####. Le serveur peut manquer de ressources ou l'assembly peut ne pas être approuvé avec PERMISSION_SET = EXTERNAL_ACCESS ou UNSAFE. Exécutez à nouveau la requête ou consultez la documentation pour voir comment résoudre les problèmes d'approbation d'assembly. Pour plus d'informations sur cette erreur:
System.IO.FileLoadException: impossible de charger le fichier ou l'assembly '{_Assembly_name_}, Version = #. #. #. #, Culture = neutral, PublicKeyToken = xxxxxxxxxxxxxxxx' ou l'une de ses dépendances. Une erreur relative à la sécurité s'est produite. (Exception de HRESULT: 0x8013150A)

signifie que l'Assemblée, actuellement marquée d'un PERMISSION_SET de n'importe quel EXTERNAL_ACCESS ou UNSAFE n'est pas autorisé à utiliser ce niveau d'autorisation tant que la deuxième partie de la configuration des autorisations SQLCLR n'est pas prise en charge. Cette deuxième partie consiste à faire un de ce qui suit:

  • L'approche très préférée

    1. Signez l'assembly lors de sa compilation (et donnez-lui un mot de passe!). On parle parfois de lui donner un nom fort.

      Si l'assembly n'est pas signé et que vous n'avez pas le code source pour le recompiler, et il n'a pas d'autres assemblys qui le référencent, alors vous pouvez toujours le signer par en suivant les instructions de la première moitié de ce billet de blog: http://ianpicknell.blogspot.com/2009/12/adding-strong-name-to-third-party.html

    2. Créer une clé asymétrique dans [master] à partir du DLL de cet assembly
    3. Créer une connexion à partir de cette clé asymétrique
    4. Accordez à cette connexion l'une de ces deux autorisations: EXTERNAL ACCESS Assembly ou UNSAFE Assembly (le UNSAFE Assembly l'autorisation permet également aux assemblys d'être marqués comme EXTERNAL_ACCESS, vous n'avez donc pas besoin des deux autorisations)
    5. Créez l'assembly dans la ou les bases de données dans lesquelles il doit exister
    6. Ne définissez PAS la propriété TRUSTWORTHY de la ou des bases de données contenant cet assembly sur ON. TRUSTWORTHY peut rester comme OFF.

  • L'approche NON préférée

    1. Modifiez la ou les bases de données dans lesquelles l'assembly doit exister pour être TRUSTWORTHY ON
    2. Assurez-vous que la connexion du propriétaire de la ou des bases de données contenant cet assembly possède l'une de ces deux autorisations: EXTERNAL ACCESS Assembly ou UNSAFE Assembly.

      Si le propriétaire de la ou des bases de données est sa, ou toute autre connexion se trouvant dans le rôle de serveur fixe sysadmin, vous n'avez pas à vous soucier d'avoir l'une de ces deux autorisations définie explicitement car elle est impliquée par le rôle sysadmin.
    3. Essayez d'éviter cette approche, si possible :-)
6
Solomon Rutzky

Réponse Wiki communautaire générée à partir d'un commentaire de l'auteur de la question

J'ai trouvé la réponse. Il s'avère que l'assemblage CLR a été utilisé dans 2 bases de données différentes. Besoin de s'assurer que les deux avaient un bit de confiance activé. De plus, il fait évidemment autre chose que le fractionnement de chaînes car j'avais besoin de créer l'assembly en tant que UNSAFE car il dit qu'il ne peut pas utiliser des appelants partiellement fiables.

2
Paul White 9