問題タブ [clrstoredprocedure]

テーブル値関数を使用した SQL Server 2008 R2 CLR データベース プロジェクトがあります。テーブル値関数は、そのロジックを実行するために選択クエリを実行します。これを VS 2010 でデバッグして、コードをステップ実行できるようにしたいのですが、私の人生では、その方法を理解できず、数え切れないほどのブログを読んできました。

また、サーバー エクスプローラーから関数を選択し、コンテキスト メニューの [ステップ イン] オプションをクリックしようとしましたが、開発サーバーにリモート デバッグが設定されていないというエラーが表示されます。リモートデバッグを有効にする必要がありますか? もしそうなら、これを機能させるために正しい方法でそれを行うにはどうすればよいですか? 私は何日もこれにいて、髪を抜く準備ができています. 週末もこれに取り組んでいました。助けていただければ幸いです。

SQL Server コンテキスト内から SFTP を実行する必要があります。MS ライブラリで FTP を実行できますが、SFTP はサポートされていません。

そこで、Rebex をダウンロードしてサンプル プロジェクトを作成し、CLR ストアド プロシージャとして SQL Server にインストールしようとしました。

これを行うと、SQL Server は次のメッセージを表示します。

メッセージ 6218、レベル 16、状態 2、行 3

アセンブリ 'Rebex.Common' の検証に失敗したため、アセンブリ 'RebexTest' の CREATE ASSEMBLY が失敗しました。参照されているアセンブリが最新であり、信頼されている (external_access または安全でない) かどうかを確認して、データベースで実行します。このメッセージに続いて CLR Verifier エラー メッセージが表示される場合

[ : Rebex.Security.Certificates.CertificateStore::Exists][mdToken=0x60003b0]
[オフセット 0x000000C7] メソッドが表示されません。

これを修正して SQL Server にインストールできる方法はありますか?

CLRストアドプロシージャの「HelloWorld」サンプルを実装しましたが、うまくいきました。

次に、コードを変更し、再コンパイルして再実行したところ、新しい結果ではなく、古い結果が得られました。

コードの変更例 (他のすべてのコードは上記のリンクにあります):

前：

後：

新しいアセンブリをロードするために SQL をリサイクルする以外に何かありますか?

物事を簡単にするために、私がやろうとしていることの例を次に示します。

C# で記述された私の CLR ライブラリ (例には示していませんが、スレッドセーフです):

コンパイルしたら、SQL Server にインポートします (Microsoft SQL Server Management Studio を使用)。

ストアド プロシージャをインポートします。

最後に、ストアド プロシージャを呼び出す SQL スクリプトを作成します。

ここで問題: ストアド プロシージャを呼び出すたびに (上記のように)、新しいセッション オブジェクトが作成されます (反対側で複数の TCP 接続が開かれているのでわかります)。

SQL Server がライブラリを複数ロードするのを止めて、実際に「静的」オブジェクト パラダイムを適用するにはどうすればよいですか? ストアドプロシージャが呼び出されるたびに1つの静的オブジェクトではなく、SQL Serverのプロセスが終了するまで、単一の「セッション」を作成するだけです。

ありがとうございました。

詳細（必要かどうかは不明）：私の「セッション」オブジェクトは別のライブラリからロードされます（したがって、技術的には2つのDLLをロードしますが、上記の例では物事を簡単にするために1つだけを示しました）。この情報が関連しているかどうかはわかりませんが、追加することにしました。

編集:同じSQLスクリプトでストアドプロシージャを複数回呼び出すと、単一のセッションオブジェクトが作成されることも追加したいと思います。複数のストアド プロシージャ呼び出しでそのスクリプトを呼び出すたびに、新しいセッション オブジェクトが作成されます。

SQL サーバーが AppDomain をアンロードすることを決定したとき、.Net コードはどのように検出できますか?

SQL サーバーは、さまざまな理由で AppDomain をアンロードすることを決定し、その状態を にリストされているようsys.dm_clr_appdomainsにE_APPDOMAIN_DOOMED変更することがあります。

AppDomain はアンロードされる予定ですが、現在実行中のスレッドがあります。

「AppDomain のアンロードがスケジュールされている」ときに CLR コードで発生するイベント、または CLR コードでこのステータスを検出する方法はありますか?

sys.dm_clr_appdomainsコードがどの AppDomain として実行されているかがわかっていれば、ステータスを定期的にポーリングできますが、これはSqlContextオブジェクトでは公開されません。sys.dm_clr_appdomains.assembly_nameと同じかどうかはわかりませんAppDomain.FriendlyName。

可能であれば永続的に実行されるストアド プロシージャがあります (データが利用可能になると、クライアントにデータをプッシュします)。SQL サーバーが AppDomain をアンロードすることを決定したとき、これらのスレッドはまだ実行されているため、AppDomain がアンロードされることはなく、スレッドが実行を停止することも、クライアントからの接続が閉じられることもありません。

編集：

appdomain_idand appdomain_namein sys.dm_clr_appdomainsmatch System.AppDomain.Idand System.AppDomain.FriendlyName、次の CLR sproc で確認しました。

したがって、次のイベントを待機するタイムアウト後にステータスをポーリングすることは間違いなく可能ですが、アセンブリ ステータスの最大ポーリング頻度に関連する望ましくない量のレイテンシが残ります。

編集2：

AppDomain.DomainUnloadAppDomain が作成されたアセンブリを変更する場合、イベントは発生しません。Sql Server が AppDomain をアンロードすることを決定したときに発生するかどうかはわかりません。

OnUnloadsproc を実行してからアセンブリを変更すると、ALTER ASSEMBLYコマンドがハングするか、イベントが発生せずに AppDomain が停止します。

Microsoft SQL Server 2008 を使用しています。CLR プロシージャを実行すると、以下のエラーが発生します。

アセンブリ ID 65547 を読み込もうとしているときに、Microsoft .NET Framework でエラーが発生しました。サーバーのリソースが不足しているか、アセンブリが PERMISSION_SET = EXTERNAL_ACCESS または UNSAFE で信頼されていない可能性があります。クエリを再度実行するか、ドキュメントを確認して、アセンブリの信頼の問題を解決する方法を確認してください。このエラーの詳細については、System.IO.FileLoadException: ファイルまたはアセンブリ 'clrprocedure、Version=0.0.0.0、Culture=neutral、PublicKeyToken=null' またはその依存関係の 1 つを読み込めませんでした。セキュリティに関するエラーが発生しました。(HRESULT からの例外: 0x8013150A) System.IO.FileLoadException:
System.Reflection.Assembly._nLoad (AssemblyName fileName、文字列 codeBase、証拠 assemblySecurity、アセンブリ locationHint、StackCrawlMark& stackMark、Boolean throwOnFileNotFound、Boolean forIntrospection) で System.Reflection.Assembly.InternalLoad (AssemblyName assemblyRef、証拠 assemblySecurity、StackCrawlMark& stackMark、Boolean forIntrospection) ) System.Reflection.Assembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection) at System.Reflection.Assembly.Load(String assemblyString)

提案してください。

CLR アセンブリを介してフラット ファイルを DB にインポートしています。
フラット ファイルの行ごとに、アセンブリはいくつかの品質チェックを行います。DB テーブルを DataTables に格納し、これらの DataTables をクエリすると、DB を直接クエリするよりもはるかに時間がかかることに気付きました。一方、HashSet は DB のクエリと同じくらい高速に見えます。

現時点では、私のコードはデータを HashSet にロードし、行ごとに HashSet をクエリすることもあれば、DB を行ごとに個別にチェックすることもあります。たとえば、ソース行のキーがデータベースに存在するかどうかを確認すると、〜10 000のソース行と〜1000の正しいキーが可能です。
HashSet :
+ DB に 1 回だけクエリを実行すると、アセンブリは HashSet でチェックを実行できます。
- DB に既に存在するものを複製するのはなぜですか?
DB のクエリ:
+ DB はテーブルの構造を保持し、これらの種類のクエリ用に最適化されています。
- DB 接続を管理する必要があります。これには、DB 接続を複数回開いたり閉じたりすることが含まれる場合があります。

コードを標準化したいのですが、どのオプションを使用するか決めるのに助けが必要ですか? 私にはパフォーマンスの違いはわかりません。CLR アセンブリから DB 接続を開くことが問題にならない場合は、複数のオブジェクトをコーディングするのではなく、CLR アセンブリに SQL コードを記述して実行するだけでよいため、DB にクエリを実行することをお勧めします。 .

どちらか一方を使用する技術的な理由はありますか?
コーディングスタイルの推奨事項?

注: 私は静的データを扱っているので、インポート アセンブリの実行中にデータの変更を心配する必要はありません。

おそらく関連する質問です。