問題タブ [sqlclr]

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

SQL CLR ユーザー定義関数がデータ型 varbinary(MAX) を返すことは可能ですか?

ドキュメントでは、次のように言及されています。

「スカラー値関数から返される入力パラメーターと型は、rowversion、text、ntext、image、timestamp、table、または cursor を除く、SQL Server でサポートされている任意のスカラー データ型にすることができます。」-彼らはvarbinaryについて言及していませんが、よくわかりません...

CLRからSQL Serverに返す必要がある.NET側からのバイト配列データがいくつかあり、ストアドプロシージャからの出力パラメーターを使用してそれを行う必要がないようにしています(これが私が持っている方法です)現在テスト中です）。

ありがとう！

複雑なフィルタリングと操作のために、Linq ベースの CLR ストアド プロシージャに取り組んでいます。それ以外の場合は、より「従来の」ストアド プロシージャで実装すると、面倒でパフォーマンスの低い T-SQL コードが大量に必要になります。

これはうまく機能していますが、モジュール内のデータベースオブジェクトをより適切に編成および分離するために、展開の段階でこのストアドプロシージャのスキーマを設定する方法が見つかりません。

何か案は？

よろしくお願いします。

私はストアド プロシージャを作成しています。このストアド プロシージャは、完了するとステージング テーブルをスキャンして偽のデータを列ごとにスキャンするために使用されます。

演習のステップ 1 は、テーブルをスキャンすることでした --- 以下のコードは、これを実行します。問題は、このコードが 5:45 秒で実行されることです --- ただし、コンソール アプリとして実行される同じコード (もちろん、接続文字列を変更します) は約 44 秒で実行されます。

ただし、同じコード (もちろん異なる接続文字列) がコンソール アプリで約 44 秒で実行されます (これは、クライアント側で期待していたものに近いです)。

SP側で何が欠けているので、実行が非常に遅くなります。

注: 行数が必要な場合は、count(*) 集計を使用する必要があることを十分に理解しています。これは、この演習の目的ではありません。