web-dev-qa-db-ja.com

.NET SQLCLRアセンブリがSQL Server 2016で機能しない（エラーメッセージ10314）

サードパーティの.NET CLRアセンブリを使用して文字列を解析するデータベースアプリケーションをWindows 2008 R2/SQL Server 2008 R2からWindows 2012 R2/SQL Server 2016に移行しています。

私が得るエラーは：

アセンブリID 65540を読み込もうとしたときに、Microsoft .NET Frameworkでエラーが発生しました。サーバーのリソースが不足しているか、アセンブリがPERMISSION_SET = EXTERNAL_ACCESSまたはUNSAFEで信頼されていない可能性があります。クエリを再度実行するか、ドキュメントをチェックして、アセンブリの信頼の問題を解決する方法を確認してください。このエラーの詳細については：
System.IO.FileLoadException：ファイルまたはアセンブリ 'clrsplit、Version = 0.0.0.0、Culture = neutral、PublicKeyToken = null'またはその依存関係の1つをロードできませんでした。セキュリティに関するエラーが発生しました。 （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 forIntrospection、Boolean suppressSecurityAsslyly.AssetlyAssemblyly.AssemblyAssembly。 System.Reflection.RuntimeAssembly.InternalLoad（文字列assemblyString、証拠assemblySecurity、StackCrawlMark＆stackMark、のIntPtr pPrivHostBinder、ブールforIntrospection）ATで（のAssemblyName assemblyRef、証拠assemblySecurity、RuntimeAssembly reqAssembly、StackCrawlMark＆stackMark、のIntPtr pPrivHostBinder、ブールthrowOnFileNotFound、ブールforIntrospection、ブールsuppressSecurityChecks） System.Reflection.Assembly.Load（String assemblyString）でのSystem.Reflection.RuntimeAssembly.InternalLoad（String assemblyString、Evidence assemblySecurity、StackCrawlMark＆stackMark、Boolean forIntrospection）[SQLSTATE 42000]（エラーr 10314）。

エラー：10314、重大度：16、状態：11。

データベースのTRUSTWORTHYビットが設定されています。

name             is_trustworthy_on
msdb             1
SimplusStaging   1

PERMISSION_SETはUNSAFEに設定されます。アセンブリはベンダーのインストール手順であったため、UNSAFEとマークされています。アセンブリと関連するT-SQLオブジェクトを削除して再作成してみました。変化なし。 DBOユーザーはSAログインです。そして、これがこのデータベース/サーバーに使用する唯一のCLRアセンブリです。

これは、デタッチ/アタッチを使用した新規インストールです。 KB2919355 をインストールしました。そうしないと、SQL Server 2016がインストールされませんでした。

私は2016年に新しいSTRING_SPLIT関数を使用したいと思います。ただし、アプリケーションはサードパーティによってサポートされており、2008 R2のすべてをビルドしました。 2016年の「より速く動く」新機能のいくつかを活用したいと考えました。

Db所有者のSIDは、元のインストールと新しいインストールの両方で同じです。次の両方のクエリは、問題のデータベースのコンテキストで実行すると0x01を返します。

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

新しい.Net Framework用にCLRアセンブリを再コンパイルする必要がありますか、それとも機能しますか？

Windows 2008 R2でSQL 2012および2014への同じ移行を行うと、問題なく動作しました。

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

次の形式のエラー：

メッセージ10314、レベル16、状態11、行1
アセンブリID #####をロードしようとしたときに、Microsoft .NET Frameworkでエラーが発生しました。サーバーのリソースが不足しているか、アセンブリがPERMISSION_SET = EXTERNAL_ACCESSまたはUNSAFEで信頼されていない可能性があります。クエリを再度実行するか、ドキュメントをチェックして、アセンブリの信頼の問題を解決する方法を確認してください。このエラーの詳細については：
System.IO.FileLoadException：ファイルまたはアセンブリ '{_Assembly_name _}、Version =＃。＃。＃。＃、Culture = neutral、PublicKeyToken = xxxxxxxxxxxxxxxx'またはその依存関係の1つを読み込めませんでした。セキュリティに関するエラーが発生しました。 （HRESULTからの例外：0x8013150A）

は、現在PERMISSION_SETまたはUNSAFEのEXTERNAL_ACCESSでマークされているアセンブリが、SQLCLR権限設定の2番目の部分が完了するまで、その権限レベルを使用することを許可されないことを意味します世話をした。その2番目の部分は、以下のoneを実行することです。

  • 非常に推奨されるアプローチ

    1. コンパイル時にアセンブリに署名します（そしてパスワードを与えます！）。これは、厳密な名前を付けると呼ばれることがあります。

      アセンブリが署名されておらず、再コンパイルするためのソースコードがない場合およびアセンブリを参照する他のアセンブリがない場合でも、このブログ投稿の前半の指示に従って署名します： http://ianpicknell.blogspot.com/2009/12/adding-strong-name-to-third-party.html

    2. そのアセンブリのDLLから[master]に非対称キーを作成します
    3. その非対称キーからログインを作成する
    4. そのEXTERNAL ACCESS AssemblyまたはUNSAFE Assemblyの2つの権限のいずれかをログインに付与します（UNSAFE Assembly権限により、アセンブリをEXTERNAL_ACCESSとしてマークすることもできるため、両方の権限は必要ありません）。
    5. 存在するデータベースにアセンブリを作成します
    6. このアセンブリを含むデータベースのTRUSTWORTHYプロパティをONに設定しないでください。 TRUSTWORTHYはOFFのままにすることができます。

  • 推奨されないアプローチ

    1. アセンブリが存在する必要があるデータベースをTRUSTWORTHY ONに変更します
    2. このアセンブリを含むデータベースの所有者のログインに、EXTERNAL ACCESS AssemblyまたはUNSAFE Assemblyの2つの権限のいずれかがあることを確認してください。

      データベースの所有者がsa、またはsysadmin固定サーバーロールにある他のログインである場合、次のことを心配する必要はありませんこれらの2つの権限の1つは、sysadminロールによって暗黙的に設定されるため、明示的に設定されます。
    3. 可能な限り、このアプローチは避けてください:-)
6
Solomon Rutzky

質問作成者のコメントから生成されたコミュニティWiki回答

答えが見つかりました。結局、CLRアセンブリは2つの異なるデータベースで使用されました。両方とも信頼できるビットがオンになっていることを確認する必要がありました。また、部分的に信頼された呼び出し元は使用できないと記載されているため、UNSAFEとしてアセンブリを作成する必要があったため、文字列分割以外の処理を行っていることは明らかです。

2
Paul White 9