問題タブ [sqlclr]

「Mike|John|Smith」のように区切られた文字列値を取り込むCLRUDFを作成しようとしています。UDFで、値を解析してDataTableに返します。C＃コードは正常にビルドされ、DLLを指すSQLでアセンブリを問題なく作成できます。

このソースによると、TransactSQLリクエストをCLR関数と照合する方法をSQLServerに指示しようとすると、問題が発生します。http://www.setfocus.com/technicalarticles/clrfunctionforsqlserver_2.aspx

または私がそれをしなければならない場合でも？基本的に、文字列を取り込んで、分離された値を解析し、FN、MN、LNの3つの異なる列を持つDBテーブルに配置します。CLRUDFを使用します。

1. 次の2 つのことを行う TSQL ストアド プロシージャtsql__sp__Aがあります。

(a)複雑な SELECT クエリからの SELECT データを含む一時テーブル#tempTableを作成します。

(b)行パラメーターで計算を行う行ごとに、CLR マネージ ストアド プロシージャclr__sp__Bを呼び出します。

質問: 同じ接続コンテキストを使用して、CLR プロシージャ clr__sp__B から#tempTableにアクセスできますか? (いいえ、マネージ プロシージャ内で別の#tempTableを移動または作成したくありません)

ありがとう。

SQL Server 2000には、外部の exe を呼び出す通常の (つまり、拡張されていない) ストアド プロシージャがあります。その exe は、SDK からの .dll をロードし、そこからいくつかのプロシージャ (つまり、Init、DoStuff、Shutdown) を呼び出します。

この外部 exe を使用する唯一の理由は、.dll を呼び出す拡張ストアド プロシージャを作成したくなかったからです。dll がクラッシュした場合 (可能性は低いですが)、SQL Server プロセスもクラッシュすると考えられていましたが、これは私たちが望んでいたことではありませんでした。外部exeを使用すると、そのexeだけがクラッシュします。

現在、SQL Server 2008にアップグレードし、それを呼び出す CLR ストアド プロシージャを作成して、exe を削除することを検討しています。もちろん、この SP は UNSAFE としてマークされます。そのための問題は、拡張 SP アプローチと比較して、そのようにすることは安全である (より安全である、十分に安全であるなど) か?

私がBOLで追い詰めた唯一の関連するものは次のとおりです。

UNSAFE を指定すると、アセンブリ内のコードが SQL Server プロセス空間に対して不正な操作を実行できるようになるため、SQL Server の堅牢性とスケーラビリティが損なわれる可能性があります。

、しかし、「堅牢性とスケーラビリティ」を求めているのではなく、安定性と物事を稼働させ続けることを求めているため、それが私の質問に答えるかどうかはわかりません。

PS: SP のアクセス許可を管理するときに不都合が生じるため、exe を削除したいと考えています (xp_cmdshell を含む SP を呼び出すと、突然適用されるものです)。

SQL Server CLR ストアド プロシージャを作成しているときに、通常のように .net フレームワークで何も参照できないことに気付きました。いくつか読んだ後、最初にアセンブリをデータベースにロードする必要があることに気付きました。

したがって、必要なものをロードしましたが、P/Invoke のために UNSAFE アクセス許可セットを使用する必要がありました。ストアド プロシージャ コードでそれらを参照できるようになり、すべて正常に動作します。

ただし、何をしているのかよくわからない場合に UNSAFE に設定しなければならないことについては少し心配です。だから私の質問はこれです：

.net フレームワークを UNSAFE としてロードしても、それが何をしているのか正確にはわかりませんか? そして、そうすることで、SQLサーバーのセキュリティ/堅牢性/スケーラビリティがどのように損なわれるのでしょうか(マイクロソフトが警告するように)?

どうもありがとう。

CLR プロシージャにメモリ内 DataTable があります。重要な処理の後、DataTable には、データベース内のテーブルにロードする必要がある大量のデータが含まれています。残念ながら、コンテキスト接続を使用しているため、 SqlBulkCopy は機能しません (エラーがスローされます: The requested operation is not available on the context connection Outline of context definitions )。

追加の通常の接続を構築し、それを使用して SQLBulkCopy を実行することを考えています。これは、コンテキスト接続を介して通常の接続を使用するオーバーヘッドを考えると、かなりばかげているように思えます。DataTable の行を繰り返し処理し、それぞれにレコードを挿入することを考えましたが、サイズが非常に大きく、SQLBulkCopy の方が適しているようです。

私たちは DataTable と結婚しておらず、CLR プロシージャから膨大な量のデータをデータベースに挿入する最良の方法を探しているだけです。DataTable に関する最後の注意事項は、基になるデータベース テーブルを表していますが、DataSet または TableAdapter を介してテーブルに関連付けられていません。CLR プロシージャでこれを行う手段は、すぐにはわかりませんでした。これを行い、AcceptChanges または Update メソッドを使用することは、許容できる解決策です。

最近、64 ビット SQL Server 2005 マシンで CLR を有効にして、約 3 proc を使用しました。次のクエリを実行してメモリ使用量に関する情報を収集すると...

私は得る

129 MB のメモリ使用量と 6.3 GB の仮想メモリが予約済み

マシンの合計メモリは 21 ギガです。予約済み仮想メモリとは正確には何を意味し、割り当てられたサイズを制御するにはどうすればよいですか? 6 ギガは私たちがやっていることに対して過剰であり、メモリは sproc キャッシュによってよりよく利用されます。この予約済みメモリがページ ファイルへのスワッピングを引き起こすのではないかと心配しています。

記憶の制御を取り戻すのを手伝ってください！

ありがとう

上記を使用してフレームワークライブラリから非対称キーを生成できないのはなぜですか（CLR関数の参照としてSQLサーバーにインストールするため）。エラーが発生します：

「非対称鍵の生成中にエラーが発生しました。」

非対称キーがない場合、SQL Server（2005）にアセンブリを追加するには、データベースを信頼できるものに設定する必要があります。フレームワークライブラリはSQLServerからの使用を目的としていないことは理解していますが、なぜこれが機能しないのか興味があります。

現在、MS SQL Server 2005 (32 ビット) を使用しています。暗号化と復号化に使用する 1 つのアセンブリ (および 1 つのアセンブリのみ) があります。CLR に割り当てられるシステム メモリは 512 MB のみです。アセンブリの実行はかなり遅く、メモリからのものかどうかを除外しようとしています。(アセンブリではなく) クエリ アナライザーで SQL コードを実行すると、すばやく実行されます。暗号化/復号化には対称キーと証明書を使用しています。

CLR に割り当てるメモリの推奨量はありますか? メモリ割り当ての不足がこのアセンブリのパフォーマンスを低下させているかどうかを確認するにはどうすればよいですか?