4

現在設計段階にある、スケーラブルでパフォーマンス中心の新しい ASP.Net アプリケーションを組織に導入しています。

マネージャーは、ハイブリッド アプローチを採用することを決定しました。彼らは、CLR ストアド プロシージャを広範に使用し、T-SQL は単純なデータ操作のみに使用することにしました。

コミュニティから次のことを知りたいです。

  1. 非常に多くの CLR ストアド プロシージャを使用すると、後の段階でパフォーマンスの問題が発生する可能性がありますか?
  2. パフォーマンスの問題があった場合、MS チームから入手できる修正プログラムはありましたか?

注: Google を実行したところ、次の最も可能性の高い問題が見つかりましたが、最初の 2 つの解決策は見つかりませんでした。

  1. SQL Server がアセンブリを読み込むと、メモリにキャッシュされます。O/S がメモリ不足を SQL Server に通知すると、明示的なガベージ コレクションが実行され、アセンブリがアンロードされる場合があります。これが頻繁に発生すると、パフォーマンスの問題が発生する可能性があります。

  2. SQL CLR コードは、コードが実際に行うことを確認しないため、クエリ オプティマイザーによって正確にコストを計算できません。これは、実行計画に影響を与える可能性があります。

  3. SQL CLR コードは、通常はシングル スレッドであるため、並列処理を妨げる場合があります。これにより、パフォーマンスが低下する場合があります。<< ここで解決策を見つけましたが、CLR Stored Procs のマルチスレッド コードですか? >>

CLR ストアド プロシージャに関する問題と修正について教えてください。

4

1 に答える 1

2

SQL サーバーの CLR アセンブリを実行しました。辛い経験でした。このような種類の CLR プロジェクトで使用できる多くの制限があります。たとえば、サードパーティ ライブラリやオープン ソース ライブラリを使用することはできません。一部のライブラリは、SQL サーバーに展開することはできません。使用できるライブラリは限られています。

2 つ目の問題は、展開と権限の設定です。DBA がデータベースに対して非常に制限されたポリシーを持っている場合、CLR アセンブリをデータベースに展開することはできません。

私のアドバイスは、データベース コンポーネントを ASP.Net のライブラリとして作成することです。これは非常に簡単で、SQL サーバーの CLR アセンブリのような制限はありません。

2008 年に、私はこの問題に関する連載ブログを書きました: SQL Sever Projects (1-4)。それらを参照として使用できます。

于 2012-03-30T04:49:14.933 に答える