SQL CLR ストアド プロシージャにおける読み取り専用のカーソルのパフォーマンスの最適化

SQL CLR ストアド プロシージャで読み取り専用のカーソルのパフォーマンスを最適化するには、OpenESQL がそれらのストアド プロシージャをどのように処理しているかを理解する必要があります。SQL CLR ストアド プロシージャでは、複数のアクティブな結果セット (Multiple Active Result Sets; MARS) 指令を使用できないため、アクティブな結果セットを処理するために回避策を提供するよう OpenESQL に要求します。実装されるソリューションは、Enterprise Developer のバージョンに応じて異なります。

Enterprise Developer 2.1 の Hot Fix 8 以降では、OpenESQL は、SQL CLR ストアド プロシージャでのスクロール不可能な読み取り専用の COBOL カーソルに DYNAMIC サーバー カーソル オプションではなく、FAST FORWARD を使用するようデフォルト設定されています。通常、FAST FORWARD カーソルにより、動的カーソルよりも優れたクエリ アクセス プランが生成されますが、クエリ プランの効率はファイアホース カーソルほど高くない場合があります。

このシナリオでは、OpenESQL DATASET カーソルに切り替えることで、サーバー カーソルを使用することを完全に回避できます。この変更では、コード変更が DECLARE CURSOR 文自体に限定されます。ただし、この方法では、ストアド プロシージャで使用されるメモリに結果セット全体が格納されるという欠点があります。結果セットが大きい、または多くのクライアントから同時にプロシージャが呼び出された場合、これにより、カーソルが開いている間に SQL Server のメモリを消費する可能性があります。さらに、DATASET カーソルは読み取り専用のカーソルに制限されていませんが、ロックすることはできません。したがって、(位置指定 UPDATE は引き続きサポートされますが) ペシミスティック同時実行を使用できません。これにより、アプリケーション ロジックが失敗する可能性があります。

OPTION=OPTIMIZESPCURSORS 指令、または Enterprise Developer 2.2 Update 1 以降の場合は OPTIMIZESPCURSORS 指令を使用することで、コード変更を完全に回避することができます。この場合、OpenESQL はファイアホース カーソルを開きます。カーソルを閉じる前にその他のデータベース アクセスが発生した場合、OpenESQL によって結果セットの残りの部分が DATASET カーソルに変換されます。

次の表に、オプションをまとめます。