SQL Server 2005でのCLRコードの問題

Question

SQL Server 2005のUDFからCLRコードにアクセスすることを検討しています。

CLRコードでスローされた未処理の例外がサーバーをダウンさせる可能性があるという話を聞きました。

明らかに、私の関数にはtry-catchブロックが含まれます。ただし、特定の例外（stackoverflow）はキャッチをスキップできます。

CLRコードがサーバーをダウンさせるリスクを完全に排除（または最小化）できる一連のガイドラインを持っていますか。

Answer 1

未処理の例外はSQL Serverに悪影響を及ぼしますが、どの程度の悪影響がスローされる例外の重大度に依存します。

一般に、制約付き実行領域を使用して、コードの一部が失敗したときに影響を与える可能性のあるスコープ（プロセス、アプリドメイン、スレッドなど）を示します。 SQL Serverはこれを使用して、現在のクエリ/リクエストを単に中止するかどうか、またはより重大なエラーの場合にさらに進むかどうかを決定します。

MSDNマガジンには、CERと、SQL ServerがCERをどのように利用するかについて説明している優れた記事があります。

http://msdn.microsoft.com/en-us/ magazine / cc163716.aspx＃

さらに、SQL Server向けのCLRコードの開発に特化したベストプラクティスのリストを次に示します。

http://msdn.microsoft.com/en-us/ library / ms228970.aspx＃

Answer 2

コードは何をしますか？

CLRを最初に使用せずに目標を達成することにより、リスクを完全に回避することを検討することをお勧めします。しかし、問題が何か、または本当にCLRが必要かどうかわからない場合は、何もお勧めできません。

Answer 3

CLRコードでキャッチされなかった例外は、サーバーを停止しませんでした。 CLRコードは別のアプリドメインで実行され、分離されます。発生する可能性が最も高い（そしてこれはありそうにない）例外は、アプリドメインをダウンさせ、アプリドメインをアンロードすることです。これにより、a）次の要求でリロードされるか、b）問題が修正されるか、アセンブリの新しいバージョンがデプロイされるまで無効になります。

したがって、せいぜい特定のCLRアセンブリは無効になり、呼び出しセッションはエラーメッセージを受け取ります。欠陥のあるCLRコードがSQLサーバーインスタンス全体をダウンさせることはほとんどありません。もしそうなら、私はそれがMicrosoftのバグであり、CLR関数やストアドプロシージャのバグではないと言うでしょう。

非常に可能性の高いケースは、キャッチされていない.net例外がtsqlエラーメッセージに変換されることです。最大で、tsql接続は終了します。ほとんどの場合、エラーメッセージが表示されます。

Answer 4

CLR関数を使用して並列処理を行うクエリの機能を抑制することを強くお勧めします。走行距離は異なる場合がありますが、これによりSQLエンジンエラーの一部が取り除かれることがわかりました。

http://msdn.microsoft.com/en-us/library /ms181714.aspx

WITH( MAXDOP 1)